STIR/SHAKEN Policy Administrator& How iconectiv Manages Telecom Trust

iconectiv currently serves as the U.S. STI-PA. Its role exists within the broader Secure Telephone Identity Governance Authority ecosystem, which includes multiple organizations and functions that should not be confused with one another.

The STI-PA performs several trust-framework functions. iconectiv's STI-PA materials describe its role in the STIR/SHAKEN ecosystem and its handling of Service Provider Code tokens. The important concept is that the STI-PA establishes trust and authorization within the framework — it does not simply act as another SIP carrier.

The Secure Telephone Identity Governance Authority (STI-GA) is part of the governance structure for the STIR/SHAKEN ecosystem. The governance layer establishes the rules and policies under which the trust framework operates. ATIS's STI-GA documentation uses terminology including the FCC, SHAKEN, SIP, Service Provider, Service Provider Code, Policy Management Authority and Public Key Infrastructure — illustrating that STIR/SHAKEN is an industry governance and cryptographic framework rather than merely a carrier-specific feature.

This table should not be interpreted as a complete technical specification, but it is useful for understanding how the architecture is organized.

The Service Provider Code (SPC) is an important identifier in the STIR/SHAKEN trust framework. It is used as part of the process by which a service provider is authorized to obtain certificates — the provider does not simply generate a certificate independently; it participates in the trust system.

The SPC token is associated with the provider's authorization to obtain a certificate. It should not be confused with the certificate itself: the token helps establish authorization, while the certificate provides the cryptographic signing credentials.

The safest technical explanation is that the STI-PA and STI-CA functions are different. The Policy Administrator manages the policy/trust process and authorization mechanisms; an authorized Certification Authority issues the certificate.

A useful way to understand the architecture is as a chain running from governance down to a verified, signed call. This is a conceptual representation — actual technical implementations include additional components and policies.

Certificates can have validity and trust status. If a certificate is compromised, misused or otherwise needs to be invalidated, the applicable trust framework includes mechanisms for revocation and trust management — otherwise a compromised credential could remain trusted indefinitely. The certificate itself is not the only security concern: providers must also protect the corresponding private signing key, since an attacker who obtains it could potentially create signatures that appear to come from the legitimate signing entity.

A certificate alone does not mean every customer call deserves Full Attestation. The provider still needs to determine its relationship with the caller and the telephone number before applying the relevant attestation level.

Suppose NexGen Voice provides service to a business customer with ten DIDs. The system must know that the customer is legitimate, that those DIDs are authorized for that customer, that the customer is permitted to use those numbers as CLI, and that traffic is being monitored with active fraud controls. When the customer makes a call, the provider can evaluate the relationship between the customer, the telephone number and the call — and if the requirements for Full Attestation are satisfied, the originating provider may apply the appropriate A-level attestation, which becomes part of the signed information the terminating provider verifies.

STIR/SHAKEN operates within a broader FCC robocall-mitigation environment. The FCC's current RMD framework requires covered providers to submit information and certifications related to robocall mitigation and caller-ID authentication. This means a provider should manage STIR/SHAKEN, RMD filing, customer verification, traffic monitoring, traceback and upstream-provider knowledge as related — but not interchangeable — components of a broader compliance program.

A reseller may rely on an upstream provider for STIR/SHAKEN signing, which can be operationally practical. However, the reseller should understand what its upstream provider actually does rather than assuming that purchasing a SIP trunk automatically transfers every compliance responsibility to the upstream carrier — the contract and actual architecture matter.

For a company operating in VoIP, SIP trunking, DID numbers and wholesale telecommunications, technically accurate wording is more valuable than aggressive claims. Recommended wording: "NexGen Voice uses STIR/SHAKEN authentication through its carrier infrastructure, where applicable customer and telephone-number verification requirements are satisfied." Statements such as "NexGen has an A-level certificate" or "NexGen guarantees every call receives A attestation" should be avoided, since neither accurately represents the framework.

This guide is educational. It does not describe NexGen Voice's own certificate status, RMD registration, or other regulated filings. For questions about a specific service, contact our team.

The STIR/SHAKEN Policy Administrator is an important part of the trust infrastructure behind caller-ID authentication. The key concepts — STI-GA, STI-PA, SPC token, STI-CA, digital certificate, signing, attestation and verification — each serve a different purpose and should not be treated as interchangeable.

For a professional VoIP provider, understanding these distinctions is important for carrier relationships, compliance, customer verification and call authentication. For NexGen Voice, accurate technical language should always take priority over marketing shorthand.

Further reading from authoritative sources: FCC, USAC and the iconectiv STI-PA resources.