STIR/SHAKEN A-Level Attestation: What It Takes to Self-Attest Your Calls

If you are a voice service provider in the United States, the rules around STIR/SHAKEN attestation have changed significantly. Upstream carriers like Bandwidth have shifted their attestation policies, reducing wholesale and reseller traffic from A-level (full attestation) down to C-level (gateway attestation). At the same time, the FCC’s Third-Party Authentication Order now requires every provider with a STIR/SHAKEN implementation obligation to obtain their own certificate and make their own attestation-level decisions.

The result: providers who previously relied on their upstream carrier to sign and attest calls must now build and manage that capability themselves. This guide explains what A-level attestation requires, how to implement it at the SBC layer, and the operational processes you need to keep it working.

What A-Level Attestation Actually Means

STIR/SHAKEN (Secure Telephone Identity Revisited / Signature-based Handling of Asserted information using toKENs) defines three attestation levels that a service provider assigns when signing an outbound call.

Full Attestation (A)

The originating provider has authenticated the calling party and confirmed that the caller is authorized to use the originating phone number. The provider has a direct relationship with the customer, knows who they are, and has verified their right to use the number appearing in caller ID.

Partial Attestation (B)

The provider knows where the call originated within their network but has not verified the caller’s authorization to use the specific number. This typically applies to calls from known customers using numbers the provider cannot fully validate.

Gateway Attestation (C)

The call entered the provider’s network from an external, untrusted source. The provider has no knowledge of the caller’s identity or their right to use the number. This is the lowest level of trust.

The practical impact is significant. Calls carrying A-level attestation are far less likely to be flagged with “Scam Likely” or “Spam Risk” labels by analytics engines at the terminating end. Some carriers have adopted policies to block all calls arriving with C-level attestation outright. For your customers, the difference between A and C attestation can mean the difference between their calls connecting and their calls being silently dropped.

Why Providers Are Being Forced to Self-Attest

Two converging forces are pushing voice providers to take direct control of STIR/SHAKEN attestation.

The FCC’s Third-Party Authentication Order

Adopted in November 2024 and effective as of September 18, 2025, this order requires every voice service provider with a STIR/SHAKEN implementation obligation to obtain a Service Provider Code (SPC) token from the STIR/SHAKEN Policy Administrator, present that token to a Certificate Authority (CA) to get their own digital certificate, and make all attestation-level decisions themselves. Providers can still use a third party to perform the technical act of signing, but the certificate must be the provider’s own, and the attestation decision must be the provider’s own. You can no longer rely on your upstream carrier’s certificate or defer attestation decisions to them.

Carrier Policy Changes

Upstream carriers and wholesale providers have been adjusting how they attest traffic that originates from resellers and downstream providers. Where a carrier like Bandwidth may have previously signed calls with A-level attestation on behalf of their customers, many now assign C-level (gateway) attestation to traffic they cannot fully authenticate at the subscriber level. This is a rational response to regulatory pressure: the carrier cannot verify KYC for a downstream provider’s end customer, so they cannot honestly attest at A-level. The burden shifts to the provider who does have that customer relationship.

RMD Compliance Deadlines

The Robocall Mitigation Database (RMD) requires annual recertification, with the most recent window closing March 1, 2026. The FCC has increased enforcement penalties: $10,000 for filing false or inaccurate information in the RMD, and $1,000 for failing to update your filing within 10 business days when required. CORES information tied to your FRN (FCC Registration Number) must also be kept current with the same 10-business-day update requirement.

This is not theoretical. Consider a VoIP provider using Bandwidth as their upstream carrier. When Bandwidth attested their outbound traffic at A-level, everything worked. When Bandwidth shifted that traffic to C-level attestation, the provider’s customers started seeing their calls flagged and blocked. The only path back to A-level attestation is for the provider to obtain their own certificate, integrate with a signing service, and make their own attestation decisions based on their direct knowledge of their customers.

The Four Requirements for A-Level Attestation

Achieving A-level attestation is not purely a technology problem. It requires a combination of operational processes and infrastructure. Here are the four things you need.

1. Know Your Customer (KYC)

You must have a direct, verified relationship with the party originating the call. This means you know who they are, you have their identity on file, and you can confirm they are a legitimate customer of your service. If you are a wholesale provider passing traffic from an unknown source, you cannot honestly assign A-level attestation to that traffic.

2. Number Authorization Verification

You must verify that the calling party is authorized to use the phone number appearing in caller ID. This means maintaining accurate records of which numbers are assigned to which customers. For ported numbers, you need the porting documentation. For numbers assigned from your own inventory, you need the assignment records. For toll-free or other special number types, you need the Letter of Authorization (LOA) on file.

3. Your Own SPC Token and Digital Certificate

You must obtain an SPC token from the STI-PA (STIR/SHAKEN Policy Administrator, currently operated by the Governance Authority) and use that token to acquire your digital certificate from an STI-CA (Certificate Authority). This certificate is what your signing service uses to create the cryptographic signature on outbound calls. Under the FCC’s rule, you cannot use another provider’s certificate.

4. Your Own Attestation Decision

You, as the originating provider, must make the determination that a specific call qualifies for A-level attestation. A third party can handle the technical signing, but the decision about which attestation level to assign must be yours, based on your KYC records and number authorization data.

How the SBC Fits Into STIR/SHAKEN Signing

The Session Border Controller (SBC) sits at the originating edge of your voice network, which is precisely where STIR/SHAKEN signing takes place. Here is how the signing flow works:

1. Your customer originates a call that arrives at the SBC.
2. The SBC sends a signing request to your external STI-AS (Authentication Service), passing the call parameters: the originating number (from the P-Asserted-Identity or From header), the destination number (from the To header), and a timestamp.
3. The STI-AS creates a PASSporT (Personal Assertion Token) containing the orig, dest, iat (issued-at timestamp), origid (origination identifier), and attest fields, signs it with your digital certificate, and returns the signed Identity header.
4. The SBC inserts the Identity header into the outgoing SIP INVITE before forwarding the call to the next hop.

The SBC itself does not perform the cryptographic signing. It acts as the integration point between your voice network and the external signing service. This is an important distinction: the signing service (such as TransNexus ClearIP or Neustar) holds your certificate and performs the actual cryptographic operations. The SBC’s job is to query the signing service at the right moment in the call flow, pass the correct parameters, and insert the resulting Identity header into the SIP message.

For high availability, your signing integration should support redundancy. If your primary signing service is unreachable, the SBC should automatically fail over to the secondary. And if both are unavailable, the SBC continues the call to the destination. So the call is not silently dropped while still signaling to downstream providers that signing was attempted but unavailable.

Implementing A-Level Attestation with ProSBC

ProSBC‘s approach to STIR/SHAKEN differs from most SBC vendors in one important way: it uses an open partner model. Where vendors like Ribbon and AudioCodes have built proprietary STIR/SHAKEN implementations that tie you to a specific signing service partner, ProSBC’s configurable Ruby routing engine integrates with any HTTP or SIP-based signing service. You choose your STI-AS provider. If you want to switch signing services later, you change a configuration parameter, not your SBC vendor.

The implementation involves pointing ProSBC at your signing service:

Signing Service Configuration

You configure a primary signing provider (SIP NAP in ProSBC configuration) and (optionally) a secondary provider for redundancy. You provide an authorization token for API authentication and set a timeout value for the query to the signing service.

Call Parameter Extraction

When a call arrives, ProSBC’s STIR/SHAKEN routing module extracts the originating number from the P-Asserted-Identity (PAI) or From header, the destination number from the To header, and the timestamp from the Date header. These are packaged into a signing request.

Identity Header Insertion

The signing service returns the signed Identity header, which ProSBC inserts into the outgoing SIP INVITE. The Identity header contains the digital signature, attestation level, originating and destination numbers, timestamp, and a reference to your certificate.

Redundancy and Fallback

If the primary signing provider fails or times out, ProSBC automatically tries the secondary provider. If both are unavailable, it appends a P-Identity-Bypass header to the outgoing call. This ensures calls still complete even during a signing service outage, while transparently indicating to downstream providers that signing was attempted.

Verification on the Terminating Side

ProSBC also supports the verification role. When acting as the terminating SBC, it can validate incoming Identity headers against the signing certificate, confirming the call’s attestation is legitimate.

ProSBC integrates with validated TelcoBridges Alliance Partners including TransNexus ClearIP and Neustar for STIR/SHAKEN signing and verification. Both have documented integration paths.

Operational Checklist for Maintaining A-Level Attestation

Getting A-level attestation working is only half the battle. Maintaining it requires ongoing operational discipline. Here is what to build into your processes:

KYC at Onboarding

Verify every new customer’s identity before provisioning service. This is not just good practice; it is the foundation of your ability to assign A-level attestation. If you cannot prove you verified the customer, you cannot defend your attestation decision.

Number Inventory Management

Maintain an accurate, up-to-date record of which phone numbers are assigned to which customers. When numbers are ported in, file the porting documentation. When numbers are reassigned, update your records. Your attestation decision depends on knowing, at the moment of each call, that the caller is authorized to use that number.

Certificate Lifecycle Management

Your digital certificate has an expiration date. Monitor it. Renew it before it lapses. A lapsed certificate means your signing service cannot sign calls, which means your outbound calls will either go out unsigned or fall back to P-Identity-Bypass, neither of which gives you A-level attestation.

RMD Maintenance

Keep your Robocall Mitigation Database filing current. Recertify annually. Update within 10 business days any time your information changes. The penalties for non-compliance are real: $10,000 for false information, $1,000 for late updates.

Attestation Monitoring

Review your Call Detail Records (CDRs) regularly to confirm that outbound calls are receiving the correct attestation level. If you see calls going out with B or C attestation that should be A, investigate. The issue is usually a gap in your number authorization records or a signing service configuration problem.

Signing Service Health Monitoring

Track the success and failure rates of your signing service queries. Alert on elevated timeout rates or HTTP or SIP errors. A healthy signing service should have near-zero failure rates; sustained failures mean your calls are going out unsigned.

Common Mistakes That Cost You A-Level Attestation

These are the operational failures that most commonly result in providers losing their ability to assign A-level attestation:

Allowing Unverified Caller ID Usage

If your customers can set arbitrary numbers in their caller ID without your verification, you cannot attest at A-level. Every number used in outbound calls must be traceable to an authorized customer in your records.

Stale Number Records

Numbers get ported, reassigned, and disconnected. If your authorization records do not reflect current assignments, you risk attesting calls where the caller is no longer authorized to use that number. This exposes you to regulatory action.

Using Someone Else’s Certificate

The FCC’s own-certificate rule is explicit: your calls must be signed with your certificate. If you are still relying on your upstream carrier’s certificate, you are out of compliance regardless of the attestation level.

Ignoring Signing Service Failures

If your signing service goes down and you do not notice, your calls are going out with P-Identity-Bypass headers instead of proper attestation. Downstream providers and analytics engines treat these very differently from properly signed calls.

Missing RMD Deadlines

The recertification window is annual. Missing it, or failing to update your filing after material changes, triggers FCC penalties and can result in your calls being treated as non-compliant by other providers.

What Happens When You Get It Right

The payoff for building and maintaining A-level attestation capability is concrete:

Higher Call Completion Rates

Your customers’ outbound calls reach their intended recipients instead of being blocked or filtered. For contact centers, sales teams, and service providers, this directly impacts revenue.

Better Caller ID Reputation

Analytics engines (the systems that label calls as “Scam Likely” or “Spam Risk”) factor attestation level into their scoring. A-level attestation is one of the strongest positive signals you can send.

Regulatory Compliance

You meet the FCC’s requirements for STIR/SHAKEN implementation, certificate ownership, and attestation decision-making. This is not optional for providers with an implementation obligation.

Competitive Differentiation

When your customers’ calls connect cleanly and your competitor’s customers’ calls get flagged, that difference shows up in churn rates. Providers who can guarantee A-level attestation for legitimately authorized calls have a real selling point.

Frequently Asked Questions