STIR/SHAKEN Compliance: 5 Provider SIP Steps for AI Contact Centers

STIR/SHAKEN compliance requires voice service providers to cryptographically sign and verify caller identity on every call path they originate or carry, authenticating the calling provider rather than the caller’s intent. The FCC mandates this under the IETF’s STIR framework and the ATIS SHAKEN profile. We recommend every obligated provider inventory its origination paths now and register with the STI-PA for an SPC token before building a signing and verification pipeline.

TL;DR:

• Use A after verifying customer identity and number rights, B when the customer is known but number rights are not, and C for gateways.
• Verification failures usually do not require call blocking: follow local policy, complete calls where permitted, and log error codes and carrier details for later traceback.
• Provider classifications determine whether direct registration with the STI Policy Administrator is required or a contracted signing partner may be used; confirm deadlines with each regulator.
• International gateways may provide C attestation or no signature, and trust does not cross borders automatically; monitor these routes for fraud and coordinate with partners.

What STIR and SHAKEN Are and What They Cover

STIR, Secure Telephone Identity Revisited, is an IETF protocol family that defines how a cryptographic signature travels with a call. SHAKEN, the Signature-based Handling of Asserted toKENs framework, is the ATIS-published profile that tells providers how to apply STIR within SIP networks, under ATIS-1000074. Together they authenticate the signing provider and its attestation claim about a call, not the caller’s identity or purpose.

Each signed call carries a PASSporT, a compact token containing claims such as the originating and destination numbers, a timestamp, and an attestation level. That token rides inside the SIP Identity header of the call setup message, giving the terminating provider a verifiable record of who signed the call and when.

Providers building or auditing a compliance program should keep these references on hand:

• IETF RFCs 8224, 8225, and 8588 for the core STIR protocol and PASSporT structure.
• ATIS-1000074 for the SHAKEN profile and its PASSporT extension claims.
• STI-GA guidance for attestation definitions and governance expectations.
• FCC orders for the regulatory mandate and filing obligations.

STIR/SHAKEN authenticates the network path a call traveled through, which is a narrower and more useful guarantee than authenticating what the caller intends to say.

How STIR/SHAKEN Works: Step-by-Step Signing and Verification Flow

The signing and verification sequence runs the same way across most SIP networks, though the party responsible for signing shifts depending on who originates the call.

1. The originating provider assigns an attestation level (A, B, or C) based on what it knows about the customer and the calling number.
2. It builds a PASSporT token containing the calling number, called number, timestamp, and attestation claim.
3. The provider signs that token using the private key tied to its SPC token certificate, issued through the STI-PA.
4. The signed PASSporT is attached to the outbound SIP INVITE as an Identity header.
5. The terminating provider’s verification service retrieves the signing certificate, checks it against the STI-PA trust anchor, and validates the signature and timestamp before the call completes.

Signing typically happens at the originating switch, at a session border controller acting as a gateway, or at a third-party signing service under contractual obligation to the carrier of record. Verification happens at the terminating provider, usually at the edge of its network before the call reaches a subscriber or an automated answering system.

Attestation decisions depend on operational inputs the signing provider must have in place: verified customer identity, telephone number assignment and validation records, and screening against Do Not Originate lists for numbers known to be spoofed. A provider that cannot confirm the customer’s right to use a number should assign attestation B or C rather than A.

Pro Tip: Build attestation logic as a rules engine tied to your customer provisioning system, not a static lookup table, so attestation levels update automatically when customer status or number assignment changes.

Regulatory Requirements, Governance, and Registration

Compliance obligations trace back to the FCC’s caller ID authentication mandate, which required larger voice service providers to implement STIR/SHAKEN on IP networks first, with smaller and non-facilities-based providers following on separate timelines. Providers should confirm their current obligations and deadlines directly with their regulator rather than relying on a general summary, since enforcement schedules and carve-outs for smaller operators have shifted since the original order.

Governance of the certificate ecosystem runs through the STI-Governance Authority, which sets policy, and the STI-Policy Administrator, which issues the Service Provider Code tokens that let a provider sign calls. Registration starts at the STI-PA, where a qualified provider or certificate authority submits documentation to establish eligibility before receiving an SPC token, a process the STI-GA FAQ walks through for newly obligated carriers.

• Confirm whether your provider classification requires direct STI-PA registration or permits reliance on a signing partner under contract.
• Budget time for documentation review; SPC token issuance is not instantaneous.
• Track certificate renewal dates alongside your HSM or certificate authority relationship to avoid signing gaps.

STI-GA governance documentation defines attestation semantics and revocation procedures for SPC tokens, which matters because a revoked token stops a provider from signing calls until it resolves the underlying compliance issue.

Jurisdictions outside the United States run their own timelines. Canada’s CRTC has imposed its own STIR/SHAKEN adoption requirements with multiple deadline adjustments distinct from the FCC schedule, so a provider operating across borders needs to track each regulator separately rather than assuming one filing satisfies every market.

Implementation Checklist: Practical Tasks for Engineering, Operations, and Compliance

Turning STIR/SHAKEN from a regulatory requirement into a working system takes coordinated work across engineering, operations, and compliance teams.

1. Inventory every call origination path, including direct trunks, resellers, and wholesale partners, and assign signing responsibility for each.
2. Register with the STI-PA and obtain an SPC token, then establish a certificate lifecycle process backed by a hardware security module or trusted certificate authority.
3. Integrate signing logic into the SIP INVITE pipeline at the point closest to call origination, and configure verification services at the terminating edge with full logging for traceability.
4. Define monitoring and alerting rules for verification failures, and route them into a ticketing workflow that supports industry traceback requests.
5. Build a test plan covering interoperability with major carrier partners, then schedule recurring reviews of attestation policy as customer onboarding and number provisioning change.

Teams managing outbound dialing operations should treat attestation policy as a living document tied to campaign compliance, not a one-time engineering task; our guide to compliant outbound dialing covers the operational priorities that intersect with signing decisions. Providers evaluating where to run signing infrastructure, particularly the HSM or CA relationship that protects private keys, benefit from mapping those controls against established frameworks, which our contact center security guidance addresses directly.

Pro Tip: Log every verification failure with its error code and originating carrier, even when policy allows the call to complete, so your traceback team has a record ready when a regulator or partner asks for it.

Attestation Levels, Verification Outcomes, and Error Handling

Attestation A means the signing provider has authenticated the customer and confirmed the right to use the calling number, the strongest claim a provider can make. Attestation B applies when the provider has a verified customer relationship but cannot confirm the calling number itself, common for enterprise PBX trunks. Attestation C applies when the provider only knows the call entered its network from a known source, typical for international gateway traffic with no visibility into the original caller.

A terminating provider that receives a signed call does not automatically block anything. Most networks label or warn on unverified or low-attestation calls while still completing them, reserving blocking for cases where local policy or regulation explicitly permits it.

Common verification error codes tell operations teams what went wrong and how to respond:

• 403 indicates a stale date in the PASSporT, suggesting clock drift or delayed delivery.
• 436 signals bad identity info, often a malformed or corrupted token.
• 437 means the verifier does not support the credential presented.
• 438 flags an invalid identity header structure.

ATIS interoperability guidance recommends treating these failures as unverified caller ID and completing the call where policy permits, while logging the failure reason for offline remediation rather than blocking outright on every verification error.

Interoperability and Cross-Border Practicalities

Every signature’s value depends on the terminating provider trusting the signing certificate’s chain back to the STI-PA root, a trust relationship that does not automatically extend across national borders or into networks outside the US framework. International gateways and calls from providers with no SHAKEN participation typically arrive with attestation C or no signature at all, since the gateway can only attest to the fact that a call entered its network, not to anything upstream.

Practical mitigations for these gaps include:

• Participating in industry traceback efforts when unverified traffic patterns emerge from a specific partner or gateway.
• Flagging gateway-attested traffic for closer fraud monitoring rather than treating it the same as fully authenticated domestic calls.
• Documenting exceptions and coordinating directly with peering partners and the STI-PA when a legitimate route cannot achieve higher attestation.

Vendors managing multi-site telephony should ask their carriers directly how spoofing prevention and attestation handling work across those gateway points; a vendor question checklist for caller ID spoofing is a useful starting point for that conversation.

Voiceracx Perspective: Bringing Verification Metadata Into Contact Center Workflows

We see signing and verification metadata as data that should reach agent desktops and routing logic, not stay buried in SIP headers. Surfacing attestation level and verification status to an AI routing engine lets a contact center prioritize or flag calls without adding friction to the customer experience. Our platform supports this across cloud, private cloud, and on-premise deployments, which matters for regulated organizations that need governance and auditability over how that metadata is stored and used. Teams exploring where to host this kind of sensitive call data can compare the trade-offs in our cloud versus on-premise deployment guide.

— Voiceracx

Let Verification Metadata Work for Your Contact Center

Signing and verifying calls solves authentication. What happens next, how that attestation data informs routing, agent context, and fraud screening, depends on the platform behind your contact center. We built our AI voice and chat agent platform to ingest call metadata, including verification status, and route it into agent desktops and automated workflows without slowing down the call.

Our Vee Enterprise product line supports cloud, private cloud, and on-premise deployment for organizations that need to keep signing infrastructure and call metadata inside their own governance boundary. For providers running outbound campaigns alongside inbound compliance obligations, Vee Dialer integrates attestation-aware signing into the outbound stack.

Our plans start at Basic for $199 per month, with Standard, Advance, and Pro tiers available as your automation needs scale, plus a pay-as-you-go option and a free tier for teams getting started. Explore our Cloud Contact Center platform to see how verification data and AI routing work together in practice.

FAQ

Should I Be Worried if My Number Is Being Spoofed?

Spoofing is worth taking seriously because it can damage your reputation and trigger unwanted calls to your own line. Report confirmed spoofing to your carrier and consider registering the number for stricter attestation handling with your provider.

What Is STIR/SHAKEN Technology?

STIR/SHAKEN is a framework that lets voice providers cryptographically sign calls so the receiving network can verify which provider originated them. It uses the IETF’s STIR protocol and the ATIS SHAKEN profile to attach a signed token to each call’s SIP setup message.

How Can I Make My Caller ID Show a Different Number?

Changing the number displayed on outbound calls is generally only appropriate when you have the legal right to use that number, such as a business line or a verified alternate contact. Providers assign lower attestation levels to calls where the right to use a number cannot be confirmed, so legitimate number display changes should go through your carrier’s verified provisioning process.

Does *57 Still Work?

*Call trace remains available through many carriers as a way to flag a harassing or threatening call for law enforcement follow-up, separate from STIR/SHAKEN verification. It does not identify a spoofed number directly; it creates a record your carrier can use if you pursue a formal complaint.

Sources

• ATIS-1000074.v003: Signature-based Handling of Asserted toKENs (SHAKEN)
• Interoperability standards between NGN for SHAKEN
• Orrick: FCC finalizes rule strengthening robocall mitigation database filing requirements

Recommended

• Map HIPAA to Phone Systems, Recordings, and AI for Healthcare Contact Centers
• Map PCI NIST & VOICERAcx to Contact Center Security for Regulated Orgs
• From 1% to Full Coverage: QA Automation for Regulated Contact Centers
• Cut PCI DSS Call Center Scope by 96% With DTMF Masking