FCC STIR/SHAKEN Own-Certificate Rule: What Voice Providers Must Know

Since September 18, 2025, every voice service provider with a STIR/SHAKEN implementation obligation has been required to sign calls with their own digital certificate, not a third party’s. If your organization has been relying on a vendor-shared certificate, that arrangement is no longer compliant.

The FCC’s Eighth Report and Order closed the door on a common shortcut: using your signing service’s certificate instead of your own. Third-party signing is still allowed. But the certificate must be yours, the attestation decisions must come from you, and you need a written agreement that spells all of that out.

If you haven’t audited your signing arrangement since the rule took effect, this page walks through what’s required, who’s affected, and how to verify your configuration meets the standard.

What the FCC’s Own-Certificate Rule Actually Requires

The rule is straightforward: if you have a STIR/SHAKEN implementation obligation, your calls must be signed with your own certificate: the one you obtained using your own Service Provider Code (SPC) token.

Before September 2025, a provider could contract with a signing service and have calls signed using the vendor’s certificate. That’s no longer compliant for obligated providers.

The rule also defines where attestation decisions must live with you, not the signing service. Attestation level determines what you’re asserting about each call:

• Level A (Full Attestation): You can authenticate the calling party, their number, and that they’re authorized to use it.
• Level B (Partial Attestation): You can authenticate the originating customer and call source, but not whether the calling party is authorized to use the specific number.
• Level C (Gateway Attestation): The call entered your network from an external source you can’t authenticate.

A signing service can perform the technical act of signing, but it cannot decide the attestation level. That determination must come from your organization, not the signing service.

What a Written Agreement Must Cover

Any provider using a third party to perform STIR/SHAKEN signing needs a written agreement that explicitly states:

1. Calls will be signed using your certificate, not the third party’s
2. The third party is only performing the act of digitally signing
3. Your organization makes all attestation-level decisions

That agreement should be preserved in the event of an inspection by the FCC.

Who Is Affected, and Who Is Exempt

The September 18, 2025 rule applies to all service providers with a STIR/SHAKEN implementation obligation: carriers, CLECs, and interconnected VoIP providers who originate calls and control the infrastructure to sign them.

Resellers and Mobile Virtual Network Operators (MVNOs) are generally exempt; they don’t control the infrastructure needed to implement STIR/SHAKEN and aren’t required to obtain their own SPC token under this rule.

Robocall Mitigation Database Update

If your organization has filed “complete” or “partial” STIR/SHAKEN implementation status in the Robocall Mitigation Database (RMD), your certification must now reflect that you hold an SPC token and digital certificate, and that calls are signed with your certificate. Any third-party signing arrangement should also be documented in your records.

The Three-Part Compliance Test

Compliance comes down to three concrete checkpoints:

1. You have your own SPC token. Obtained from the STIR/SHAKEN Policy Administrator (STI-PA). This is your foundational credential in the STIR/SHAKEN ecosystem.
2. Your calls are signed with your own certificate. You present your SPC token to a STIR/SHAKEN Certificate Authority (STI-CA) to obtain that certificate. All calls must be signed with it (not a third party’s), regardless of who performs the signing operation.
3. You make the attestation decisions. Attestation level A, B, or C is determined by your organization based on what you know about each call’s origin. The signing service executes the signing based on the level you supply; it doesn’t assign it independently.

Meet all three, with a written agreement in place if you use a third party, and you’re compliant.

How Session Border Controllers Fit Into STIR/SHAKEN Compliance

Session Border Controllers (SBCs) sit at the originating edge of your network, which is exactly where STIR/SHAKEN signing happens. Understanding the architecture helps clarify where compliance controls need to live.

In a typical implementation, the SBC receives a call from your originating customer and initiates a signing request to an external STIR/SHAKEN Authentication Service (STI-AS) before forwarding the call. That signing request carries your provider credentials and the attestation level you’ve determined for the call. The STI-AS fetches your certificate from your STI-CA, generates the PASSporT token, and returns a signed Identity header, which the SBC injects into the outbound SIP INVITE.

Several architectural points are worth confirming with your SBC vendor:

• Your credentials travel with the signing request. The SBC should pass your authorization token and signing service URL in the request; the certificate used to sign the call must be registered to your domain, not the signing service’s.
• Attestation control stays at the routing layer. The SBC should populate the attest parameter in the signing request based on your routing logic and what it knows about each call source. A compliant architecture gives the signing service no independent authority to override or modify attestation level.
• Redundancy for signing service availability. SBCs that support both a primary and secondary signing service URL give you automatic failover without manual intervention.
• Graceful handling when signing fails. When a signing service is unreachable, the call should still complete, with a mechanism to signal to downstream providers that signing was unavailable for that call. It’s worth reviewing how your SBC handles this edge case to confirm it aligns with FCC expectations.

How to Verify Your Compliance

The rule has been in effect since September 18, 2025. Use this checklist to audit your configuration:

1. Confirm your STIR/SHAKEN obligation. Verify whether your organization is an obligated service provider or falls under an exemption.
2. Confirm you hold your own SPC token. Obtained from the STI-PA prior to or shortly after September 18, 2025. If not yet obtained, this is your first corrective step.
3. Confirm calls are signed with your own digital certificate. Verify with your signing service that the certificate currently in use is yours, not a vendor-shared one.
4. Verify your signing service is configured with your certificate. Whether you use TransNexus, Neustar, or another STI-CA-integrated service, confirm it’s signing with your certificate, not the service’s own.
5. Confirm a written agreement is in place. The agreement must state: your certificate is used, the third party only performs the signing operation, and your organization makes all attestation decisions. Retain it for FCC inspection.
6. Audit your SBC configuration. Confirm your signing service URL points to an integration using your credentials and certificate. Review your routing logic to verify attestation level rules correctly reflect your knowledge of each call source.
7. Verify your Robocall Mitigation Database certification is current. Your RMD filing should reflect SPC token ownership, own-certificate signing, and memorialize any third-party signing arrangement in place.

If You’re Using a Signing Service: You’re Probably Fine. Check These Three Things.

The FCC’s own-certificate rule doesn’t prohibit third-party signing. It defines the conditions under which it’s lawful: your certificate, your attestation decisions, your written agreement.

Most well-architected STIR/SHAKEN implementations already follow this model: attestation is set at the routing layer, credentials belong to the provider, and the signing service executes the request. The audit checklist above covers everything you need to confirm compliance.