# STIR SHAKEN attestation framework

Canonical: https://warmtransfer.net/knowledge/stir-shaken-framework

Last verified: 2026-09-24

The Federal Communications Commission mandated in FCC 20-42, adopted and released on 31 March 2020 in WC Docket No. 17-97, that all voice service providers implement the STIR/SHAKEN caller identity authentication framework in the internet protocol portions of their networks by 30 June 2021[^18]. Federal regulations define operational duties, network definitions, and consumer protections for handling caller identification authentication[^15][^14][^21].

## Regulatory requirements

Under 47 CFR 64.6301, a voice service provider must obtain a Service Provider Code token from the Secure Telephone Identity Policy Administrator and use it to acquire a certificate from a Secure Telephone Identity Certificate Authority[^15]. The provider must then authenticate and verify caller identification information for all SIP calls that transit exclusively its own network, authenticate all SIP calls it originates and hand them off with that information where technically feasible, and verify all authenticated SIP calls it terminates[^15]. 47 CFR 64.6301(b) allows a voice service provider to satisfy its authentication obligations via a third-party authentication service, provided that the third party signs calls using the provider's own certificate, the provider makes all attestation-level decisions for each originated SIP call, and a written agreement specifies the third party's tasks while confirming both conditions[^26].

Voice service providers with non-internet-protocol network segments had 2 compliance pathways by 30 June 2021 under 47 CFR 64.6303: upgrade the entire network to carry SIP calls and implement STIR/SHAKEN throughout, or maintain and be ready to provide documented proof of participation in a working group, industry standards group, or consortium developing or testing a non-IP caller identity authentication solution[^23]. 47 CFR 64.6300 defines an intermediate provider as any entity carrying or processing traffic on the public switched telephone network that neither originates nor terminates that traffic, and defines a gateway provider as a United States based intermediate provider receiving a call directly from a foreign originating or intermediate provider at its United States facilities before passing it downstream[^14]. 47 CFR 64.6307 prohibits voice service providers from adding any additional line item charges to consumer or small business subscribers for the call authentication technology required by these rules[^21].

## Attestation levels and verification

Cisco states that SHAKEN attestation levels allow an originating service provider to attest its relationship to the calling number using 3 tiers[^27]:
- Attestation A: The provider attests that the caller has the right to use the phone number as the caller identity[^27].
- Attestation B: The customer is known, but it is unknown whether they have the right to use the caller identity[^27].
- Attestation C: The call satisfies neither requirement, with international calls cited by Cisco as an example[^27].

Terminating service providers convey verification results using the verstat parameter in the SIP P-Asserted-Identity header[^29]. Cisco states this parameter carries 3 possible values: `TN-Validation-Passed` for a successful validation carrying an A, B, or C attestation; `TN-Validation-Failed` when the caller could not be verified; and `No-TN-Validation` when verification fails for reasons such as a malformed E.164 number[^29].

## Webex Calling client display and feature behaviors

Webex Calling maps incoming verification results and attestation levels to client display labels[^10].

| Verification result | Attestation level | Client display |
| --- | --- | --- |
| Validation passed | A or not provided | Verified Caller[^10] |
| Validation passed | B or C | Possible Spam[^10] |
| Failed validation | Any | Potential Fraud[^10] |
| No validation / no verstat | None | Possible Spam[^10] |

Cisco clients supporting Unified Call History display an icon for the caller identity disposition in the call history record[^16]. Cisco states that the Webex App displays both the attestation text and the icon, while Multiplatform phones display only the icon[^16]. Spam detection requires the Webex App desktop or mobile at version 42.5 or higher, or 6800, 7800, 8800, and 9800 Multiplatform phones at firmware version 11.3.7 or higher[^25].

On-net call verification rules operate asymmetrically[^24]. Webex Calling marks calls between Webex Calling users, as well as calls from Unified Communications Manager users to Webex Calling users, as a verified user with an icon[^24]. The Unified CM scenario is classified according to whether the caller identity matches the configured enterprise dial plan[^24]. Cisco states that a call from a Webex Calling user to an on-premises Unified CM user carries no indication on the Unified CM client[^24].

For mid-call features including call transfer, call park, call pickup, call forwarding, and caller identity, Cisco states that the disposition is based on the verstat value processed on the initial call leg[^17]. When an incoming call to a Webex Calling user is forwarded and the calling number changes, the disposition remains determined by the verstat in the incoming call request[^17].

## Administration and reputation screening

Control Hub provides controls for call handling based on caller verification[^11][^28]. The setting to block calls failing caller identity validation is disabled by default; when enabled, failed calls do not route to endpoints, though the calling number is logged in the called user's call history[^11]. The setting to present calls from unverified callers as normal calls is enabled by default, presenting unverified calls without indication[^28]. Cisco states that organisations with STIR/SHAKEN enabled by their PSTN provider can disable this setting, causing unverified callers to display as Possible Spam[^28]. If the PSTN provider does not send verstat parameters, Cisco instructs administrators to leave this default enabled to avoid every incoming call showing as Possible Spam[^22].

Organizations in the United States and Canada using on-premises PSTN via a Local Gateway or Cisco Unified Border Element must configure a SIP copy list covering the From, P-Asserted-Identity, and P-Attestation-Indicator headers alongside 9 SIP profile rules to pass verstat information to Webex Calling[^20]. Cisco states that having this configuration in place does not affect calls when the service provider omits the parameter[^20].

Webex Calling integrates with Certified Calling Reputation Providers to evaluate incoming PSTN calls in real time and return an allow, block, or CAPTCHA action[^13]. Cisco states this integration is available to customers headquartered in North America via the certified provider Mutare[^13]. Because Webex Calling passes the called number alongside caller details, administrators can configure destination-specific screening rules in the provider portal[^12]. The reputation score remains based on the calling number, but the provider can return an allow, block, or CAPTCHA action based on the calling number, the called number, or a combination of both[^12].

## See also

- [Branded calling and CNAM delivery](https://warmtransfer.net/knowledge/branded-calling-cnam)
- [Robocall mitigation and RMD obligations](https://warmtransfer.net/knowledge/robocall-mitigation)
- [Webex Calling PSTN options and selection](https://warmtransfer.net/knowledge/webex-calling-pstn-options)
- [Local Gateway design and configuration](https://warmtransfer.net/knowledge/webex-calling-local-gateway)
- [Call transfer semantics REFER and Replaces](https://warmtransfer.net/knowledge/call-transfer-semantics)
- [Webex Calling supported devices and MPP firmware](https://warmtransfer.net/knowledge/webex-calling-device-support)
- [E.164 numbering and dial string normalization](https://warmtransfer.net/knowledge/e164-numbering)
- [Number porting and LNP workflows](https://warmtransfer.net/knowledge/number-porting)
- [Toll-free numbering and RespOrg](https://warmtransfer.net/knowledge/toll-free-numbering)
- [Call blocking and analytics labeling remediation](https://warmtransfer.net/knowledge/call-blocking-labeling)

## Applicability

Cisco states that the call indication features and caller identity settings apply only to Webex Calling locations in the United States and Canada, while other locations present calls normally regardless of caller identity configurations[^19]. The FCC mandate and CFR provisions apply to voice service providers, gateway providers, and intermediate providers in the United States[^18][^15][^14]. Applies to: Federal Communications Commission STIR SHAKEN and Cisco Webex Calling. Sources checked 2026-09-16.

## What remains uncertain

- What attestation level Webex Calling signs its own customers' calls at is not covered by the sources below.
- What a Webex Calling customer must file in the Robocall Mitigation Database is not covered by the sources below.
- What a caller challenged by CAPTCHA on a voice call actually hears and does is not covered by the sources below.
- Whether the Detailed Call History records the attestation or verstat of a call is not covered by the sources below.
- The ATIS and SIP Forum SHAKEN specifications that define the attestation levels are not covered by the sources below.
- How Webex Calling handles caller identity authentication outside the United States and Canada is not covered by the sources below.

## Sources

[^1]: CTIA describes Branded Calling ID as an industry-led, standards-based Rich Call Data ecosystem that delivers the caller's name, logo and call reason to smartphones on STIR/SHAKEN-signed calls. Source: [Branded Calling ID home](https://brandedcallingid.com/), home page hero and technology sections. Checked 2026-09-24.
[^2]: In BCID a Signing Agent generates the cryptographic signature on the Rich Call Data PASSporT, confirming the call was vetted and validated. Source: [Authorized Partners - Branded Calling ID](https://brandedcallingid.com/authorized-partners/), Signing Agent role definition. Checked 2026-09-24.
[^3]: RFC 9796 says the STIR security framework, including the rcd PASSporT, should be used to protect the integrity and authenticity of Call-Info rich call data. Source: [RFC 9796: SIP Call-Info Parameters for Rich Call Data](https://www.rfc-editor.org/rfc/rfc9796.html), Section 13.2 (security considerations). Checked 2026-09-24.
[^4]: The draft FNPRM proposes that terminating providers must send verified caller identity information to the handset whenever they send an indication that the call received A-level attestation. Source: [FCC Fact Sheet and draft: Call Branding FNPRM, Improving Verification and Presentation of Caller Identification Information (FCC-CIRC2510-07)](https://docs.fcc.gov/public/attachments/DOC-415059A1.txt), draft FNPRM paragraph 30. Checked 2026-09-24.
[^5]: The draft FNPRM notes that RCD works only on IP networks and asks what to do about the non-IP gap, including whether to require other solutions that work on non-IP networks. Source: [FCC Fact Sheet and draft: Call Branding FNPRM, Improving Verification and Presentation of Caller Identification Information (FCC-CIRC2510-07)](https://docs.fcc.gov/public/attachments/DOC-415059A1.txt), draft FNPRM paragraph 62. Checked 2026-09-24.
[^6]: The draft FNPRM describes RCD as building on STIR/SHAKEN to carry name, photo, logo, email, location, title and call reason, and cites RFC 9795, RFC 9796 and ATIS-1000094 v002 as the RCD standards. Source: [FCC Fact Sheet and draft: Call Branding FNPRM, Improving Verification and Presentation of Caller Identification Information (FCC-CIRC2510-07)](https://docs.fcc.gov/public/attachments/DOC-415059A1.txt), draft FNPRM paragraphs 12-13. Checked 2026-09-24.
[^7]: RFC 9795 lets an authentication service either send rcd in its own PASSporT with a separate Identity header or add rcd claims directly to another extension PASSporT such as shaken; verifiers that support only the base extension ignore the extra claims. Source: [RFC 9795: Personal Assertion Token (PASSporT) Extension for Rich Call Data](https://www.rfc-editor.org/rfc/rfc9795.html), Section 13 (using rcd with other PASSporT extensions). Checked 2026-09-24.
[^8]: Twilio US Enhanced Branded Calling requires SHAKEN/STIR on the phone numbers, a signed Letter of Authorization, and an approved primary Business Profile with an EIN. Source: [US Enhanced Branded Calling](https://www.twilio.com/docs/voice/branded-calling/us-enhanced), requirements section. Checked 2026-09-24.
[^9]: Webex Calling shows Potential Fraud when verstat is TN-Validation-Failed, and Possible Spam when verstat is No-TN-Validation, missing, or TN-Validation-Passed with C attestation. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), verstat to call indication table. Checked 2026-09-24.
[^10]: In Webex Calling's mapping from verification result to client display, a call whose validation passed is shown as Verified Caller when the attestation is A or not provided and as Possible Spam when the attestation is B or C; a failed validation is shown as Potential Fraud; and no validation, or no verstat parameter at all, is shown as Possible Spam. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Verstat value and attestation table, read as table cells. Checked 2026-09-16.
[^11]: The Control Hub setting that blocks calls failing caller identity validation is disabled by default, and Cisco states that when it is enabled such calls are not routed to the user's endpoints while the calling number is still added to the called user's call history. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Administrator Configuration, Block calls that failed Caller ID validation. Checked 2026-09-16.
[^12]: Webex Calling sends the called number to the reputation provider along with the caller information, so an administrator can configure rules in the provider's portal that apply different screening treatments by destination, and Cisco states that the provider can return an allow, block or CAPTCHA action based on the calling number, the called number or a combination while the reputation score itself remains based on the calling number. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Called-number screening section. Checked 2026-09-16.
[^13]: Webex Calling integrates Certified Calling Reputation Providers that assess incoming PSTN calls in real time and return an allow, block or CAPTCHA action, and Cisco states the integration is available for customers headquartered in North America through the certified provider Mutare. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Certified caller reputation providers with Webex Calling section. Checked 2026-09-16.
[^14]: 47 CFR 64.6300 defines a gateway provider as a United States based intermediate provider that receives a call directly from a foreign originating or intermediate provider at its United States facilities before passing it downstream to another United States provider, and an intermediate provider as any entity that carries or processes traffic traversing the public switched telephone network while neither originating nor terminating it. Source: [47 CFR part 64 subpart HH — Caller ID Authentication](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B/part-64/subpart-HH), 47 CFR 64.6300(d) and (g). Checked 2026-09-16.
[^15]: 47 CFR 64.6301 requires a voice service provider to obtain a Service Provider Code token from the Secure Telephone Identity Policy Administrator and use it to obtain a certificate from a Secure Telephone Identity Certificate Authority, then to authenticate and verify caller identification information for all SIP calls that transit only its own network, to authenticate it for all SIP calls it originates and hand them on with that information where technically feasible, and to verify it for all authenticated SIP calls it terminates. Source: [47 CFR part 64 subpart HH — Caller ID Authentication](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B/part-64/subpart-HH), 47 CFR 64.6301(a). Checked 2026-09-16.
[^16]: Cisco clients that support Unified Call History show an icon for the caller identity disposition in the call history record, and Cisco states that the Webex App displays the attestation text and the icon while Multiplatform phones display only the icon. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Verstat value and attestation, paragraph following the mapping table. Checked 2026-09-16.
[^17]: Cisco states that for mid-call features including call transfer, call park, call pickup, call forwarding and caller identity, the caller identity disposition is based on the verstat value processed on the initial call leg, and that when an incoming call to a Webex Calling user is forwarded and the calling number changes the disposition is still decided by the verstat in the incoming call request. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Verification of the on-net calls, mid-call features paragraph. Checked 2026-09-16.
[^18]: The Federal Communications Commission mandated in FCC 20-42, adopted and released on 31 March 2020 in WC Docket No. 17-97, that all voice service providers implement the STIR/SHAKEN caller identity authentication framework in the internet protocol portions of their networks by 30 June 2021. Source: [FCC 20-42 — Call Authentication Trust Anchor, Report and Order and Further Notice of Proposed Rulemaking, WC Docket No. 17-97](https://docs.fcc.gov/public/attachments/FCC-20-42A1.pdf), FCC 20-42 paragraph 3. Checked 2026-09-16.
[^19]: Cisco states that the call indication features and the caller identity settings apply only to Webex Calling locations in the United States and Canada, and that other locations see calls presented normally regardless of the caller identity settings. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Administrator Configuration, note following the 2 toggles. Checked 2026-09-16.
[^20]: Cisco requires organisations in the United States and Canada using on-premises PSTN through a Local Gateway or Cisco Unified Border Element to configure a SIP copy list covering the From, P-Asserted-Identity and P-Attestation-Indicator headers together with 9 SIP profile rules, in order to pass verstat information through to Webex Calling, and states that applying the configuration when the service provider does not send the parameter does not affect calls. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Configure CUBE for spam indication section and its configuration block. Checked 2026-09-16.
[^21]: 47 CFR 64.6307 prohibits voice service providers from adding any additional line item charge to consumer or small business customer subscribers for the effective call authentication technology required by 47 CFR 64.6301 and 64.6303. Source: [47 CFR part 64 subpart HH — Caller ID Authentication](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B/part-64/subpart-HH), 47 CFR 64.6307. Checked 2026-09-16.
[^22]: Where the PSTN provider does not send verstat information in an incoming call, Cisco instructs the administrator not to change the default of the setting presenting calls from unverified callers as normal, because disabling it would show the Possible Spam indication to users on every such call. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Configure CUBE for spam indication, For calls from PSTN where the service provider doesn't support STIR/SHAKEN. Checked 2026-09-16.
[^23]: 47 CFR 64.6303 gives a voice service provider with non-internet-protocol network portions 2 ways to comply by 30 June 2021: upgrade the entire network to carry SIP calls and implement STIR/SHAKEN throughout, or maintain and be ready to provide documented proof of participation in a working group, industry standards group or consortium developing or actively testing a non-IP caller identity authentication solution. Source: [47 CFR part 64 subpart HH — Caller ID Authentication](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B/part-64/subpart-HH), 47 CFR 64.6303(a). Checked 2026-09-16.
[^24]: Webex Calling marks an on-net call between Webex Calling users and an on-net call from a Unified Communications Manager user to a Webex Calling user as a verified user with an icon, classifying the Unified CM case by whether the caller identity matches the configured enterprise dial plan, and Cisco states that a call from a Webex Calling user to an on-premises Unified CM user carries no indication on the Unified CM client. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Verification of the on-net calls section. Checked 2026-09-16.
[^25]: Cisco states that spam detection is supported on the Webex App desktop and mobile at version 42.5 or higher and on 6800, 7800, 8800 and 9800 Multiplatform phones at firmware version 11.3.7 or higher. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Supported devices section. Checked 2026-09-16.
[^26]: 47 CFR 64.6301(b) permits a voice service provider to meet its authentication obligation through a third-party authentication service, provided the third party signs all calls using the provider's own certificate, the provider makes all attestation-level decisions for each SIP call it originates, and the agreement is memorialised in writing specifying the third party's tasks and confirming both conditions. Source: [47 CFR part 64 subpart HH — Caller ID Authentication](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B/part-64/subpart-HH), 47 CFR 64.6301(b). Checked 2026-09-16.
[^27]: Cisco states that the SHAKEN attestation levels let an originating service provider attest its relationship to the calling number: A means the provider can attest that the caller has the right to use the phone number as the caller identity, B means the customer is known but it is unknown whether they have the right to use the caller identity, and C means the call meets neither requirement, for which Cisco's example is an international call. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Understanding the STIR/SHAKEN standard, SHAKEN attestation levels. Checked 2026-09-16.
[^28]: The Control Hub setting presenting calls from unverified callers as normal calls is enabled by default, so unverified calls reach endpoints with no indication, and Cisco states that an organisation whose PSTN service provider has enabled STIR/SHAKEN can disable it, after which unverified callers display as Possible Spam. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Administrator Configuration, Present calls from unverified callers as normal calls. Checked 2026-09-16.
[^29]: Cisco states that terminating service providers convey verification results in the verstat parameter of the SIP P-Asserted-Identity header, with 3 values: TN-Validation-Passed for a successful validation carrying an A, B or C attestation, TN-Validation-Failed where the caller could not be verified, and No-TN-Validation for a verification failure for other reasons such as a malformed E.164 number. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Understanding the STIR/SHAKEN standard, verstat options. Checked 2026-09-16.