For many service providers offering service in the United States, June 30, 2023 has been a looming deadline. It's the date at which every Voice service provider in the USA is required fully implement the STIR/SHAKEN framework. But many providers are stopping short of full implementation -- and running a risk of an enforcement investigation from the FCC.
STIR/SHAKEN is a framework required by the FCC for combating illegal caller ID spoofing on IP-based voice networks. The goal is to increase trust in phone calls by verifying that the caller ID is accurate and hasn't been tampered with.
To comply with STIR/SHAKEN, a Voice Service Provider must do two things:
Sign outbound SIP calls with an Identity header that includes a PASSporT and attestation level (A, B, or C).
Verify inbound SIP calls by decoding and checking Identity headers from other providers.
Full compliance also involves internal decisions—such as how to handle attestation, where to insert headers in the network, and how to manage customer number validation (KYC).
STIR/SHAKEN compliance is more than just a technical upgrade, it’s a legal and operational requirement. The FCC has made it clear that failure to comply may result in investigations, enforcement actions, or removal from trusted call termination databases.
For service providers, full compliance builds trust in your call traffic, reduces your risk of being labeled a robocaller enabler, and keeps you in good standing with interconnect partners. Non-compliance, on the other hand, can lead to penalties or call blocking by other networks.
STIR/SHAKEN is not optional if you operate in the U.S. telecom space, it’s table stakes.
For Voice engineering teams, the most visible part of STIR/SHAKEN is the Identity. It's a value sent to other companies when the phone call is setup, as a SIP header. But behind sending Identity are many other decisions...
This article is written for Voice Service Providers to discuss these questions and help you see if you're fully compliant.
What level of attestation should we be using? A, B, or C?
In the Identity header, there's an encoded value called a PASSporT. The PASSporT was created for a single phone call, and inside it has a single attestation value: A, B, or C. I paraphrase the attestation levels for a Service Provider like this.
A (Full): Provider knows both the caller identity and controls number assignment. Te originating service provider has verified the identity of the caller and their right to make calls from a certain number.
B (Partial): Identifies caller but not authorized number use (e.g. enterprise PBX). The originating service provider knows the identity of the customer, usually a business, but does not know whether they have the right to place calls from the telephone number.
C (Gateway): Only knows where call entered, not caller info, common for international traffic.
Do we know if our customers have the right to use the phone numbers they're using?
This question gets to the "Know Your Customer" (KYC) problem. What do you know about your customers, and how do you go about learning it? You can watch many presentations on this topic at SIP Forum's June 2023 KYC Summit. The problem space varies widely among service providers.
In the "simplest" case, you can typically be happy to choose the "A" attestation level. Happily, that aligns well with the wording of the federal TRACED law, which desires Service Providers to provide the strongest level of proof of the identity of their callers.
If you have customers in the "hardest" category, then choosing the attestation level can be quite hard! You may need technology to determine which calls they're placing from numbers assigned directly to them to choose the "A" attestation level. There is no universal registry of telephone numbers, nor is there a standard way of proving ownership of a telephone number. Combine this with other obligations that service providers must take affirmative steps to prevent their customers from placing illegal calls of any kind, and the administrative workload for service providers has increased substantially. A customer with a SIP trunk allowing them to call from any telephone number should expect to pay more than a SIP trunk that uses "number screening" to limit the telephone numbers they can use.
In what parts of our network do we have to implement STIR/SHAKEN? (Meaning: do we have to have Identity headers everywhere)?
Service Providers have to implement STIR/SHAKEN in all of the SIP portions of their network, but that doesn't necessarily mean they have to add Identity headers throughout.
If you have a simple network, the "User-Network Interface" may simply be used for device management and authentication (i.e., SIP REGISTER, 401, REGISTER with Authorization, then 200). That authentication itself allows you to satisfy some of the STIR/SHAKEN requirements by clarifying precisely which legal person/corporation your system is communicating with. If you have a set of SBCs, and few synchronized calling servers (like BroadSoft/BroadWorks Application Servers linked with a single Network Server, or a single Metaswitch MaX platform, or a single Crexendo/NetSapiens cluster), then it's likely all the context about the identity of the caller is kept in one place. That simplifies the process of tracking the identity of the caller.
If you have a larger network or a more distributed architecture, a call may enter your network on one entry point and be routed several times before ultimate termination. In this case, you may need to track context, like "Where did the call enter our network?" and "Do we trust the caller's right to place a call from this telephone number?". For those purposes, tagging headers like those described by Metaswitch's Austin Spreadbury can be useful.
What do we have to do to "fully implement" STIR/SHAKEN?
Everyone quickly becomes aware of the need to send SIP INVITE's with the Identity header. But the FCC is strict about the need to analyze incoming Identity headers. One major US service provider was put in the penalty box for failing to verify all calls entering its network.
Vonage claims that it “completed all necessary network upgrades to its network infrastructure to be able to authenticate and verify caller ID information for calls exchanged with STIR/SHAKEN-enabled partners by June 30, 2021.” However, Vonage also explains that only “50% of inbound SIP calls [are] being validated as of today,” and that it is “coordinating with . . . partners and expects to expeditiously re-enable inbound processing of STIR/SHAKEN identification headers.” We [the FCC] find that this gap in Vonage’s use of STIR/SHAKEN falls short of the Commission’s requirement that a provider have “fully implemented the STIR/SHAKEN authentication framework” to maintain the exemption in section 64.6306(e). We conclude that this section must be read in light of section 64.6301(a), which defines the requirements for a voice service provider to “fully implement the STIR/SHAKEN authentication framework” in the first instance. In section 64.6301(a), the Commission requires a voice service provider to, among other things “verify caller identification information for all SIP calls it receives from another voice service provider . . . which it will terminate and for which the caller identification information has been authenticated.”
This FCC order is notable because it makes clear that service providers are required to verify incoming Identity headers—even if they don’t take any further action based on the results. In other words, compliance doesn’t depend on what you do with the data, but rather on the fact that verification must occur.
The verification process includes several key steps:
Even without defined outputs or required actions based on the verification result, performing the process itself is a non-negotiable part of STIR/SHAKEN compliance under FCC rules.
A service provider can use the data as part of a program of blocking inbound nuisance calls. If a service provider does so, and uses that to block calls, then there are obligations for logging that data and providing for remediation. (I.e., callers have to be able to contact the blocking service provider.) In addition, certain SIP response codes must be used -- 603, 607, or 608 -- when blocking like this is done.
If your network or procedures include any of the above, now is the time to fix them, before an investigator calls.
Nobody I know wants to be on the side of the illegal robocallers. Don't put yourself in the position to be caught by the FCC for non-compliance. When you're implementing STIR/SHAKEN, do a thorough job, both carefully "Knowing your Customer," sending proper attestations, and verifying inbound calls.
STIR (Secure Telephone Identity Revisited) is an IETF standard (RFCs) defining how to sign/verify calls using PASSporTs. SHAKEN (Signature-based Handling of Asserted information using toKENs) is the ATIS/SIP profile that specifies how STIR is implemented in carrier-grade IP voice networks.
The originating provider signs outbound calls with a PASSporT including attestation (A/B/C) and timestamp. The terminating provider must decode it, fetch the public cert, verify the signature, and compare the claims - even if they don’t take action
Some providers believe they only need to sign calls - not verify inbound ones. In reality, verification is legally required even if no action is taken, and consumers may not see any visual indicator.
No, it authenticates the call origin and how confident the originating caller is about the right of the number to be used. It is not capable of signaling intent. A call could be A-level signed but still scammy.
Yes, scammers may game attestations via upstream providers or misassigned A-level without actual KYC.
All portions of telecom networks that use VoIP must use STIR/SHAKEN.\
Resellers must obtain their own certificate, implement signing, and update Robocall Mitigation Plans by June 20, 2025 - no longer can depend on downstream signatures.
ATIS and Neustar offer a testbed to confirm SHAKEN interoperability, as differing STIR implementations can break verification. But for many first-generation STIR/SHAKEN platforms there has been no testing! Many Identity headers fail verification.
No, only providers at network edge do. If a PBX or call center wants higher attestation, they must work through a compliant provider. This is especially important for Branded Caller ID (BCID).
The FCC can audit telecom records, demanding to know whether Voice service providers are properly functioning for attestation and verification. In addition, techniques exist to detect whether STIR/SHAKEN is implemented and operating
The FCC’s Eighth Report and Order (2025) prohibits third-party call-signing certificates for compliance in the Robocall Mitigation Database. Risks of third-party reliance include:
Providers must transition to proprietary signing servers to remain compliant.
The STI-GA, under ATIS, oversees the STIR/SHAKEN framework by:
Out-of-band SHAKEN is an extension of STIR/SHAKEN designed for calls that traverse traditional TDM/SS7 segments where SIP signaling - and thus PASSporTs - don’t travel. It allows call authentication tokens to be published to and retrieved from a Call Placement Service (CPS), ensuring verification survives the TDM portion of the call.
The originating or transit provider publishes the PASSporT to a Call Placement Service (CPS) before the call enters the TDM network. The downstream provider retrieves the token from the same CPS after exiting the TDM leg and injects it into SIP signaling for verification.
There are three key methods:
The multiple CPS method uses a mesh that replicates tokens across all CPSs. The agreed CPS method simplifies this by having providers use a single shared CPS, reducing complexity and minimizing race conditions by specifying the publishing provider.
Key components include: a Call Placement Service client (CPS/OOBS), possibly a TDM-to-SIP InterWorking Function (IWF), digital certificate support, and logic to publish or retrieve PASSporTs around TDM call segments.
These include: ensuring CPS availability and performance for retrieval in real-time; aligning TDM leg handling among providers; managing tokens, timing, and provider identities correctly; and integrating new logic into legacy TDM switches which often lack modern update cycles.
The system ensures security through digital signatures on CPS interactions, strict matching of call metadata (numbers, timestamp, provider ID), and time-limited token storage. The agreed CPS method enhances reliability by reducing mistaken token retrievals.
Early implementations exist, with TransNexus offering a CPS and runnable code. ATIS published the updated standard in early 2025. Wider adoption depends on integration by carriers with TDM infrastructure and resolution of operational support issues.
Not entirely. In-band TDM signaling provides limited info; out-of-band offers full PASSporT support, but both require bilateral agreement and compatible systems. Until widespread deployment, some TDM paths remain unauthenticated.
Yes, the FCC can easily determine if you are verifying inbound calls. While the outbound SIP INVITEs go into the PSTN and potentially could be available to any service provider through which our calls route, some service providers don't think about the fact that Verification triggers detectable activity across the Internet