Caller ID spoofing can make fraudulent calls appear to originate from legitimate businesses or familiar numbers. STIR/SHAKEN helps telecom providers authenticate caller identity, but the framework also depends on trusted organizations that manage participation and establish the rules for obtaining authentication credentials.
One important component is the Secure Telephone Identity Policy Administrator (STI-PA). It operates at the policy and governance layer of the STIR/SHAKEN ecosystem, helping establish the conditions under which service providers can participate and obtain the credentials required for caller authentication.
Understanding the STI-PA is essential for telecom operators, voice service providers and communications infrastructure teams seeking to understand how caller authentication is organized and maintained.
What Is the STI-PA?
Understanding its place in STIR/SHAKEN
STIR/SHAKEN is a framework designed to help service providers authenticate caller ID information using digital certificates and cryptographic signatures. It helps receiving providers assess whether caller identity information has been authenticated by an authorized participant.
The STI-PA operates at a different level from the systems that sign or verify individual calls. Its role concerns the policies and authorization framework that supports participation in the ecosystem.
In the United States, the STI-PA's responsibilities include administering the governance process for the framework and managing the requirements service providers must satisfy to obtain credentials for STIR/SHAKEN authentication.
A useful analogy is a professional licensing authority. The authority does not perform every professional's daily work; it establishes participation requirements and determines who qualifies to operate under the relevant rules.
Why the STI-PA matters
Without a defined policy and authorization structure, certificate issuance could become inconsistent and difficult to govern across a large telecommunications ecosystem.
The STI-PA helps create a common foundation for participation. This supports a more organized environment in which authorized providers can obtain the credentials needed to authenticate calls according to applicable requirements.
It is important to distinguish this policy function from the technical work performed by Certificate Authorities (CAs), authentication services and verification systems. These components work together but perform different responsibilities.
How the STI-PA Fits Into the STIR/SHAKEN Architecture
Understanding the key participants
STIR/SHAKEN involves several distinct roles. Understanding their relationship helps clarify why the STI-PA is necessary.
STI-PA: Administers the applicable policy and authorization framework for participation.
STI-CAs: Issue Secure Telephone Identity certificates to eligible participants under the applicable requirements.
STI-Certificate Repositories (STI-CRs): Make public certificates available so receiving systems can retrieve them for verification.
Authentication services: Generate signed caller identity information for calls handled by participating providers.
Verification services: Check the signature and certificate associated with the received call to help assess the authenticity of the caller identity information.
The STI-PA does not replace these technical systems. Instead, it supports the policy framework under which authorized participants obtain the credentials used by them.
An example of how the roles connect
Suppose a voice service provider wants to authenticate outbound calls from its customers. It must meet the applicable participation requirements and obtain the necessary credentials through the authorized process.
A Certificate Authority issues the relevant certificate. The provider's authentication service uses the associated signing capability to create authenticated caller identity information. The receiving provider can then use verification infrastructure and the published certificate to evaluate the signature.
The STI-PA's role is associated with the policy and authorization arrangements that support the provider's eligibility to participate. It does not personally sign each call or verify every call passing through the network.
This separation of responsibilities allows policy administration and technical call processing to operate as distinct but connected functions.
What Responsibilities Does the STI-PA Handle?
Provider eligibility and authorization
A central responsibility of the STI-PA is to apply the rules established by the Secure Telephone Identity Governance Authority (STI-GA). These rules determine which participants can access the credentials needed for STIR/SHAKEN authentication.
Depending on the applicable requirements, a provider may need to establish its identity, supply relevant organizational information and demonstrate eligibility before it can obtain the credentials used to request certificates.
In the US framework, the Operating Company Number (OCN) is an important identifier for eligible service providers. Providers should confirm current registration requirements and authorization procedures with the designated STI-PA before beginning certificate provisioning.
The distinction matters because being technically capable of generating a certificate does not automatically make a provider eligible to receive one. The authorization process establishes whether the participant qualifies under the framework's rules.
Service Provider Code tokens and certificate access
The STI-PA authorization process also supports the controlled issuance of Service Provider Code (SPC) tokens. These tokens are used in the certificate enrollment process to demonstrate that a provider has the appropriate authorization.
For example, a provider may have already deployed its SIP infrastructure and signing software. Before it can complete certificate enrollment with a CA, it still needs to satisfy the required authorization process and obtain the appropriate credentials.
This separation is an important security control: infrastructure readiness and participation eligibility are related but distinct requirements.
How the STI-PA Supports Trust and Security
Establishing a trusted certificate ecosystem
STIR/SHAKEN relies on a public key infrastructure in which certificates connect digital signatures to authorized participants. The STI-PA helps protect this trust model by applying the authorization policies that govern access to certificates.
Without these controls, a certificate-based authentication system would have a weaker basis for determining which participants should be trusted.
Consider a building with controlled entry. The STI-PA performs a role similar to the authority that establishes who qualifies for an access credential. The CA issues the credential, while the technical authentication and verification systems use the resulting trust infrastructure during call processing.
Each component has a separate responsibility, but the overall security model depends on their coordination.
What the STI-PA does not guarantee
STIR/SHAKEN authentication is not a universal guarantee that a call is legitimate, safe or wanted. It helps establish information about caller identity and the originating provider's attestation.
A successfully authenticated call could still be unwanted or fraudulent in other respects. Providers therefore need complementary controls such as call analytics, reputation assessment, fraud detection and appropriate call-handling policies.
The STI-PA supports the trust framework behind authentication; it does not independently inspect every call or determine whether every conversation is trustworthy.
STI-PA vs. STI-CA: Understanding the Difference
Two distinct roles in the trust framework
The STI-PA and STI-CA work together, but their responsibilities are not interchangeable.
The STI-PA manages authorization and policy enforcement. In the US STIR/SHAKEN ecosystem, iconectiv has served as the STI-PA since 2019. ATIS announced a new five-year agreement with iconectiv in November 2024, confirming its continued role.
The STI-CA issues certificates to eligible participants. It validates the required authorization and issues certificates according to the applicable framework and its approved practices.
A simple way to understand the distinction is that the STI-PA determines whether a participant is authorized under the ecosystem's rules, while the STI-CA handles certificate issuance within that framework.
How PeeringHub and TransNexus fit into the picture
Telecom providers evaluating STIR/SHAKEN services should distinguish between the organization responsible for policy administration and vendors that provide certificate or authentication technology.
PeeringHub: Provides STIR/SHAKEN Certificate Authority services, an ACME-based certificate issuance workflow and certificate repository hosting. Its documentation states that providers need approved STI-PA status before generating STIR/SHAKEN certificates through its service.
TransNexus: Offers STIR/SHAKEN solutions that include certificate services, call authentication and verification capabilities through its software platforms. Its product portfolio extends beyond the policy administration role.
Neither vendor should be confused with the STI-PA simply because it provides STIR/SHAKEN-related services. Providers should evaluate each vendor's specific role, current approvals, technical capabilities and service requirements before selecting a solution.
How Service Providers Can Work With the STI-PA
Follow a structured onboarding process
For a provider preparing to implement STIR/SHAKEN, the process generally begins with confirming eligibility and completing the required registration steps.
A practical sequence is:
Confirm eligibility: Review the applicable STI-GA policies and service provider requirements.
Prepare provider information: Ensure relevant organizational identifiers and registration details are accurate.
Register with the STI-PA: Complete the required application and authorization procedures.
Obtain the necessary authorization: Secure the appropriate SPC token or other required credentials.
Select an approved STI-CA: Choose a certificate service that meets the provider's technical and operational requirements.
Integrate and test: Configure certificate issuance and call authentication, then validate the deployment.
Exact requirements may vary with provider status and applicable policy. Consult the current STI-GA documentation and the designated STI-PA for authoritative instructions.
Prepare before requesting certificates
Providers can reduce avoidable delays by preparing their organizational information, checking their identifiers and understanding the integration requirements of their selected CA.
PeeringHub provides documentation for its certificate generation workflow and API. Its documentation also explains that STI-PA credentials are required for certificate generation through its service.
Preparing these requirements in advance helps teams distinguish registration issues from technical deployment problems and makes the onboarding process easier to manage.
Conclusion: The STI-PA Is a Foundation of STIR/SHAKEN Trust
The STI-PA plays a central role in the STIR/SHAKEN ecosystem by applying the policies that govern participation and access to authentication credentials. Working alongside the STI-GA and STI-CAs, it helps maintain a controlled trust framework for certificate-based caller authentication.
For telecom providers, understanding this distinction is essential. Successful deployment depends not only on signing and verifying calls but also on meeting authorization requirements and selecting the right certificate infrastructure.
PeeringHub helps eligible service providers manage STIR/SHAKEN certificate operations through Certificate Authority services, API-driven workflows and certificate repository hosting.
Explore PeeringHub's services and technical documentation to understand how its tools can support your implementation.
Visit: https://www.peeringhub.io/
Explore the documentation: https://doc.peeringhub.io/
Post a Comment