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.
What Is STIR/SHAKEN Compliance?
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).
Why STIR/SHAKEN Compliance Matters
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...
- What level of attestation should we be using?
- Do we know if our customers have the right to use the phone numbers they're using?
- In what parts of our network do we have to implement STIR/SHAKEN? (Meaning: do we have to have Identity headers everywhere)?
- What do we have to do to "fully implement" STIR/SHAKEN?
- What do I do with the data I gain from verifying the Identity header PASSporT values?
- Could the FCC determine if I'm verifying inbound calls?
This article is written for Voice Service Providers to discuss these questions and help you see if you're fully compliant.
Choosing the Right STIR/SHAKEN Attestation Level
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: I know who the caller is as a legal person/corporation, and I know they have the right to call from this telephone number.
- B: I know who the caller is as a legal person/corporation, but I don't know if they have the right to call from this telephone number.
- C: I don't know who the caller is, but I know where the call came into my network. But that entry point wasn't from the caller.
What’s the difference between Attestation Levels A, B, and C? (What do STIR/SHAKEN attestation levels mean?)
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.
How to Validate Your Customers’ Use of Phone Numbers
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.
- SIMPLEST: Customers only use telephone numbers that you assign to them. They cannot modify their telephone numbers used for outbound calls. You know you have the right to use the telephone numbers because they were assigned to you from a governing authority. If a customer tries to send a call from another telephone number, you block their call (except when it's going to 911, because you never block that.)
- HARDEST: Your customers place calls to you from any telephone number they choose. In fact, your customers may actually be routing calls that they received from another location (such as with Call forwarding, or informal 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.
Where in Our Network Is STIR/SHAKEN Implementation Required?
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 Full STIR/SHAKEN Implementation Really Means
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.”
What Does STIR/SHAKEN Verification Actually Involve?
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:
- Forward the PASSporT to a system capable of interpreting it
- Decode the PASSporT to extract the embedded data
- Retrieve the public certificate used to sign the PASSporT
- Verify the digital signature to confirm its authenticity
- Compare the calling number, called number, and timestamp to evaluate the token’s validity
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.
What does a Service Provider with the data it gains from verifying the Identity header PASSporT value?
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.
Common STIR/SHAKEN Compliance Mistakes
Even providers who think they're compliant may be falling short in key areas. Here are the most common mistakes we see:- Relying on downstream providers for third-party signing when this is not allowed under FCC regulations.
- Failing to verify inbound Identity headers, which can undermine call authentication.
- Assigning A-level attestation without proper Know Your Customer (KYC) procedures.
- Losing call context across multi-hop SBCs, such as not using internal tagging to track how the call was received or authenticated.
- Misapplying attestation levels due to inadequate number-screening controls—e.g., assuming a call should receive an A-level attestation simply because it came from customer X.
- Lacking documentation or logs to support enforcement actions. If the FCC requests verification for a specific call, can you prove how and why the attestation level was assigned?
If your network or procedures include any of the above, now is the time to fix them, before an investigator calls.
Protect Your NetworkWith Proper STIR/SHAKEN Implementation
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/SHAKEN Compliance frequently Asked Questions (FAQs)
1. What exactly do “STIR” and “SHAKEN” stand for and how do they differ?
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.
2. How are calls verified end-to-end?
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
3. Why do users complain “I don’t see any evidence of verification”?
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.
4. Does STIR/SHAKEN distinguish between good vs spam calls?
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.
5. Are there “garbage in, garbage out” vulnerabilities?
Yes, scammers may game attestations via upstream providers or misassigned A-level without actual KYC.
6. Who must comply and by when?
All portions of telecom networks that use VoIP must use STIR/SHAKEN.\
7. What about VoIP resellers on hosted platforms?
Resellers must obtain their own certificate, implement signing, and update Robocall Mitigation Plans by June 20, 2025 - no longer can depend on downstream signatures.
8. What about compatibility testing for STIR/SHAKEN?
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.
9. Can end-user phone systems implement STIR/SHAKEN?
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).
10. Can the FCC and other regulators detect compliance or not?
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
11. What are the risks of relying on third-party STIR/SHAKEN solutions?
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:
- Non-Compliance: Using third-party certificates may lead to delisting or fines.
- Operational Disruptions: Calls signed with invalid certificates may be blocked, affecting service delivery.
- Security Vulnerabilities: Third-party systems may lack robust security, increasing the risk of certificate misuse.
Providers must transition to proprietary signing servers to remain compliant.
12. What is the role of the Secure Telephone Identity Governance Authority (STI-GA)?
The STI-GA, under ATIS, oversees the STIR/SHAKEN framework by:
- Defining Certificate Rules: Establishes policies for issuing and managing digital certificates.
- Approving Certification Authorities: Maintains a secure list of trusted CAs, accessible via REST interface queries.
- Supporting Call Authentication: Ensures the framework’s integrity by validating service provider tokens and certificates, enabling effective robocall mitigation.
13. What is out-of-band SHAKEN and why is it needed for TDM?
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.
14. How does the PASSporT reach the terminating leg when the call goes over TDM?
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.
15. What are the main technical approaches defined by ATIS?
There are three key methods:
- In-band TDM signaling (ATIS-1000095): Embeds limited attestation info via ISUP fields or UUI.
- Out-of-band multiple CPS (ATIS-1000096): Uses a mesh of CPSs to publish and retrieve PASSporTs.
- Out-of-band agreed CPS (ATIS-1000105): Providers agree on and use a shared CPS, adding provider ID to avoid token mismatches.
16. What is the difference between multiple CPS and agreed CPS 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.
17. What elements does a service provider need to implement out-of-band SHAKEN?
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.
18. What are common implementation challenges?
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.
19. How secure and reliable is the out-of-band method?
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.
20. How mature is out-of-band SHAKEN in the industry?
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.
21. Does this fully close the TDM caller ID authentication gap?
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.
22.Can the FCC determine if I'm verifying inbound calls?
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
