December 2024: Understanding the FCC's Eighth Report & Order

The FCC's Eighth Report and Order increases the obligations of service providers to implement STIR/SHAKEN, aiming to enhance transparency across the ecosystem. By requiring all originating providers to sign their own calls, the order looks to bolster transparency and trust in voice communications. Additionally, it sets clear guidelines for implementing STIR/SHAKEN, striking a balance between compliance mandates and practical technical considerations.

The implementation obligation applies to all providers that originate calls and have control over the network infrastructure necessary to implement STIR/SHAKEN.

By requiring calls to be signed using the certificate of the provider with the implementation obligation, the STIR/SHAKEN governance model will be able to function as intended by making it easier to identify providers responsible for any authentication information transmitted with a call and facilitating enforcement remedies that may be needed for failures to comply with authentication requirements, including, for example, revocation of a provider’s SPC token by the Secure Telephone Identity Governance Authority (STI-GA).

All Originating Service Providers (obligated to implement STIR/SHAKEN) need to:

1. Obtain a STIR/SHAKEN certificate. To obtain a certificate, a Service Provider must:
   1. Have a current form 499A on file with the FCC;
   2. Have an Operating Company Number (OCN) from NECA
   3. Have certified with the FCC that it has implemented STIR/SHAKEN or complies with the FCC’s Robocall Mitigation Program requirements and is listed in the RMD, or that it has direct access to telephone numbers from the Toll-Free Number Administrator (TFNA).  
   4. Obtain an SPC token.
2. Certify to complete or partial implementation in the FCC Robocall Mitigation Database only if they have obtained an SPC token and STIR/SHAKEN certificate and sign calls with their certificate; and
3. Memorialize and maintain records of any third-party authentication agreement(s) they have entered into, subject to certain limitations.

The FCC describes acceptable implementations including 3rd parties under the following rules:

The provider with the STIR/SHAKEN implementation obligation: (1) makes all attestation level decisions,
consistent with the STIR/SHAKEN technical standards; and (2) ensures that all calls are signed using its
own certificate obtained from a STIR/SHAKEN Certificate Authority—not the certificate of a third party.

Compliance Deadline

The eight order was released on November 22, 2024 and establishes the following deadlines:

• 30 days after publication of this Report and Order in the Federal Register following OMB approval, or 
• 210 days after release of the Order, whichever is later. The Order was released on November 22, 2024.

The tentative compliance deadline is June 20, 2025.

Technical Implementation

The permitted third-party authentication rules offer new STIR/SHAKEN Originating Service Providers participants flexibility to to implement STIR/SHAKEN. A third-party authentication implementation looks like this:

1.  OSP unsigned traffic arrives at Intermediate Provider. OSP has an an agreement with the Intermedia Provider(s) to perform third-party call signing.
2. The Intermediate Provider, on a per-call basis, performs call authentication against the OSP's STI-AS system.  The STI-AS system uses the OSP's STIR/SHAKEN certificate obtained from an STI-CA after SPC token procedures from the STI-PA infrastructure.
3. All traffic sourced by the OSP and routed through the Intermediate Provider is signed with the OSP's certificate following attestation rules defined by the OSP.
4. The Terminating Service Provider (TSP) is performs call verification and despite the Intermedia Provider's efforts to technologically sign the call, sees the OSP in the SHAKEN digital signature as the originator of the call.

Why would a provider want to do 3rd-party call authentication?

While there are benefits to performing in-network call authentication, a provider trying to obtain compliance may want to opt for 3rd party call authentication for any of the following reasons.

1. Technical limitations. The provider's existing infrastructure may not support STIR/SHAKEN yet.
2. Limited resources. There are limited resources available to reach compliance in a timely matter.
3. Cost. 3rd-party call authentication may reduce the cost to implement STIR/SHAKEN.
4. Minimize risks. A provider may want to minimize risks associated with the STIR/SHAKEN implementation.

Whether you are looking at deploying 1st-party (in-network) or third-party call authentication, Sansay's STIR/SHAKEN solution is highly interoperable. We support SIP and REST interfaces and work with a large list of SBCs, PBXs and Switches.

How do I know if I'm compliant?

A simple way to understand compliance is by using Sansay's SHAKEN Echo Number. Any calls made from your network should already be carrying your OCN/certificate. If not, you have changes to make in your network.

To make your tests visit https://test-shaken.sansay.cloud