STIR/SHAKEN caller ID authentication: what the rule requires

What STIR/SHAKEN is, as far as the rule is concerned

The rule text calls it the "STIR/SHAKEN authentication framework" and does not define it further, so this page sticks to what section 64.6301 actually requires. The section is about authenticating and verifying the caller identification information carried with a call, and it puts that duty on voice service providers.

The core obligation and its deadline

Paragraph (a) says that, except as provided in sections 64.6304 and 64.6306, not later than June 30, 2021, a voice service provider shall fully implement the STIR/SHAKEN authentication framework in its Internet Protocol networks. The deadline has passed; the live question for a provider today is whether it has implemented the framework, or has an extension or exemption under 64.6304 or 64.6306, and what it says about that in its Robocall Mitigation Database filing, covered on the database certification page.

The three steps a provider must take

1. Get credentials. Obtain an SPC token from the Secure Telephone Identity Policy Administrator and use that token to obtain a Secure Telephone Identity certificate from a Secure Telephone Identity Certificate Authority.
2. Authenticate. Using the certificate, authenticate and verify caller identification information for all SIP calls that exclusively transit the provider's own network, and authenticate caller identification information for all SIP calls the provider originates and will exchange with another voice service provider or intermediate provider, transmitting the call with authenticated information to the next provider in the path to the extent technically feasible.
3. Verify. Verify caller identification information for all SIP calls it receives from another provider that it will terminate and for which the caller identification information has been authenticated.

The rule is limited to SIP calls. Calls that do not travel as SIP calls over internet protocol networks are not addressed by these paragraphs.

Using a third-party authentication service

A provider may meet its authentication duty by contracting with a third-party authentication service, but the rule keeps accountability with the provider. Paragraph (b) requires that the provider: requires the third party to sign all calls using the provider's own certificate; makes all attestation-level decisions regarding the caller identification information of each SIP call it originates; memorializes the agreement in writing, specifying the tasks the third party will perform and confirming that the provider makes all attestation-level decisions and that all calls are signed with the provider's certificate; maintains the agreement for as long as the arrangement exists; and retains a copy for two years from the end or termination of the agreement.

In short, a provider can outsource the signing, but not the decision about how much trust to assert on each call. The rule does not define "attestation level"; it only says the provider makes those decisions.

A worked example

Suppose a small regional carrier receives a SIP call from a business customer and hands it to a larger carrier. Under 64.6301(a)(2)(ii) the small carrier must authenticate the caller ID with its own certificate before handing off, whether it signs the call itself or through a third party under an agreement meeting paragraph (b). The larger carrier, if it terminates the call to a subscriber, must verify the caller ID under paragraph (a)(3) because it has been authenticated. If the call never leaves the small carrier's own network, paragraph (a)(2)(i) requires it to authenticate and verify internally.

What this means for people who are not carriers

The rule imposes nothing on individuals or on businesses that merely place calls, and nothing on the person receiving one. The rule text read here does not set any display or labeling rules for the person receiving a call. If you operate a phone system that originates calls on behalf of others, whether you count as a voice service provider is a legal question for the FCC and your counsel; this page does not decide it.

What is not in the section

The version read here does not include the extension categories, the foreign-provider rules, the gateway provider obligations (section 64.6302) or the penalty provisions. It is a short section of three duties plus the third-party rule. Amendments were last recorded at 90 Federal Register 40255 (August 19, 2025). For the rest of the framework, the Robocall Mitigation Database page and the eCFR's sections 64.6302 through 64.6308 are the places to continue.

Sources

• 47 CFR 64.6301, Caller ID authentication (eCFR). Read November 2, 2026.
• 47 CFR 64.6305, Robocall mitigation and certification (eCFR), for the database cross-reference. Read November 2, 2026.

Text read: the eCFR (Electronic Code of Federal Regulations) text of Title 47 as it stood on October 29, 2026, retrieved through the eCFR versioner API on November 2, 2026. The eCFR is an editorial compilation and is not the official legal edition; the Federal Register and the annual CFR are. Rules change, so confirm the current wording on the eCFR before relying on it. This page paraphrases the rule and does not replace it.