STIR/SHAKEN Certificate Authorities and the STI-CA Ecosystem

Every signed call in the STIR/SHAKEN framework carries a cryptographic signature, and that signature is only trustworthy because it chains back to a certificate a terminating carrier can verify. Behind that certificate sits a small, tightly governed public key infrastructure (PKI): a governance authority that sets the rules, a single Policy Administrator that enforces them, and a short list of approved Certificate Authorities that actually issue the certificates. If you operate a voice network in the United States, you cannot sign a call at any attestation level until you have registered into this ecosystem and obtained your own certificate.

This guide explains who the players are, how the trust chain fits together, and the exact steps a voice service provider follows to register, obtain a Service Provider Code token, and receive an STI certificate. It also covers the FCC’s own-certificate rule, which changed what “using a third party to sign your calls” is allowed to mean, and where a Session Border Controller (SBC) fits once your certificate is in hand.

Why STIR/SHAKEN Needs a Certificate Ecosystem

A signature only means something if the party checking it can trust where it came from. When a terminating carrier receives a call with a STIR/SHAKEN Identity header, it needs to answer one question quickly and automatically: was this call signed by a provider the industry has vetted, using a certificate that has not been revoked? Answering that at scale, across thousands of providers, is exactly the problem a public key infrastructure solves.

The design borrows the same trust model that secures websites. A website’s TLS certificate is trusted because it chains up to a recognized root authority your browser already trusts. STIR/SHAKEN works the same way, with one important difference: participation is closed and governed, not open. You cannot simply buy a certificate. You must first be confirmed as a legitimate voice service provider, which is what the governance layer exists to enforce.

That closed model is what makes the framework resistant to abuse. A robocaller cannot obtain a valid certificate because it cannot pass the vetting that produces the token a Certificate Authority requires. The ecosystem’s structure, rather than any single piece of cryptography, is what ties a signature back to an accountable, identifiable company.

The Four Roles in the Trust Chain

Four distinct roles make the ecosystem work, and keeping them straight is the key to understanding where your responsibilities begin and end. The first three are governance and infrastructure; the fourth is you.

Governance Authority (STI-GA)

The Secure Telephone Identity Governance Authority, administered through ATIS, sits at the top. It does not touch a single call. Instead, it defines the policies that everyone else follows: eligibility rules for providers, the technical requirements for certificates, and the process for selecting and overseeing the Policy Administrator. The STI-GA also sets the annual funding model that spreads the cost of running the ecosystem across participants, scaled by size so the largest carriers pay the most and the smallest pay a modest minimum.

Policy Administrator (STI-PA)

The Policy Administrator is where governance becomes operational, and in the United States that role belongs to iconectiv, selected by the STI-GA and confirmed for a second term after the initial agreement. The Policy Administrator performs the work that makes the trust chain real: it vets each applicant against FCC records, issues Service Provider Code tokens to those that qualify, approves and monitors the Certificate Authorities, and publishes the trusted list and revocation data that verification services rely on. Nothing enters the ecosystem without passing through the Policy Administrator first.

Certificate Authority (STI-CA)

An approved Certificate Authority issues the certificate you actually sign calls with. Iconectiv approves each CA through a controlled process and monitors it on an ongoing basis, so the label “approved STI-CA” is meaningful rather than self-declared. A CA cannot issue you a certificate on trust or reputation alone. It must receive a valid, current Service Provider Code token, which mathematically ties every certificate it issues back to the Policy Administrator’s vetting.

Voice Service Provider (you)

The fourth role is the provider that originates or signs calls. Your job is to register correctly, obtain a token, get a certificate from an approved CA, and then use that certificate to sign the calls you send. The FCC places the responsibility for signing and for attestation-level decisions on you, the provider with the STIR/SHAKEN obligation, even when the mechanical act of signing is performed by a partner.

Who the Approved Certificate Authorities Are

The Policy Administrator maintains the authoritative list of approved Certificate Authorities, and that list is the only source you should treat as definitive when choosing one. Several established providers operate as approved STI-CAs, and many of them bundle the certificate with the rest of the signing stack so a provider can obtain everything from a single partner.

Certificate Authority	Typical offering	Certificate delivery
TransNexus	Full stack: CA, signing/verification, CPS, testing	Web portal or REST API
Sansay	Approved for US and Canadian certificates	Portal-based issuance
Others on the approved list	Vary by provider (Peeringhub, Telonium, Ribbon, and more)	Portal or API, varies

How Registration Works, Step by Step

Getting from “we operate a voice network” to “we can sign calls with our own certificate” follows a defined sequence. Each step depends on the one before it, so the order matters.

1. Establish your regulatory identityObtain an Operating Company Number if you do not already have one, and file your FCC Form 499-A. These records are what the Policy Administrator checks to confirm you are a legitimate voice service provider rather than an anonymous applicant.
2. Register in the Robocall Mitigation DatabaseFile your robocall mitigation plan and certify your STIR/SHAKEN status in the FCC’s Robocall Mitigation Database. Carriers are prohibited from accepting traffic from providers that are not listed, so this filing is foundational and must be kept current.
3. Apply to the Policy AdministratorRegister with iconectiv as the Policy Administrator. It verifies your OCN, your Form 499-A, and your RMD listing, confirming that all three point to the same legitimate entity before granting access.
4. Obtain your Service Provider Code tokenOnce approved, request an SPC token from the Policy Administrator. The token is short-lived by design and is refreshed periodically, which is why signing services automate its retrieval rather than treating it as a one-time credential.
5. Request a certificate from an approved CAPresent your token to an approved Certificate Authority. The CA validates the token against the Policy Administrator, then issues your STI certificate, delivered through its web portal or REST API depending on the provider.
6. Load the certificate into your signing serviceInstall the certificate and its private key where your Authentication Service can reach them. From this point your outbound calls can be signed with your own certificate, and terminating carriers can verify them against the trusted list.

The FCC Own-Certificate Rule

For years, many smaller providers relied on an upstream carrier or a third party to sign their calls, using that third party’s certificate. The FCC closed that arrangement. Under the Call Authentication Trust Anchor order (FCC 24-120), effective September 18, 2025, the provider that holds the STIR/SHAKEN obligation must ensure every call is signed with its own certificate obtained from a Certificate Authority, and must make its own attestation-level decisions.

The rule does not ban third-party signing outright. A partner may still perform the mechanical act of signing, but only under a written agreement establishing that the calls are signed with the provider’s own certificate, that the third party is performing only the signing operation, and that the provider makes the attestation-level decision. In other words, you can outsource the keystroke but not the identity. Using a third party to sign traffic without meeting these conditions is a violation of the Commission’s caller ID authentication rules.

The practical consequence is that obtaining your own SPC token and your own certificate, the process described above, is no longer optional for providers that were leaning on someone else’s. If you were relying on an upstream carrier’s certificate and have since seen your attestation quality drop, this rule is very often the reason, and the fix is to complete your own registration and move to signing with your own certificate.

Where the SBC Fits Once You Have a Certificate

The certificate ecosystem answers the question of identity: who you are and whether you are trusted. It does not place a signature on an actual call. That happens in your call path, and it is where the SBC and the signing service do their work. Understanding the boundary keeps expectations realistic: an SBC is not a Certificate Authority and does not issue or hold ecosystem trust; it uses the certificate you have already obtained.

In a typical deployment, the SBC sits at the network edge and routes each outbound call to a signing service, the STI-AS, which constructs the PASSporT, signs it with your certificate’s private key, and returns the Identity header the SBC attaches to the outbound INVITE. For inbound calls, the SBC hands the Identity header to a verification service (STI-VS) that checks the signature against the trusted list and revocation data, then applies your policy based on the result. Because the attestation level is a per-call decision, the routing engine, not a static setting, is the right place to make it.

The signing service and the SBC are separate from the CA precisely so you can choose each independently. A programmable SBC integrates with the signing partner over the protocol that partner prefers, which keeps the certificate ecosystem, the signing service, and the edge as three interchangeable components rather than one locked bundle.

Frequently Asked Questions

Conclusion

The STIR/SHAKEN certificate ecosystem is small by design: a Governance Authority that writes the rules, one Policy Administrator that enforces them and issues tokens, a short list of approved Certificate Authorities that issue certificates, and the providers that register and sign. The closed, vetted structure is what lets a terminating carrier trust a signature it has never seen before. Your path through it is straightforward once the order is clear: establish your regulatory identity, register in the Robocall Mitigation Database, get vetted by the Policy Administrator, obtain your SPC token, and use it to get your own certificate from an approved CA.

The FCC’s own-certificate rule made that path mandatory rather than optional for providers that had been relying on someone else’s certificate. Once your certificate is in hand, the ecosystem’s job is done and your call path takes over, with the SBC and signing service using the certificate to sign and verify calls in real time.