Most of the STIR/SHAKEN conversation aimed at operators is still framed as a deployment story: stand up an authentication service, get your SPC token from the Policy Administrator, sign your outbound INVITEs, done. If you are an originating carrier, that framing hides the part that actually carries risk. Attestation is not a configuration setting. Every time your softswitch or session border controller stamps a call with an A, you are making a verifiable claim about a specific subscriber and a specific number, and you are the party on record if that claim is wrong.
This is operator-to-operator background reading, not regulatory or legal advice. STIR/SHAKEN obligations, robocall-mitigation expectations, and enforcement posture shift with FCC orders and with your own regulatory status, and the specifics as of publication may not match where things stand when you read this. Confirm current requirements with your regulatory counsel and against the live FCC guidance before you rely on anything here for a filing.
Attestation is a claim about the caller, not the call
The three levels exist to answer one question: how much does the originating carrier actually know about who is placing this call and whether they have the right to use the number in the From header. Full (A) attestation says two things at once — you have a direct authenticated relationship with the customer, and you have verified they are authorized to use that calling number. Partial (B) drops the second claim: you know the customer but cannot vouch for the number. Gateway (C) says you are passing a call into the network but cannot vouch for the origin at all.
The distinction that trips people up is that B is not a downgrade you apply when you are being cautious about call quality. It is the honest answer whenever you cannot tie the calling number to the customer with confidence. Reaching for A because your downstream partners prefer to see it, without the underlying number verification, is exactly the behavior the framework was built to expose. The caveat here: the line between A and B is a judgment call at the edges, and reasonable operators reading the same customer record can land differently. Document why you chose the level you chose.
Where small originating carriers get attestation wrong
The most common failure is not malice, it is inheritance. A reseller or downstream customer brings numbers onto your platform that were ported or assigned somewhere else, your provisioning system marks them as active, and your authentication service happily A-attests everything that originates from that trunk. Nobody verified that the end user actually controls those DIDs — the switch just treats “number is in my routing table” as “number is authorized.” Those are not the same claim, and A-level attestation asserts the second one.
A second recurring problem is static trunk-level attestation policy. If your SBC is configured to attest every call from a given customer trunk at A regardless of the calling number, you have effectively decided that any number that customer can stuff into a From header is one they are authorized to use. For a single-location business with a fixed DID block, that assumption is usually fine. For a wholesale customer reoriginating traffic, it is not. Attestation logic that cannot distinguish those two cases will eventually attest something it should not.
Our 2026 LNP, E911, CNAM and STIR/SHAKEN compliance checklist walks the number-provisioning side of this in more detail, and it pairs directly with the attestation logic discussed here — the two problems share a root cause, which is trusting the routing table as if it were an authorization record.
The Robocall Mitigation Database is not a one-time filing
Filing a certification in the Robocall Mitigation Database and then never touching it again is a live exposure. The database entry is supposed to describe the robocall-mitigation program you are actually running, and it is meant to stay current. If your practices change — you add a wholesale customer, you start accepting foreign-originated traffic, you outsource authentication — and your filed description no longer matches reality, the gap is the problem, not just the original filing.
There is also the downstream obligation that catches smaller operators off guard: intermediate and terminating providers are generally expected not to accept traffic from originators that are not properly listed, which means your own filing status affects whether your traffic gets accepted at all. The honest limitation here is that enforcement intensity and the exact acceptance behavior of your downstream partners vary, and they have been moving. Treat your database entry as a document you review on a schedule, not a task you closed out.
What “known customer” means when you are the originating carrier
A-level attestation rests on a “known customer” relationship, and the framework deliberately does not hand you a rigid checklist for what qualifies. That flexibility is a trap if you treat it as permission to be vague. In practice, a defensible known-customer posture means you can produce, for any A-attested number, the evidence chain: how the customer was onboarded, how their identity was validated, how the number was assigned or ported to them, and how you confirmed their right to use it as calling party.
If a traceback request lands and you cannot reconstruct that chain for a number you A-attested, the attestation was aspirational. Small carriers that survive traceback scrutiny are usually the ones who built the evidence trail at provisioning time rather than trying to assemble it under a deadline. This connects to broader recordkeeping discipline — the same instinct that keeps your NECA settlement, LATA and FCC filing records intact through a switch modernization is the instinct that keeps your attestation evidence intact through a provisioning-system change.
A short operator checklist before you sign off on A-level
Not a compliance product, just the questions worth asking about your own originating traffic:
- Can your authentication service attest per-call based on the actual calling number, or only per-trunk? If only per-trunk, which customers does that assumption break for?
- For any A-attested DID, can you produce the assignment or port record and the authorization evidence within a traceback window?
- Does your provisioning flow verify number authorization at onboarding, or does it infer authorization from routing-table presence?
- Does your Robocall Mitigation Database entry describe what you actually do today, including any wholesale or foreign-origin traffic?
- When you cannot verify the number, does your platform fall back to B, or does it default to A because a downstream partner prefers it?
The caveat on the checklist: it is a starting point for an internal conversation, not a substitute for reviewing the current FCC requirements that apply to your specific carrier classification.
Where this is heading for small originators
Two pressures are worth watching. First, gateway and foreign-originated traffic obligations continue to tighten, which matters even for small domestic carriers the moment they touch any traffic that enters the U.S. network through them. Second, third-party and delegated authentication arrangements are becoming more common, and they do not transfer the underlying responsibility away from the originating carrier — outsourcing the signing does not outsource the claim. If you are considering a hosted authentication or delegate-certificate model, read the arrangement for who is on record for attestation accuracy, because it is very likely still you.
None of this changes the core operator takeaway: attestation is a statement you can be asked to defend, and the work that makes it defensible happens at provisioning and recordkeeping, not at the SBC. For the broader regulatory context around modernizing an independent telco without breaking your compliance posture, our ILEC vs CLEC carrier services overview is the pillar these operator posts build from, and the phased switch-migration playbook covers keeping authentication and attestation intact while you cut over.
Talk it through with a wholesale peer
If you are weighing how attestation, number authorization, and interconnection fit together on your network — or you want a second operator’s read on your origination setup — see our ILEC/CLEC interconnect options or talk to our wholesale team at 844-450-3527. This is a general operator-level overview; confirm the specifics that apply to your classification with your regulatory counsel before you file or change your attestation policy.
