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:
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. |
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:
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.
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.
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.
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.

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:
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.
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.
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.
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.
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.

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
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.

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.
