Caller ID is just a field the calling network fills in, so without authentication anyone can make a phone call appear to come from your help desk, your bank or your chief executive. STIR/SHAKEN is the framework that lets the originating telephone provider cryptographically sign the calling number and lets the terminating provider verify it, with an attestation level that says how much the originator knows about the caller's right to use that number. In the United States the FCC requires voice providers to implement it in their IP networks. This guide explains how the signing works (RFC 8224, RFC 8225 and the SHAKEN extension in RFC 8588), what decides whether an enterprise's outbound calls get A, B or C attestation, what it does and does not do against voice phishing, and what to ask your carrier. It is for telephony, contact centre and security teams that run SIP trunks or cloud calling. For securing the voice platform itself, see the VoIP and SIP Security Guide.
Key takeaways
- It signs the number, not the person. STIR/SHAKEN tells the recipient's network whether the originating provider vouches for the calling number; it says nothing about whether the caller is honest.
- Attestation depends on your provider's knowledge. Full (A) attestation needs the originating provider to know the customer and know the customer is authorised to use the number; calls with numbers the provider cannot vouch for get B, and calls from gateways get C.
- Enterprises usually do not sign their own calls. The carrier or cloud calling provider signs them, so poor attestation is usually a number ownership or routing problem to solve with that provider.
- The rules are US-centred. FCC rules under 47 CFR Part 64 Subpart HH set implementation and robocall mitigation duties for US providers; elsewhere, check the national regulator and do not assume calls are signed.
- Vishing defences still rest on process. Many voice phishing attacks use real, correctly attested numbers; call-back verification and strong help desk identity checks remain the main control.
How STIR/SHAKEN works
STIR (Secure Telephone Identity Revisited) is the IETF work; SHAKEN (Signature-based Handling of Asserted information using toKENs) is the industry profile used by North American carriers.
- Origination: the caller's provider receives a SIP INVITE from its customer and decides the attestation level.
- Signing: the provider's authentication service builds a PASSporT (Personal Assertion Token, RFC 8225), a signed JSON token carrying the calling and called numbers, a timestamp and, under SHAKEN, the attestation level and an origination identifier. RFC 8224 places it in the SIP Identity header field, with an info parameter that gives the URL of the signing certificate. The mandatory signing algorithm is ES256 (ECDSA on the P-256 curve).
- Transit: intermediate providers pass the Identity header unchanged across IP interconnects.
- Verification: the terminating provider's verification service fetches the certificate from the info URL, checks it chains to a trusted certificate authority for the scheme, checks the signature and compares the signed numbers and timestamp with the call.
- Use of the result: the terminating provider feeds the result into call blocking and labelling analytics and may display a verified indication on the handset.
Certificates are issued only to authorised providers. The FCC rules refer to the SHAKEN Governance Authority and to the Service Provider Code (SPC) token that a provider needs before it can obtain a certificate; 47 CFR 64.6308 provides for FCC review when the Governance Authority revokes a provider's SPC token.
What a PASSporT contains
RFC 8225 defines the token. The SHAKEN extension adds its own claims and identifies itself with the ppt header value.
| Part | Field | Purpose |
|---|---|---|
| Header | typ | Always "passport" |
| Header | alg | Signing algorithm; ES256 must be supported |
| Header | x5u | URI of the signing certificate or chain |
| Header | ppt | Names the extension (for SHAKEN, "shaken"); a verifier must reject an extension it does not support |
| Payload | orig | The calling number (exactly one) |
| Payload | dest | The called number or numbers |
| Payload | iat | Issued-at time, which limits replay of a captured token |
| Payload (SHAKEN) | attest, origid | Attestation level and origination identifier (RFC 8588) |
The iat check is why clock accuracy matters on signing and verifying systems: a verifier rejects a token whose timestamp is too far from the time it receives the call.
Attestation levels
RFC 8588 defines the SHAKEN "attest" claim with three values and points to the ATIS-1000074 specification for the formal definitions. It also defines the "origid" claim: an opaque UUID that the originating provider generates to identify the entry point of the call into its network, used for traceback.
| Level | RFC 8588 meaning | Typical enterprise situation |
|---|---|---|
| A, Full attestation | The provider can fully attest to the calling identity | The provider knows the enterprise and the number is assigned to it or verified as authorised for it |
| B, Partial attestation | The provider originated the call but cannot fully attest to the calling identity | An enterprise sends calls with numbers from another carrier, or presents numbers the provider has not verified, such as a main switchboard number hosted elsewhere |
| C, Gateway attestation | The provider received the call from a gateway that does not support PASSporT or STI | Calls entering from international or non-IP interconnects |
A verified call with B or C attestation is not "failed": it is signed, and the signature identifies which provider let it in. But terminating analytics weigh attestation, so legitimate enterprise calls with B attestation are more likely to be labelled as spam or blocked.
Why enterprises get B attestation and how to fix it
| Cause | Example | Fix |
|---|---|---|
| Numbers from a different carrier | Outbound calls leave via carrier X but present numbers ported to or held at carrier Y | Route calls for those numbers through the carrier that holds them, or provide the signing carrier with proof of authorisation so it can verify the numbers |
| Cloud contact centre or outsourcer | A third-party contact centre platform presents the enterprise's numbers | Ask the platform how it obtains authorisation for customer numbers and what attestation it achieves; supply letters of authorisation |
| Multiple trunks and failover | Calls fail over to a secondary provider that does not know the numbers | Register the full number range with every provider used for outbound calls |
| Calling party number rewriting | The PBX presents a main number that is not in the trunk's range | Present only numbers in the provider's verified inventory, or add them to it |
| International origination | Calls placed from overseas offices with US numbers | Expect gateway attestation; originate US-number calls from US infrastructure where possible |
Steps to improve outbound attestation:
- Inventory every telephone number and range the organisation presents as caller ID, including contact centres, notification services and marketing platforms.
- Map each to the provider that holds it and the providers that carry outbound calls for it.
- Ask each outbound provider, in writing, what attestation level your calls currently receive and on what basis; request a sample of signed calls.
- Fix routing so each number leaves through a provider that can verify it, and provide authorisation documents to the others.
- Test by calling numbers on several terminating networks and checking whether calls are labelled; repeat after any routing change.
- Roll back by keeping the previous trunk routing as a fallback route until test calls show no new blocking.
The US regulatory picture
The FCC's rules are in 47 CFR Part 64, Subpart HH (Caller ID Authentication); the eCFR version checked on 27 October 2026 was up to date as of 20 October 2026. The main obligations as they appear there:
| Section | Obligation | Date in the rule |
|---|---|---|
| 64.6301 | Voice service providers fully implement STIR/SHAKEN in their IP networks; third-party authentication services are allowed under conditions, including that the third party signs all calls using the provider's certificate | 30 June 2021 |
| 64.6302 | Intermediate providers fully implement STIR/SHAKEN, with further duties for gateway providers | 30 June 2021 |
| 64.6303 | Non-IP networks: upgrade to IP or take part in a non-IP caller ID authentication solution | 30 June 2021 for voice service providers; 30 June 2023 for gateway providers; 31 December 2023 for some non-gateway intermediate providers |
| 64.6304 | Extensions, including for small providers (100,000 or fewer subscriber lines) through 30 June 2023, and a continuing extension for non-IP portions of networks | As stated per category |
| 64.6305 | Robocall mitigation programmes, including responding to traceback requests within 24 hours; certification in the Robocall Mitigation Database; restrictions on accepting traffic from providers not listed; annual recertification on or before 1 March | Traffic restrictions for foreign and gateway traffic beginning 11 April 2023 |
These duties fall on providers, not on enterprise callers. They matter to enterprises because they decide whether providers will carry and how they will sign your calls, and because the Robocall Mitigation Database lets you check that a provider you buy from is certified. Rules change through FCC orders, so check the current eCFR text before relying on a date.
What STIR/SHAKEN does and does not do against vishing
| Threat | Does STIR/SHAKEN help? | Other controls |
|---|---|---|
| Spoofing your published numbers to call customers or staff | Partly: calls spoofing your number from another provider cannot get A attestation for it, and analytics may block them | Publish which numbers you call from; never ask for credentials on an inbound call |
| Caller posing as IT support from an unrelated, real number | No: the number is real and may be fully attested | Help desk and employee call-back verification; phishing-resistant MFA |
| Calls from overseas gateways | Limited: they arrive with C attestation or unsigned | Terminating analytics; staff awareness |
| Calls over non-IP or unsigned segments | No signature survives | As above |
| Internal calls on your own PBX | No: STIR/SHAKEN covers the public network | PBX security and internal caller ID integrity |
Voice phishing (ATT&CK T1566.004 Spearphishing Voice, and T1598.004 when used to gather information) is effective because people trust the voice and the story, not only the number. In the Cisco breach of 2022, callers posing as trusted organisations paired calls with repeated MFA prompts until an employee accepted one. In the ShinyHunters Salesforce campaign of 2025, callers posing as IT support talked staff into authorising an attacker-controlled connected app. Neither page reports spoofed caller ID; both show that caller authentication alone would not have stopped the attack.
Enterprise controls alongside STIR/SHAKEN
- Call-back verification: staff never act on an inbound call that asks for credentials, MFA approval, payment changes or app authorisation; they hang up and call back using a number from the directory.
- Help desk identity proofing: resets of passwords and MFA methods require verification that does not depend on caller ID, such as a manager confirmation or an identity verification flow. See the Vishing and Help Desk Social Engineering Awareness Guide.
- Inbound call handling: ask your provider whether it passes verification results to your SIP trunk or cloud calling platform, and whether your contact centre can route or flag calls by result.
- Protect your numbers: lock number porting with your providers, monitor for complaints of spoofed calls from your numbers, and register outbound numbers with the analytics services the major terminating networks use where available.
- Customer communication: tell customers which numbers you use and what you will never ask for on the phone.
Decision guidance for enterprises
- Small organisations on a single cloud calling or SIP trunk provider that also holds their numbers usually receive A attestation by default; confirm it once and recheck after any number port.
- Large organisations and contact centres with several carriers, outsourced dialling and many number ranges need a number inventory owner, written attestation commitments in carrier contracts and periodic test calls.
- Organisations that call the US from abroad should expect gateway attestation and lower answer rates, and decide whether to originate those calls from US infrastructure.
- Organisations that want to sign their own calls must qualify as a provider under the scheme's governance rules; for most enterprises using the carrier's signing, or a third-party authentication service the carrier contracts under 47 CFR 64.6301, is the realistic route.
Where identity fits
A calling number is an identifier for an organisation, and STIR/SHAKEN is effectively a PKI for it: certificates, a governance authority, token-based eligibility and signatures checked by a relying party. The same lifecycle discipline applies as for any machine credential: know which providers sign for which numbers, keep authorisation records current when numbers move, and treat a number presented by a platform you no longer use as an orphaned credential. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Detection and measurement
- Outbound: ask providers for attestation reporting by number range; track labelling complaints from customers.
- Inbound: where your SBC or calling platform logs SIP headers, record whether calls arrive with an Identity header and any verification failure response codes (RFC 8224 defines 428 Use Identity Header, 436 Bad Identity Info, 437 Unsupported Credential and 438 Invalid Identity Header).
- Abuse: log reports of calls spoofing your numbers and share them with providers for traceback.
Metrics:
- Percentage of outbound caller ID numbers mapped to a verifying provider.
- Percentage of outbound calls receiving A attestation, by provider.
- Answer rate and labelled-as-spam rate for outbound contact centre calls.
- Number of reported spoofing incidents using your numbers per quarter.
- Help desk resets completed without caller ID based verification (target 100 per cent).
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| IETF | RFC 8224, RFC 8225, RFC 8588 | SIP Identity header, PASSporT token, SHAKEN attestation claims |
| FCC | 47 CFR Part 64 Subpart HH | Provider obligations in the US |
| NIST SP 800-53 Rev. 5 | SC-8 Transmission Confidentiality and Integrity, SC-17 Public Key Infrastructure Certificates, AT-2(3) Social Engineering and Mining | Signed signalling, certificate trust, staff awareness of vishing |
| NIST CSF 2.0 | PR.AT-01 | Awareness training for social engineering by phone |
| MITRE ATT&CK v20 | T1566.004, T1598.004 | Voice phishing for access and for information |
Common failure patterns
- Treating a verified call as a trusted caller: staff or agents read "verified" as "safe" and act on requests that should require call-back.
- Presenting numbers your provider cannot vouch for: contact centre calls leave with B attestation and are labelled as spam, hurting legitimate outreach.
- Forgotten outbound platforms: a marketing or notification service still presents company numbers through a provider nobody manages.
- Assuming coverage outside North America: calls from or to other countries are often unsigned, and policies that rely on verification fail there.
- Help desk trusting caller ID: password and MFA resets authorised because the call "came from" the user's mobile number.
Practitioner checklist
- Inventory every number presented as outbound caller ID, by platform and provider.
- Confirm in writing the attestation level each provider gives your calls and why.
- Route each number through a provider that can verify it, or supply authorisation documents.
- Check that providers you buy from are listed in the FCC Robocall Mitigation Database where US rules apply.
- Ask providers whether inbound verification results reach your SBC, PBX or contact centre and use them for routing.
- Lock number porting and monitor reports of spoofing of your numbers.
- Require call-back verification for any phone request involving credentials, MFA, payments or app authorisation.
- Remove caller ID as an identity factor in help desk procedures.
- Re-test outbound labelling after every trunk or platform change.
Standards and references
- IETF: RFC 8224 Authenticated Identity Management in the Session Initiation Protocol (SIP)
- IETF: RFC 8225 PASSporT: Personal Assertion Token
- IETF: RFC 8588 PASSporT Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)
- eCFR: 47 CFR Part 64 Subpart HH Caller ID Authentication
- FCC: Combating Spoofed Robocalls with Caller ID Authentication
- MITRE ATT&CK: Phishing: Spearphishing Voice
Related NHI Mgmt Group resources: VoIP and SIP Security Guide · Vishing and Help Desk Social Engineering Awareness Guide · Top 10 Phishing Techniques · Machine Identity, PKI and Certificate Lifecycle Guide