STIR/SHAKEN is a call authentication framework designed to combat caller ID spoofing, a common technique used in illegal robocalls. The name stands for:
Together, these standards allow phone carriers to digitally sign and verify the caller ID information in SIP-based phone calls. The goal is simple: if recipients and service providers can trust the displayed caller ID, they can make better decisions about whether to answer, filter, or block a call.
STIR/SHAKEN doesn’t block calls itself, but it creates a trust layer for the identity of each caller, which downstream systems (or users) can use to take action.
STIR/SHAKEN works by attaching a cryptographically signed token to SIP calls — specifically in the form of an Identity header that carries a PASSporT (Personal Assertion Token).
This process involves three main components:
By checking this signature and the certificate used to generate it, the receiving network can verify the authenticity of the call’s claimed origin — without needing to trust the calling device or user directly.
Here’s a simplified version of how the process flows:
This system ensures that any tampering with the call identity along the way invalidates the signature, making spoofing much harder in verified networks.
Illegal robocalls and spoofed caller IDs continue to erode trust in voice communications. The STIR/SHAKEN framework is a critical step toward restoring that trust by verifying the identity of callers at the network level. Below are seven key facts every service provider should know.
STIR/SHAKEN is a substantial technology aimed at stopping "robocalling" by targeting the unverifiability of Caller ID. The hypothesis is that if call recipients could really know who was calling, we could better judge whether we wanted to answer the call.
Attackers design scams around the assumption that people still trust what they see on caller ID. STIR/SHAKEN gives providers a way to turn that assumption on its head by making caller identity something the network can verify instead of guess at.
In a typical phishing scenario, fraudsters spoof the number of a bank, credit card issuer, or government agency. They rely on the familiar number to pressure subscribers into sharing credentials, one-time passwords, or account details. When calls are attested and signed, terminating networks and analytics platforms can treat fully verified calls very differently from low-attestation traffic that merely “looks like” a trusted source.
Vishing campaigns often target enterprises, contact centers, and high-value individuals. Attackers impersonate vendors, executives, or IT teams using spoofed numbers to request changes, payments, or access. With STIR/SHAKEN in place, service providers can expose the real trust level behind those calls and feed that signal into fraud monitoring, making these social engineering attempts easier to detect and throttle.
Tech support scams typically begin with an alarming message and a caller ID that appears to belong to a well-known technology vendor. STIR/SHAKEN does not block those calls outright, but it does give providers a reliable way to differentiate legitimate support numbers from unauthenticated, low-confidence traffic. That reduces the odds that spoofed “support” calls blend in with real assistance that users actually need.
Illegal robocall operations frequently use neighbor spoofing, where the caller ID shares the same area code or even prefix as the recipient’s number. This pattern is designed to drive answer rates. When calls carry signed PASSporTs, analytics engines can move beyond the digits on the screen and lean on verification and attestation instead. That makes it easier to identify large campaigns of spoofed local numbers without punishing legitimate local callers.
In November 2018, US Federal Communications Commission (FCC) sent letters to major Telephone Providers, including AT&T, Verizon, and Comcast, asking them to implement STIR/SHAKEN in 2019.
In Canada, the CRTC has required many providers to implement STIR/SHAKEN telephony validation within 2019.
Some of the major telephone providers have hinted they would have STIR/SHAKEN operating in their networks before summer, 2019. The goal is to provide a special display on telephone calls.
Display examples courtesy Richard Shockey, Shockey Consulting.
STIR/SHAKEN does not block any telephone calls. But when it is fully implemented, customers and Voice service providers may choose to block calls that do not come from a verifiable Caller ID. If you can't tell who's calling, you probably don't want to talk to them.
Under the hood, STIR/SHAKEN is about headers, certificates, and signatures. On the surface, it changes how often calls connect, how customers perceive your network, and how much time your teams spend fighting fraud.
When calls carry strong attestation and can be verified end to end, they are less likely to be labeled as spam or diverted to voicemail by analytics engines and devices. That is especially important for high-value traffic such as appointment reminders, one-time passwords, and fraud alerts, where missed calls translate directly into real-world cost and frustration.
If attackers spoof a provider’s or enterprise’s numbers, the brand associated with those numbers often takes the reputational damage. With STIR/SHAKEN in place, you can show which calls truly originated on your network and which did not. Over time, consistent, accurate attestation helps rebuild trust in the phone channel and reduces the risk that customers start ignoring even legitimate calls.
Fraud and nuisance traffic do not only impact subscribers. They also consume engineering cycles, NOC time, and support resources. By feeding attestation levels and verification results into monitoring and analytics, providers can detect problematic traffic patterns sooner and reduce the amount of manual investigation required. That allows technical teams to spend more time improving the network, and less time chasing spoofed calls.
STIR/SHAKEN adds a new cryptographically-signed header to the SIP header of telephone call. Many SBCs block unknown headers, but the new Identity header should be allowed to pass through the network unchanged to allow the recipient to validate the call.
The Identity header will be computed by the "Authentication Service" function, and then added to the SIP message. The Identity header is expected to transit the network unchanged to the final recipient, who will verify it with the "Verification Service" function. The Identity header includes both the original calling party number, called party number, and also an indication of the confidence that the originator has in the validity of the caller ID -- i.e., the "attestation level". A "fully attested" call is one for which the Voice service provider has absolute confidence that the caller has the right to make a call from that telephone number.
INVITE sip:+12155551213@tel.example1.net SIP/2.0
Via: SIP/2.0/UDP 10.36.78.177:60012;branch=z9hG4bK-524287-1--- 77ba17085d60f141;rport
Max-Forwards: 69
Contact: <sip:+12155551212@69.241.19.12:50207;rinstance=9da3088f36cc528e>
To: <sip:+12155551213@tel.example1.net>
From: "Alice"<sip:+12155551212@tel.example2.net>;tag=614bdb40
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
P-Asserted-Identity: "Alice"<sip:+12155551212@tel.example2.net>,<tel:+12155551212>
CSeq: 2 INVITE
Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, MESSAGE, OPTIONS Content-Type: application/sdp
Date: Fri, 11 Jan 2019 19:23:38 GMT
Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1IjoiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNbWNhc3QubmV0L2V4YW1wbGUuY2VydCJ9eyJhdHRlc3QiOiJBIiwiZGVzdC6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiIxNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6nY4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtCA ;info=<http://cert.example2.net/example.cert>;alg=ES256
Content-Length: 153
v=0
o=- 13103070023943130 1 IN IP4 10.36.78.177
c=IN IP4 10.36.78.177
t=0 0
m=audio 54242 RTP/AVP 0
a=sendrecv
Example courtesy Martin Dolly, AT&T
The SIP INVITE above packs a lot of meaning into a single Identity header. Understanding the main components makes it easier for operations teams to debug issues, confirm attestation behavior, and explain results to customers.
The PASSporT header describes how the token is built and where to find the certificate that signed it. In a decoded view, you will typically see fields for the signing algorithm, the token type, the PASSporT extension, and a certificate URL. For STIR/SHAKEN, the algorithm is ES256, the type is usually “passport,” the extension is “shaken,” and the certificate URL points to the resource that contains the public key needed to validate the signature.
The payload ties the token to a specific call. It includes the attestation level assigned by the originating provider, the originating telephone number, the destination number or numbers, and a timestamp that shows when the token was created. An origination identifier can also appear in the payload to help correlate calls and tokens in logs. If any of these fields conflicts with the SIP INVITE — for example, if the originating number in the payload does not match the From header — a well-designed verification service will treat the call as suspicious.
Beyond the JSON Web Token itself, the Identity header can carry parameters that repeat key details, such as the certificate URL, the signing algorithm, and the PASSporT extension. These parameters give verification services and logging systems a quick way to locate the right certificate and to understand how the token was constructed. When you are troubleshooting a failed verification, confirming that these values are correct can quickly reveal whether you are dealing with a misconfiguration, an expired certificate, or an untrusted signer.
It is possible for Voice service providers to wrongly "attest" ownership and validity of telephone numbers; they can produce Identity headers that they should not. If a Voice service provider is discovered to do this, then other service providers may choose not to trust anything signed by that "bad actor" Voice service provider. But doing this will require recipients to assess the quality of the Identity headers.
Because of this, the rules about deciding who can attest telephone calls are unresolved. The expectation in the US is that any company with the right to "own telephone numbers" -- i.e., they have an Operating Company Number, OCN -- will have the right to attest telephone calls.
STIR/SHAKEN works best when the carrier that originates your outbound calls can confidently verify (attest) your caller ID. That’s straightforward in a single-carrier setup, but it gets messy fast when an enterprise routes outbound calls through multiple carriers.
In most implementations, a provider can add the STIR/SHAKEN Identity header and give strong attestation when the phone numbers are directly assigned to them or ported to them, and the call also exits their network.
For example:
The result is a real-world “attestation gap” where the same enterprise caller ID can look more or less trustworthy depending on the outbound path.
In a multi-carrier environment, the same enterprise number can show up with different attestation levels based on routing:
From the caller’s perspective, nothing changed. From the callee’s perspective, some calls look “verified” (the “green check” experience) and others look suspicious, even though they’re from the same business.
Start by getting clear on where attestation decisions are happening and why certain call paths lose trust.
The best mix depends on your enterprise setup and your wholesale/retail carrier relationships, but the goal stays the same: make sure your most important calls consistently receive strong attestation, no matter which carrier route they take.
As part of the STIR/SHAKEN framework, attestation levels indicate how confident a service provider is that the caller is authorized to use the calling number. These levels are embedded in the signed PASSporT and help downstream carriers assess the trustworthiness of a call.
There are three STIR/SHAKEN attestation levels:
The provider fully verifies the caller and their right to use the calling number.
Example: A call from a SIP trunk belonging to an enterprise with a valid number assigned by the provider.
The provider knows the caller, but cannot verify the caller's right to use that particular calling party phone number.
Example: A call from a SIP trunk that has been forwarded through the customer's PBX back to the originating service provider.
The provider is simply passing along the call and cannot verify the caller’s identity or right to use the number.
Example: A call received from another provider without any verification, such as calls traversing international routes.
Carriers, analytics engines, and spam filters use attestation levels to help determine whether to trust, flag, or block a call. Repeated misuse of Level A by a provider (e.g., incorrectly signing calls as fully attested) can lead to distrust across the ecosystem — and even FCC enforcement actions.
In short, attestation is the backbone of STIR/SHAKEN trust. It’s not just about signing the call — it’s about signing it correctly.
As of 2025, STIR/SHAKEN has been implemented by most major voice service providers in the United States and Canada, including many smaller and regional carriers. The FCC has enforced compliance deadlines and now requires even intermediate and gateway providers to support STIR/SHAKEN, particularly in IP-based networks.
Still, challenges remain in networks that rely on legacy TDM infrastructure, where STIR/SHAKEN cannot be fully applied. In such cases, out-of-band solutions are being explored to bring call verification to non-IP systems.
Although STIR/SHAKEN began as a North American initiative, many providers now have to think about what happens when authenticated calls cross borders and encounter different regulatory and technical frameworks.
Countries that adopt STIR/SHAKEN-style standards make local decisions about governance. They choose who issues certificates, who acts as a policy authority, how eligibility is checked, and what timelines apply. Some move quickly to enforce authentication on IP voice; others take a phased approach. For providers operating in more than one jurisdiction, understanding those local rules is just as important as understanding the technical specification.
When a call originates in one country and terminates in another, the receiving network has to decide how much to trust the originating provider’s certificate and attestation. In some cases, formal agreements or shared governance structures make that trust clear. In others, terminating networks may treat foreign attestations cautiously, downgrade them, or rely more heavily on local analytics until stronger cross-border mechanisms are in place.
If a meaningful portion of your traffic is international, it is worth monitoring how attestation behaves on those routes. Patterns such as frequent downgrades, missing identity headers, or inconsistent treatment across partners can highlight where additional agreements, different interconnect choices, or specialized cross-border services might be needed. The goal is to keep legitimate international calls as trusted and answerable as domestic ones.