STIR/SHAKEN Attestation Levels Explained: A, B, and C

The STIR/SHAKEN framework assigns one of three attestation levels to every signed call: A (Full), B (Partial), or C (Gateway). These three letters get debated in industry forums, misread by ops engineers, and quietly mis-assigned by providers who never had to think about them until an upstream carrier dropped their traffic from A to C. The letters look simple. The criteria, the consequences, and the way they travel through downstream networks are not.

This article is a reference. It explains what each level actually means per the ATIS-1000074 standard, where the level lives on the wire, who assigns what in which scenario, how a received attestation behaves downstream, and the common mis-attestations that quietly damage call completion. If you need the operational playbook for moving your traffic to A-level, the A-Level Attestation Guide covers that. If you need the SBC configuration walkthrough, the Implementation Guide covers that. This piece is for the question that sits underneath both: what does each level mean, and what does an originating provider actually claim when they sign at A, B, or C?

What Attestation Actually Is (and Three Things It Is Not)

Before walking through the three levels, it helps to clear up what attestation actually represents. The word gets used loosely, and the loose usage drives most of the confusion.

Attestation is a self-declaration by the originating provider. When your SBC signs an outbound call, your provider’s certificate is what creates the signature, and your provider chooses the letter that goes into the attest claim. No one else verifies that you chose correctly at the moment of signing. The level you stamp is your statement about your knowledge of the call.

Attestation is not a verification. An A-level call has been signed by the originating provider, not validated by an independent third party. Verification happens later, on the terminating side, and verification only confirms that the signature is cryptographically valid and the certificate chain is trusted. It does not second-guess the originating provider’s attestation decision. If a provider signs a call at A-level when they had no business doing so, verification will still pass. The accountability sits with the originating provider, enforced through FCC oversight rather than cryptographic validation.

Attestation is not a spam score. Analytics engines (the systems that display “Scam Likely” or “Spam Risk” on the recipient’s phone) consume attestation as one input, but they combine it with calling-pattern data, reputation history, number-block age, and dozens of other signals. A call signed at A-level can still get flagged by an analytics engine if the originating number has a poor reputation. A call signed at C-level can still complete cleanly if the receiving carrier’s policy is lenient. The level is one signal in a multi-signal decision.

Attestation does not live in the SIP From header or the PAI. The level is carried inside a signed JSON token (the PASSporT) inside the SIP Identity header. The From and P-Asserted-Identity headers are still where the calling number appears, but they are unsigned and trivially spoofable. The whole point of STIR/SHAKEN is to bind the calling number and the attestation level together cryptographically so they cannot be edited in transit. If your engineering team is debugging an attestation problem by looking at the From header, they are looking in the wrong place.

Where the Level Lives: The attest Claim Inside the PASSporT

The attestation level is one field inside the PASSporT, the signed token at the heart of every STIR/SHAKEN-signed call. The PASSporT is a JSON Web Token (JWT) that holds five core claims defined by ATIS-1000074:

The decoded payload of a real PASSporT looks roughly like this:

{
  "attest": "A",
  "dest": { "tn": ["14165550100"] },
  "iat": 1748964123,
  "orig": { "tn": "14165550199" },
  "origid": "ab37e29c-4c84-4f6e-bb50-1f9f8e2dc4ad"
}

The whole token is signed with the originating provider’s private key, encoded as a JWT, and placed inside the SIP Identity header on the outbound INVITE. Downstream networks read the Identity header, decode the PASSporT, and act on the attest field. Whatever single character the provider put there is the attestation the entire downstream chain sees.

The Three Attestation Levels per ATIS-1000074

The published standard defines three discrete levels. Each one answers two questions: does the provider know who the calling party is, and does the provider know that the calling party is authorized to use the calling number? The combination of answers determines the level.

A (Full Attestation)

The criteria are strict. A-level applies when the originating provider has authenticated the calling party, has a direct relationship with that party, and has verified that the party is authorized to use the calling number presented in caller ID. All three conditions must be true. A direct customer relationship without number authorization is not A-level. Number authorization without authenticated identity is not A-level.

In practice, A-level is the bar a retail voice provider can meet for their own subscribers, an IP-PBX vendor can meet for the DIDs they have assigned, and a managed service provider can meet for their managed customers’ verified numbers. It is the bar a wholesale carrier passing transit traffic cannot meet for traffic that did not originate on their network.

B (Partial Attestation)

The criteria are looser. B-level applies when the provider knows where the call entered their network (it came from a known, authenticated trunk or peer) but has not independently verified that the specific calling party is authorized to use the specific calling number. The provider is vouching for the trunk, not for the number-to-caller binding.

This is the level a wholesale carrier assigns to traffic from a known reseller whose end-customer authorization records the wholesaler cannot see. The wholesaler knows the reseller. The wholesaler cannot independently confirm that the reseller has done KYC and number-authorization checks on every call. B-level is the honest answer for that scenario.

C (Gateway Attestation)

The criteria are minimal. C-level applies when the provider is acting as a gateway for traffic that originated outside its trust domain. The provider can identify the point where the call entered its network but cannot authenticate the original calling party or verify authorization for the calling number.

This is the level that applies at PSTN-to-IP gateways, at international interconnects where the upstream provider does not authenticate their users, and in some cases at retail providers receiving traffic from a tenant whose customer records they do not maintain. C-level represents the accurate level for an honestly described untrusted source, and treating it as a failure mode misreads what the standard intends.

The Three Levels Side by Side

Reduced to the two questions every level answers:

The deliberate gap between A and B is the verification of number authorization. The gap between B and C is the verification of the trunk or peer itself. Two distinct hurdles, three distinct levels.

Worked Scenarios: Who Should Assign What

The honest level for a given call depends on the provider’s relationship to the originator. The following scenarios are representative of the call types that arrive at a typical Session Border Controller (SBC) in production.

Scenario 1: A Retail VoIP Provider Signing Subscriber Traffic

A residential VoIP provider receives an outbound call from a subscriber whose identity they verified at sign-up, on a DID they assigned from their own inventory. They know who the caller is. They know the number is theirs to assign. A-level is the accurate attestation.

Scenario 2: An MSP Delivering Microsoft Teams Direct Routing

A managed service provider hosts Microsoft Teams Direct Routing for a customer whose tenant they manage, on numbers they ported in with documented LOAs. The MSP authenticates the customer at the SBC trunk level and maintains the porting records. A-level is the accurate attestation for those numbers. If the same MSP terminates calls from a numbering range the customer brought in without porting documentation, those calls drop to B-level until authorization is confirmed.

Scenario 3: A Wholesale Carrier Passing Reseller Traffic

A wholesale carrier receives traffic from a downstream reseller who has their own end-customer relationships. The wholesaler authenticated the reseller trunk and knows the reseller, but the wholesaler does not maintain KYC records on the reseller’s end customers and cannot confirm individual number authorizations. B-level is the honest answer. The reseller, if they sign the same call upstream of the wholesaler with their own certificate, may legitimately stamp it A.

Scenario 4: An IP Gateway Receiving International Traffic

A gateway provider terminates traffic arriving over an international interconnect from a foreign carrier who does not implement STIR/SHAKEN and does not authenticate their downstream users. The gateway provider can confirm the trunk arrived from the foreign carrier, but nothing more. C-level is the accurate attestation for traffic arriving on that interconnect.

Scenario 5: A Contact Center BPO Originating Outbound Campaigns

A BPO contact center originates outbound calls on behalf of multiple end clients, using DIDs assigned by an upstream voice provider. The BPO authenticates its agents and knows which campaign and client each call belongs to. The attestation question is whether the upstream voice provider (the one whose certificate signs the calls) considers the BPO an authenticated customer with verified number authorization. If yes, the upstream signs the outbound traffic at A-level. If the upstream cannot confirm the BPO’s authorization for the specific number presented, the level drops to B.

Scenario 6: An Enterprise PBX Calling Through a Carrier Trunk

An enterprise customer with their own PBX places outbound calls through a SIP trunk provided by a carrier. The carrier authenticated the trunk to the enterprise and has the porting documentation for the enterprise’s numbers. A-level is appropriate for calls placed from authorized numbers in the assigned range. Calls placed with caller ID outside the assigned range drop to B or fail authorization and should not be signed at A.

How a Signed Attestation Reaches Downstream Networks

The attestation level is set once, at signing, by the originating provider. From that moment, it travels through every downstream hop inside the signed PASSporT. The PASSporT is signed using the originating provider’s STIR/SHAKEN certificate, so any tampering with the attest field invalidates the signature.

The downstream journey looks like this:

1. The originating SBC requests signing from the STI-AS, which creates the PASSporT with the chosen attest value, signs it with the provider’s certificate, and returns the Identity header.
2. The originating SBC injects the Identity header into the outbound SIP INVITE and forwards the call to the next hop.
3. Each intermediate carrier passes the SIP INVITE forward, preserving the Identity header. They cannot legitimately modify the attest field without breaking the signature.
4. The terminating SBC receives the INVITE, extracts the Identity header, and forwards it to the verification service (STI-VS).
5. The STI-VS validates the signature against the originating provider’s public certificate, checks the certificate chain back to the STIR/SHAKEN Certificate Authority, and confirms the token is fresh and unmodified. It returns the verification result alongside the original attest value (typically via the verstat parameter in the P-Asserted-Identity header).
6. The terminating provider’s policy engine reads the verstat and the verified attest, then applies routing decisions: route normally, flag, screen further, or reject.
7. If an analytics engine sits in front of the destination handset (a common configuration for U.S. mobile carriers), it consumes the verified attestation as one input into its “Scam Likely” or “Spam Risk” scoring.

The Identity header is the only on-the-wire artifact that carries the attestation. If it is missing, downstream networks treat the call as unsigned, which is functionally similar to C-level for analytics purposes. If it is present but verification fails, downstream networks know the call was tampered with or signed by an untrusted certificate, which is typically worse than no signature at all.

Reading a Received Attestation: What an A Actually Tells You

When your SBC verifies an inbound call and reads attest=A, that single character is making a specific claim. Translated into plain English: the originating provider declares that they authenticated the calling party and verified the calling party is authorized to use the calling number.

That is the claim. The verification confirms two things only: the signature is valid, and the certificate chains back to a trusted Certificate Authority. It does not confirm that the originating provider’s KYC procedures are sound. It does not confirm that the originating provider verified number authorization correctly. It does not confirm that the calling party is actually who they say they are. Those are all the originating provider’s promises, backed by FCC regulatory accountability rather than cryptographic proof.

The practical consequence is that an A from a reputable U.S. retail carrier is a much stronger signal than an A from a provider you have never heard of. The cryptographic content is identical. The reputational backing behind it is not. This is why some terminating carriers maintain their own provider-reputation lists alongside the attestation levels and why analytics engines weight attestation as one input among many.

The same logic applies to B and C. A received B-level call carries an explicit acknowledgment from the originating provider that they could vouch for the trunk but not for the specific number authorization. A received C-level call carries an explicit acknowledgment that the provider is a gateway with no direct knowledge of the caller. The signal value of attestation comes from honesty about the relationship to the call, and that honesty is what downstream networks reward or punish through routing policy.

Common Mis-Attestations and What They Reveal

Mis-attestation happens in both directions: over-attesting (claiming a higher level than the criteria support) and under-attesting (claiming a lower level than the criteria support). Each tells you something useful about the originating provider.

Over-Attesting C Traffic as A

A provider that signs gateway traffic at A-level is making a claim they cannot defend. The FCC has been increasing enforcement on inaccurate attestation, and downstream analytics engines that detect a pattern of A-level calls from a provider that consistently behaves like a gateway will weight that provider’s future attestations down. Over-attestation tends to be a short-lived strategy. It either invites regulatory scrutiny or it gets neutralized by reputation systems.

Under-Attesting A Traffic as C

This is the pattern that prompted the wave of self-attestation in 2024 and 2025. An upstream wholesaler whose KYC and number-authorization records on downstream resellers are incomplete may decide that B or C is the only honest level for all reseller traffic, regardless of how much KYC the reseller themselves has done. The reseller’s customers then see their calls flagged or blocked even though the calls would qualify for A if signed by the reseller directly. The fix, covered in the A-Level Attestation Guide, is for the reseller to obtain their own certificate and sign their own traffic at the level they can defend.

Mixing Levels on the Same Trunk

A single SBC often handles mixed traffic: retail subscriber traffic that qualifies for A, wholesale traffic that qualifies for B, and gateway traffic that qualifies for C. The attestation decision is per-call, not per-trunk. An SBC that assigns a blanket level to everything on a trunk will either over-attest the gateway traffic or under-attest the retail traffic. Both are wrong. The per-call attestation capability of a programmable SBC is what lets the same instance handle all three honestly.

Signing with a Third Party’s Certificate

This is no longer an attestation choice; it is a compliance violation. The FCC’s own-certificate rule requires every provider with a STIR/SHAKEN obligation to sign with their own certificate. A call signed at A-level using an upstream’s certificate is non-compliant regardless of how accurate the attestation itself is. Downstream networks that detect this pattern increasingly treat it the same as no signature at all.

How Downstream Treatment Varies by Level

Downstream treatment is policy, not protocol. Terminating providers and analytics engines decide what to do with a verified attestation, and those decisions vary by carrier, by recipient device, and by call pattern. The patterns below are representative of what U.S. mobile carriers and major terminating providers do today, not a guarantee.

A-Level Treatment

Calls signed at A-level from a reputable originating provider typically reach the recipient with no analytics-engine label and a clean caller ID. If the originating number has a poor reputation (history of complaints, recent number recycling, mass-dialing patterns) the call may still be labeled. Attestation is a positive signal, not an override.

B-Level Treatment

B-level calls usually reach the recipient but may receive a neutral label (“Caller Verified” rather than the negative “Scam Likely”) depending on the terminating carrier’s UI conventions. Some carriers do not differentiate B and A in their user-facing display. Others treat B as ineligible for any positive label.

C-Level Treatment

C-level calls receive the least favorable treatment. They are most likely to be labeled “Scam Likely” or “Spam Risk”, and a growing number of terminating carriers route C-level traffic into more aggressive screening pipelines. Some carriers reject C-level calls outright under specific conditions, particularly for traffic patterns that resemble robocalling.

Unsigned or Verification-Failed Calls

Calls arriving with no Identity header (unsigned) or with an invalid Identity header (verification failed) are typically treated worse than C-level signed traffic. C-level at least represents an honest gateway declaration; unsigned or invalid traffic represents either a non-compliant provider or active tampering, and downstream networks increasingly route both into the same aggressive-screening bucket.

Quick Reference: Which Level to Assign in Common Scenarios

The table below summarizes the honest attestation for each common provider role and traffic type. It is a starting point, not a substitute for case-by-case judgment.

The decision logic is consistent across all rows: identity check produces yes or no, authorization check produces yes or no, and the combination yields the level. Two yeses give A, one yes gives B, zero yeses gives C.

The Role of the SBC in Assigning the Right Level

The attestation decision is the provider’s, but the SBC is where the decision is operationalized. Every signed outbound call passes through the SBC’s signing flow, where the call’s metadata is packaged into a signing request, sent to the STIR/SHAKEN signing service, and returned as an Identity header. The level that gets stamped depends on what the SBC tells the signing service to claim.

A static, per-trunk attestation setting cannot get this right when the same trunk carries mixed traffic. Per-call attestation logic in the SBC routing engine is what allows the same instance to sign retail subscriber traffic at A, wholesale transit at B, and gateway traffic at C, on a call-by-call basis, using the same certificate. ProSBC implements this through its configurable Ruby routing engine, where the attestation decision can incorporate any data the routing script can access: the calling number’s record in the number-authorization database, the trunk it arrived on, the customer’s KYC status, the time of day, or any other input the provider chooses to factor in.

The configuration mechanics for ProSBC’s SIP-based integration with TransNexus ClearIP and Neustar (the production-deployed pattern for the company’s customer base) are covered in the Implementation Guide. The relevant point for attestation specifically is that the level is a per-call decision the routing engine makes, not a global parameter set once on the SBC.

Frequently Asked Questions