STIR/SHAKEN Call Authentication and Its Impact on Routing

STIR/SHAKEN is a suite of cryptographic standards and regulatory mandates that assign verifiable attestation certificates to telephone calls traversing US voice networks, enabling carriers and downstream systems to confirm whether a caller ID has been legitimately authorized. The Federal Communications Commission mandated implementation across voice service providers under rules codified at 47 CFR Part 64, with compliance deadlines that began in 2021. The framework directly shapes how calls are accepted, flagged, or filtered before any call forwarding technology decision is executed, making its mechanics operationally relevant to every organization that relies on caller identity data to drive contact center or enterprise telephony logic.

Definition and scope

STIR/SHAKEN combines two distinct but interdependent specifications. STIR — Secure Telephone Identity Revisited — is defined by the Internet Engineering Task Force (IETF) in RFC 8226 and RFC 8588, which establish the use of JSON Web Tokens (JWTs) and X.509 public-key certificates to cryptographically sign caller identity assertions within SIP signaling. SHAKEN — Signature-based Handling of Asserted information using toKENs — is defined by the Alliance for Telecommunications Industry Solutions (ATIS) in standard ATIS-1000074, which specifies how US carriers implement STIR across Session Initiation Protocol infrastructure, including certificate management, token structure, and verification procedures.

The scope of mandatory deployment covers originating and terminating voice service providers operating in the United States. The FCC's Second Report and Order in Docket 17-97 established that large providers had to implement STIR/SHAKEN by June 30, 2021, with phased deadlines for smaller carriers extending into 2023. The framework applies to SIP-based call legs; calls traversing Time Division Multiplexing (TDM) segments that cannot carry SIP Identity headers are handled through robocall mitigation programs filed with the FCC's Robocall Mitigation Database rather than through full STIR/SHAKEN token attachment.

How it works

STIR/SHAKEN operates through a four-phase process that spans the originating carrier, a credential authority, the terminating carrier, and ultimately the receiving telephony system.

1. Token generation at the originating carrier. When a call is placed, the originating service provider evaluates whether it can verify the caller's right to use the displayed number. If verification is possible, the provider signs a PASSporT (Personal Assertion Token) — a JWT defined in RFC 8225 — and attaches it to the SIP INVITE message in an Identity header field.

2. Attestation level assignment. The originating provider assigns one of three attestation levels to the signed token:

3. Attestation A (Full Attestation): The provider has authenticated the customer and confirmed the customer is authorized to use the specific calling number.
4. Attestation B (Partial Attestation): The provider has authenticated the customer but cannot confirm the customer's right to use that specific number (common with enterprise SIP gateways presenting indirect numbers).

5. Attestation C (Gateway Attestation): The provider can only verify that the call entered its network at a specific gateway; no customer-level authentication is available.

6. Certificate verification by the terminating carrier. The terminating carrier retrieves the originating provider's public certificate from the Secure Telephone Identity Policy Administrator (STI-PA), operated under contract with the FCC. The terminating carrier validates the certificate chain and confirms the token has not been altered in transit.

7. Routing signal delivery. The verification result — along with the attestation level — is passed to the terminating system, where it can inform carrier-side call labeling (e.g., "Spam Likely"), enterprise telephony configuration, or call forwarding for contact centers that uses caller ID as a routing variable.

The Secure Telephone Identity Governance Authority (STI-GA), an industry body coordinated through ATIS, oversees the certificate authority ecosystem that underpins steps 2 and 3.

Common scenarios

Enterprise outbound calling. An enterprise using a SIP trunk to present a direct-inward-dial number it controls should receive Attestation A from a properly configured carrier, provided the carrier has verified number assignment. Misconfigurations — such as presenting a number not registered to the trunk's account — produce Attestation B or C, triggering spam labeling that reduces answer rates on outbound campaigns. This scenario is directly relevant to SIP trunking and call forwarding configurations.

Contact center inbound routing. Inbound calls carrying Attestation A can be used with high confidence to trigger skills-based routing rules tied to caller ID, such as routing a returning customer to their previous agent. Calls carrying Attestation C or no token at all cannot support the same trust level, requiring routing logic to treat the presented number as unverified.

Toll-free number traffic. Toll-free originations often traverse multiple carrier hops before reaching a terminating network. Each intermediate carrier that cannot carry the original SIP Identity header forward — particularly across TDM segments — breaks the attestation chain, producing Attestation C or a missing token at the terminating side. Toll-free number routing designs must account for this degradation when building caller-ID-dependent logic.

Robocall mitigation overlap. Calls from providers enrolled only in the FCC's Robocall Mitigation Database rather than full STIR/SHAKEN implementation carry no cryptographic token. Terminating carriers and enterprise systems must apply separate mitigation policies to this traffic class, which falls outside the attestation framework entirely.

Decision boundaries

The attestation level embedded in a verified STIR/SHAKEN token establishes a trust gradient that routing systems can act upon. The table below summarizes operational implications:

The distinction between Attestation A and Attestation B is operationally significant for priority-based call forwarding and financial services call forwarding, where caller identity underpins regulatory compliance or fraud-detection thresholds. An enterprise SIP gateway presenting a number not directly registered to the originating carrier account will receive Attestation B not because the call is fraudulent, but because the carrier's verification scope is structurally limited.

call forwarding compliance in the US requires organizations to understand which attestation level their originating carrier assigns to their outbound traffic. A mismatch between presented caller ID and attestation level produces carrier-side labeling that suppresses answer rates and corrupts inbound routing logic built on caller identity signals.

STIR/SHAKEN does not itself block calls. The framework generates a cryptographically verifiable signal. Enforcement authority — whether to block, label, or route differently — rests with terminating carriers acting under FCC robocall mitigation rules and with enterprise telephony administrators who configure routing policies. The PASSporT token is a trust input, not a gatekeeping mechanism, and call forwarding security and fraud prevention strategies must treat it as one signal among multiple verification layers rather than a binary pass/fail control.

References

• IETF RFC 8226 — JSON Web Token Claims for STIR
• IETF RFC 8588 — Personal Assertion Token (PASSporT) Extension for SHAKEN
• IETF RFC 8225 — PASSporT: Personal Assertion Token
• FCC — STIR/SHAKEN and Robocall Mitigation
• FCC — 47 CFR Part 64 (Electronic Code of Federal Regulations)
• ATIS — SHAKEN Governance and Standards (ATIS-1000074)
• FCC Robocall Mitigation Database