Upriser logo featuring red play button icon and dark text

STIR/SHAKEN Compliance: What U.S. Providers Must Do Now

Full STIR/SHAKEN compliance requires five concrete things: an SPC token from the STI Policy Administrator, an STI certificate issued against that token by an approved certificate authority, calls signed and attested with your own certificate, correct attestation-level decisions on every SIP call, and an accurate Robocall Mitigation Database filing that reflects reality, not aspiration.

The August 19, 2025 Federal Register order raised the bar considerably. Providers that lean on a third party for signing can no longer just point to that vendor’s work. You now need your own SPC token and certificate, plus a memorialized agreement proving you still control attestation decisions.

Checklist for compliance:

  • Confirm you hold a valid SPC token and active STI certificate
  • Verify your RMD entry matches your actual signing and attestation practices
  • Pull any third-party signing agreement and check it names who controls attestation
  • Test verification on a sample of inbound and outbound SIP calls

Key Takeaways

STIR/SHAKEN compliance depends on holding your own SPC token and certificate, controlling attestation decisions even when signing is outsourced, and keeping RMD filings and third-party agreements audit-ready at all times.

Point Details
Own your credentials Obtain your SPC token and STI certificate directly; don’t rely solely on a vendor’s certificate.
Control attestation Retain and document final say over attestation-level decisions, even in third-party signing arrangements.
File accurately Keep RMD entries current with real contact information, call-chain role, and implementation status.
Retain third-party records Memorialize signing agreements in writing and keep them accessible for the required retention period.
Centralize communication logs Platforms like Upriser help consolidate contact records and audit trails that support traceback and compliance documentation.

Table of Contents

What the FCC Requires for STIR/SHAKEN Compliance

The rule governing all of this, 47 CFR §64.6301, is shorter than most compliance officers expect, but it’s dense. It requires voice service providers to obtain an SPC token, use that token to acquire an STI certificate, and then authenticate and verify caller identity on SIP calls they originate, transmit, or receive. The rule also sets specific conditions for when a provider may rely on a third party to perform signing, which is where most enforcement risk now concentrates.

The FCC’s Robocall Mitigation Database sorts every registered provider into one of three implementation categories: Complete, Partial, or No STIR/SHAKEN implementation. Each filing needs to include:

  • Current company contact information for enforcement and traceback purposes
  • A description of the provider’s role in the call chain (originating, intermediate, terminating)
  • Disclosure of any prior FCC enforcement actions
  • A robocall mitigation plan detailing non-IP network segments and remediation steps

The 2025 order tightened this considerably. Providers relying on third-party signing arrangements must now demonstrate, as part of their RMD certification, that they hold their own SPC token and certificate and that a written agreement memorializes the third party’s role. This closes a loophole where a provider could claim “Complete” implementation while never actually controlling the cryptographic signing process.

By the numbers: the FCC frames STIR/SHAKEN as the mechanism that “erodes” illegal caller ID spoofing at scale, which is the entire policy rationale behind tying RMD eligibility to concrete proof of SPC token and certificate ownership rather than a vendor’s word.

Getting this filing wrong isn’t a paperwork slip. An inaccurate RMD entry can trigger downgraded attestation from upstream providers, which means your calls get labeled or blocked before they reach the called party.

How to Implement STIR/SHAKEN: SPC Token to RMD Filing

Most providers stall somewhere between “we know we need this” and “we have working attestation.” Here’s the sequence that actually gets you compliant, in order.

  1. Register with the STI-PA and request your SPC token. This is your service provider code, the credential that proves your regulatory identity to the entire SHAKEN PKI system. Without it, nothing downstream works.
  2. Select an approved STI-CA and order your certificate. Not every certificate authority is created equal. Check the STI-PA’s published trusted CA list before committing, and evaluate vendors on renewal automation, support for automated certificate management (ACME-style workflows), and how quickly they issue replacement certificates during an incident.
  3. Deploy signing at the origination edge. Most providers place signing logic on their session border controllers, at the point where calls first enter the IP network. This keeps attestation decisions close to the source, where you actually have the information needed to judge the caller’s legitimacy.
  4. Build and enforce attestation logic. Full attestation (A) means you know the caller and their right to use the number. Partial (B) means you know the caller but not the number relationship. Gateway © means you’re just passing the call along. Get this wrong systematically and downstream carriers will start discounting your calls regardless of what the signature says.
  5. File or update your RMD entry with accurate contact information, your role in the call chain, and an honest implementation status.

Pro Tip: Assign attestation-level decisions to a specific role, not “the network team” generically. When an auditor asks who decided a batch of calls deserved Full attestation, you need a name and a documented policy, not a shrug.

A simple roles matrix helps here: engineering owns the signing infrastructure and certificate deployment, compliance owns attestation policy and RMD accuracy, and a designated liaison owns traceback response. Split these badly, or leave them undocumented, and you end up with the exact gap the 2025 rule was written to close.

When Is Third-Party Signing Allowed Under STIR/SHAKEN Rules?

Third-party signing is permitted, but the FCC’s rules draw the line in one specific place: no matter who performs the cryptographic signing, the calls must be signed with your certificate, and you must be the one making attestation decisions. Outsourcing the mechanics does not outsource the legal responsibility.

Hands inserting cryptographic security token

This is the single most common compliance gap the 2025 Federal Register order targets. A provider hands signing to a vendor, assumes the vendor’s certificate covers them, and never memorializes who actually decides attestation levels. That arrangement no longer passes muster.

Your contract with any third-party authenticator should spell out, in writing:

  • Exactly which tasks the third party performs (signing mechanics only, versus signing plus attestation recommendations)
  • Explicit language confirming the provider retains final control over attestation-level decisions
  • Which certificate gets used to sign calls, and confirmation it’s issued to you, not the vendor
  • Data retention terms consistent with the rule’s two-year recordkeeping requirement

Pro Tip: Keep a signed copy of the third-party agreement somewhere your compliance team can retrieve it in minutes, not days. Enforcement inquiries move fast, and “we’ll have to find that” is not an answer that builds confidence with an investigator.

If you ever face an audit or enforcement inquiry, the evidence package that actually protects you includes the signed authenticator agreement, logs tying specific calls to the certificate used to sign them, your written attestation policy, and a snapshot of your RMD filing from the period in question. Providers that can produce all four documents quickly tend to resolve inquiries fast; providers that can’t tend to spend months explaining gaps that better recordkeeping would have closed on day one.

Technical Pitfalls That Break STIR/SHAKEN Verification

PASSporT, the token format defined in RFC 8224, carries the claims that let a receiving network verify who signed a call and when. Missing or malformed claims are the single most common reason calls arrive unverifiable, and an unverifiable call gets treated with suspicion by downstream carriers regardless of your intent.

A few implementation issues show up repeatedly across provider networks. SIP platform documentation flags certificate validity window mismatches, where a call gets signed just outside the timeframe a receiving network considers valid, as a frequent cause of failed verification. Unsupported PASSporT extensions between different vendors’ implementations cause similar failures. And in mixed IP and non-IP environments, calls that cross from a traditional TDM network onto IP infrastructure midstream often lose their signature entirely unless the gateway is specifically built to reassert it.

Pitfall Typical cause Mitigation
Unverifiable signature Certificate expired or not yet valid at call time Automate renewal well ahead of expiration; monitor validity windows
Dropped attestation on handoff Non-IP to IP transition mid-call Route through a gateway that reasserts PASSporT claims, or flag partial attestation
Rejected by receiving network Unsupported extension or malformed claim Test against multiple carrier verification stacks before full rollout
Reliance on untrusted CA Certificate purchased outside the STI-PA trusted list Check the STI-PA trusted CA list before every renewal cycle

For mixed-network operators, routing calls through an IP gateway capable of asserting PASSporT claims at the handoff point, or explicitly documenting a partial attestation for non-IP-originating segments, keeps calls from disappearing into unverifiable status once they cross network boundaries.

How Do You Test and Maintain STIR/SHAKEN Compliance?

Compliance isn’t a certificate you install once. It’s an ongoing operational discipline that needs regular testing and a fast response capability when something breaks.

  1. Run self-tests against your own signing chain monthly at minimum, confirming certificates validate and PASSporT claims parse correctly on both origination and termination.
  2. Validate interoperability with major receiving carriers. A signature that verifies internally can still fail against a specific carrier’s verification stack due to extension mismatches.
  3. Monitor attestation-level distribution over time. A sudden shift toward more Gateway or Partial attestations, with no corresponding network change, usually signals a misconfiguration worth investigating immediately.
  4. Maintain a rapid-response traceback team. Industry traceback requests typically carry tight turnaround expectations, and providers unprepared to respond quickly risk both reputational damage and regulatory scrutiny.
  5. Update your RMD entry whenever your network architecture, signing vendor, or third-party agreements change materially.

Treat traceback cooperation as a standing obligation, not a one-off event. The providers that handle these requests smoothly are the ones who’ve already designated who picks up that call at 2 a.m.

Where to Find Authoritative STIR/SHAKEN Standards and Guidance

When you need to defend a compliance decision, cite primary sources, not secondhand summaries. The STI-GA policy binder published through ATIS defines the PKI trust model, SPC token validation rules, and certificate policy controls every STI-CA must follow. It’s the operational playbook, not just a governance document.

The FCC’s own call authentication pages cover the regulatory “what” and link directly to the RMD filing portal. The eCFR text of §64.6301 is the legally binding “how,” spelling out exact obligations. For the technical protocol itself, RFC 8224 and its companion RFCs 8225 and 8226 define PASSporT and the cryptographic token structure your engineers actually implement.

Bookmark all four categories. An auditor asking “why did you make this attestation decision” wants a citation, not an explanation from memory.

Where to Find Authoritative STIR/SHAKEN Standards and Guidance — overview diagram

Treating STIR/SHAKEN as Ongoing Risk Management, Not a One-Time Project

The providers that struggle with STIR/SHAKEN treat it as a project with an end date. It isn’t. Attestation ownership needs a name attached permanently, certificate renewals and CRL checks need automation so nobody’s relying on a calendar reminder, and third-party agreements need to live somewhere your compliance team can pull them in minutes.

Communications platforms that already centralize contact records and audit trails, Upriser among them, can help surface irregular calling patterns worth investigating before a regulator does it for you. The practical next step: name your attestation owner this week, then put certificate expiration on a monitored calendar, not a hope.

— Brent

How Upriser Supports Compliance and Operations Teams

Upriser gives operations teams something STIR/SHAKEN compliance quietly depends on: a single, searchable record of every customer conversation across voice, video, SMS, and email. That matters when a traceback request lands and you need to reconstruct exactly who contacted whom, and when.

Upriser

Compliance officers spend a surprising amount of time reconstructing communication history by hand, pulling logs from three different systems that don’t talk to each other. Upriser’s unified audit trail keeps that history in one place, with automated logging that doesn’t depend on someone remembering to export a spreadsheet. For providers managing property services, insurance operations, or any business fielding high call volume, that consolidated record supports both customer service and the documentation an enforcement inquiry might eventually require.

Upriser doesn’t issue certificates and isn’t a substitute for your STI-CA relationship. It’s the operational layer that keeps your customer-facing communications organized while your engineering and compliance teams handle the regulatory heavy lifting. If your team wants to see how integrated logging fits into a property services workflow, that’s the natural place to start.

Sources

Blog

The Latest Updates

Copyright © 2026 UPRISER – All Rights Reserved.

Access the Hospitality Technology Case Study

Unlock the full case study to see how VEE voice and KAI video helped transform automated guest interactions into a more authentic, trust driven experience. Fill in the form below and the PDF will land in your inbox shortly.