STIR/SHAKEN Compliance for U.S. Providers in 2026

STIR/SHAKEN compliance means three things right now: you sign outbound calls with a valid certificate, verify inbound signatures, and keep an accurate Robocall Mitigation Database filing on record. Miss any one of those and you risk losing connectivity to major carriers within weeks, not months. If your organization has an implementation obligation, the FCC also requires you to sign with your own certificate and retain control over attestation decisions, even when a vendor handles the technical signing, as explained by Netera Communications.

Here’s your immediate checklist for the next 30 to 90 days:

• Confirm your Robocall Mitigation Database (RMD) entry is current and matches your actual network configuration.
• Determine whether your business has a STIR/SHAKEN implementation obligation (most IP-based voice providers do).
• Verify who owns your STI certificate and whether your Service Provider Code (SPC) token is registered correctly.
• Map your traffic paths, including any legacy TDM or gateway segments that need C-level attestation.
• Name a designated robocall mitigation contact and document your traceback response procedure.

1. Pull your current RMD filing and compare it line by line against your actual operations.
2. Calendar your annual recertification window now, not in February.
3. Audit any third-party signing arrangement against the FCC’s own-certificate requirement.

Pro Tip: The single most common compliance failure isn’t cryptographic. It’s administrative. Stale RMD entries, wrong contact information, or missed recertification windows account for the bulk of enforcement action. Set a recurring calendar reminder for January 15 each year, a full six weeks before the March 1 deadline, and assign one named owner for the RMD filing who is not also juggling network operations during the same window.

Key Takeaways

STIR/SHAKEN compliance requires signed calls, verified inbound traffic, accurate attestation, and a current RMD filing, with certificate ownership retained by the provider even when a vendor performs the technical signing.

Point	Details
Maintain RMD accuracy	Recertify between February 1 and March 1 annually, and audit your entry quarterly against actual network changes.
Own your attestation decisions	Retain certificate ownership and attestation control in writing, even when using a third-party signing vendor.
Watch attestation drift	Monitor your A versus B/C ratio and investigate unexplained shifts before they draw regulatory scrutiny.
Staff traceback response	Name a reachable contact and commit to a documented traceback turnaround time in your mitigation plan.
Build compliance into your platform	A connected system like RevRing pairs dialing infrastructure with signing, monitoring, and mitigation reporting support.

Table of Contents

• What Does Stir Shaken Compliance Actually Require?
• What Are the Stir Shaken Attestation Levels?
• What Are the FCC’s Filing and Timeline Requirements?
• How Do Signing and Verification Actually Work?
• How Do CSPs Become Fully Compliant, Step by Step?
• How Should You Govern Attestation Decisions Internally?
• How Do You Handle Legacy and Gateway Traffic?
• What Triggers Enforcement, and What Are the Consequences?
• How Do You Get an STI Certificate?
• How Do You Test and Monitor Compliance for Traceback Readiness?
• How Does a Compliance-Focused Platform Handle This for You?
• Where Should Compliance Teams Focus in the Next 90 Days?
• How Does Revring Support Stir Shaken Compliance?
• Frequently Asked Questions
• Sources

What Does Stir Shaken Compliance Actually Require?

STIR/SHAKEN is the U.S. federally mandated framework for authenticating caller ID on IP-based voice networks, enforced by the Federal Communications Commission. STIR (Secure Telephone Identity Revisited) and SHAKEN (Signature-based Handling of Asserted information using toKENs) work together to attach a cryptographically signed token, called a PASSporT, to every call. That token tells the terminating carrier who originated the call and how confident the originating provider is that the caller has a legitimate right to use that number. Full compliance requires signing calls, verifying incoming signatures, running a documented robocall mitigation program, and maintaining a valid entry in the Robocall Mitigation Database.

The framework rests on a handful of moving parts that every compliance officer needs to recognize by name:

• PASSporT — the signed token (defined in RFC 8225) that carries the calling number, called number, and attestation claim.
• Attestation level — the A/B/C confidence rating the originating provider assigns to the call.
• STI certificate — the digital credential a provider uses to sign calls, issued through an authorized certificate authority.
• STI-CA — the certificate authority that issues STI certificates once a provider has an SPC token.
• origid — the origination identifier embedded in the PASSporT that ties a call back to a specific originating source, useful for traceback.

Authentication and verification are not the same function, and mixing them up is where a lot of engineering teams stumble. Authentication happens on the originating side: your switch signs the call and attaches an attestation claim before it ever leaves your network. Verification happens on the terminating side: the receiving carrier checks the signature against a trusted certificate chain and decides how to treat the call. You control one side. You do not control the other.

What Are the Stir Shaken Attestation Levels?

Attestation is where technical compliance turns into a business outcome. The originating provider assigns one of three levels to every signed call, and that letter grade follows the call all the way to the person’s phone screen.

Attestation Level	Criteria	Typical Use Case
A (Full)	Provider has a direct relationship with the caller and has verified the caller is authorized to use the calling number	Standard business line, verified enterprise customer
B (Partial)	Provider has a direct relationship with the caller but cannot verify authorization of the specific number	Reseller traffic, some VoIP customers without number verification
C (Gateway)	Provider has no relationship with the calling party, typically an international gateway or transit carrier	Inbound international traffic, TDM interconnection points

Terminating carriers and analytics engines treat these levels very differently. A-attested calls are far less likely to get flagged as spam or blocked outright, and A-level attestation is directly linked to better branded-calling performance and higher answer rates. B and C attestations, by contrast, get scrutinized harder by call-blocking algorithms, and a steady stream of B-attested traffic from a number that should qualify for A can quietly erode a client’s answer rates over months without anyone noticing the root cause.

A few operational rules keep attestation honest:

• Only assign A when you have both a direct customer relationship and confirmed number authorization, not just one or the other.
• Reassign a customer to a lower attestation level the moment their number authorization lapses or their account status changes.
• Treat attestation upgrades as a formal decision with a documented trigger, not a default setting.

Pro Tip: Escalating a customer to A-level attestation without confirmed number ownership is called improper attestation, and it’s exactly the pattern STI-GA governance actions are designed to catch. Build a simple rule: no A attestation without a signed Letter of Authorization or equivalent number-ownership proof on file.

What Are the FCC’s Filing and Timeline Requirements?

The FCC ties network access to a short list of administrative filings, and this is where most providers actually fall out of compliance. It’s rarely the cryptography that trips people up. It’s the paperwork.

Three filings and identifiers are non-negotiable:

• FCC Form 499-A — establishes your 499 Filer ID, the baseline registration nearly every U.S. telecom entity needs.
• Operating Company Number (OCN) — your carrier identifier used across industry databases and interconnection agreements.
• Robocall Mitigation Database entry — your public declaration of STIR/SHAKEN implementation status and mitigation program, checked by downstream carriers before they’ll accept your traffic.

The recertification calendar is fixed and unforgiving. The RMD filing window opens February 1 each year, and recertification is due by March 1. Miss that window and your entry lapses, which means downstream carriers can legally start blocking your traffic the moment they notice.

1. Confirm your Form 499-A and OCN are current before touching your RMD entry.
2. File or recertify your RMD entry inside the February 1 to March 1 window every year.
3. Document a per-fiscal-quarter internal audit that checks RMD accuracy against actual network changes.

As of August 2025, the FCC had removed nearly 1,400 providers from the RMD for non-compliance, a wave of enforcement that cut those providers off from downstream carriage almost overnight. That number should sober up anyone who treats RMD recertification as a background task. The providers swept up weren’t necessarily running bad cryptography. Many simply let a filing go stale.

How Do Signing and Verification Actually Work?

Engineers building or auditing a STIR/SHAKEN stack need to understand exactly where the signature lives and how it travels through the SIP path. The PASSporT token rides in the SIP Identity header, and it carries two claims that matter most operationally: attest, which holds the A/B/C level, and origid, a unique origination identifier that lets investigators trace a call back to its source even across multiple hops.

The signing chain has four links, and each one depends on the previous:

1. A provider registers with the Policy Administrator and receives an SPC (Service Provider Code) token confirming its identity.
2. The provider presents that SPC token to an authorized STI-CA, which issues a service provider certificate.
3. The provider’s switch or signing service uses that certificate to generate a PASSporT signature for each outbound call, per the ATIS-1000074 SHAKEN specification.
4. The terminating provider receives the signed INVITE, checks the certificate chain against the STI-GA repository, and validates the signature before deciding how to handle the call.

On the operational side, a few integration points deserve direct attention from your architecture team:

• Confirm your session border controller can pass the Identity header unmodified across all trunk groups.
• Check that your signing service populates origid consistently, since gaps here make traceback slower during an incident.
• Test verification failure handling separately from signing, since a misconfigured verification path can silently downgrade legitimate A-attested calls to unverified status.

Pro Tip: A surprisingly common debugging mistake is confusing the attestation claim inside the PASSporT with the From or P-Asserted-Identity header in the SIP message. They serve different purposes. The From header shows the calling number as presented to the callee; the attestation claim reflects the originating provider’s confidence in that number’s legitimacy. A call can have a perfectly formatted From header and still carry a B or C attestation if number authorization wasn’t verified.

How Do CSPs Become Fully Compliant, Step by Step?

Getting from zero to fully compliant follows a predictable sequence, and skipping steps almost always creates rework later.

1. Map your traffic: identify which calls originate on your network, which transit through you, and which arrive from gateway or TDM sources.
2. Determine whether you carry an implementation obligation under FCC rules (most facilities-based and many non-facilities-based voice providers do).
3. Obtain or confirm your 499 Filer ID and OCN if you don’t already have them.
4. Register with the Policy Administrator and request an SPC token.
5. Present that token to an authorized STI-CA and obtain your service provider certificate.
6. Integrate signing on outbound calls and verification on inbound calls across your entire IP footprint.
7. File your Robocall Mitigation Database entry, including a documented mitigation plan.
8. Set up ongoing monitoring, a traceback runbook, and an internal audit schedule tied to your recertification date.

The practical compliance path outlined by industry guidance consistently flags the administrative filings, not the cryptographic implementation, as the step where providers most often stall or make mistakes.

Your robocall mitigation plan needs specific fields, and the RMD expects them filled out with real operational detail rather than boilerplate:

• Named contact with a direct phone number and email, not a general support inbox.
• Description of your actual mitigation procedures, including call analytics tools or filtering in use.
• Traceback response commitment, stating your target turnaround time for industry traceback requests.

Pro Tip: If you’re using a third-party signing service, get contract language in writing that confirms you retain attestation decision authority and certificate ownership. The FCC’s own-certificate requirement puts accountability on you regardless of who technically performs the signing, so a vague vendor agreement is a liability you’re carrying, not one your vendor is carrying for you.

How Should You Govern Attestation Decisions Internally?

Attestation isn’t a one-time technical setting. It’s an ongoing decision that needs the same rigor as any other compliance control, because downstream verification only confirms cryptographic integrity, not whether your original attestation decision was accurate. That accountability sits entirely with you.

A defensible attestation policy needs several concrete pieces:

• A documented know-your-customer (KYC) process for verifying who your customers are before onboarding them.
• Number authorization checks, ideally tied to a signed Letter of Authorization or carrier-verified number ownership record.
• Logging and audit trails that show why each attestation decision was made and by whom.
• Written rules of engagement for reassigning attestation levels when customer status or number ownership changes.

Monitor a short set of operational metrics that connect directly to enforcement exposure:

1. Attestation drift: the rate at which a customer’s attestation level changes over time without a clear trigger.
2. The ratio of A versus B/C attestations across your customer base, watched for sudden unexplained shifts.
3. Verification failure rate on inbound traffic, which can signal upstream signing problems before a partner notices.

Recordkeeping matters more than most compliance teams initially expect. If the STI-GA revokes a token or the FCC opens an inquiry, you need to produce attestation decision logs quickly, showing the KYC basis for every A-attested account in question. Waiting until an inquiry lands to figure out where those logs live is the wrong time to discover you don’t have them.

How Do You Handle Legacy and Gateway Traffic?

Not every call on your network originates on IP infrastructure, and the rules account for that with C-level, or gateway, attestation. Gateway attestation is the correct signal when you have no direct relationship with the calling party, most commonly international inbound traffic entering your network through a gateway, or domestic TDM interconnection where the originating carrier hasn’t signed the call.

For providers still running mixed TDM and IP environments, three practical paths exist:

• Upgrade the TDM segment to IP where feasible, which eliminates the gateway attestation question entirely.
• Deploy a gateway-authentication solution that signs calls at the network edge as they transition from TDM to IP.
• Document active, good-faith efforts toward a non-IP solution, which the FCC’s rules explicitly recognize as an acceptable interim posture for segments that genuinely cannot yet support signing.

A concrete example: a provider receiving heavy inbound international traffic through a single gateway point should apply C attestation consistently at that gateway rather than attempting to pass through whatever attestation (or lack of one) arrived with the call. Consistency here limits both the compliance risk and the business impact, since terminating carriers expect gateway traffic to carry C attestation and won’t necessarily penalize it the way they penalize unexplained B attestation on domestic traffic that should qualify for A.

1. Inventory every non-IP interconnection point on your network.
2. Classify each one as either upgrade-eligible or gateway-authentication-eligible.
3. Document your remediation timeline for each segment as part of your RMD mitigation plan.

What Triggers Enforcement, and What Are the Consequences?

Two main actors drive enforcement in this space: the FCC Enforcement Bureau, which handles regulatory action including RMD removal and fines, and the STI-GA, which governs the certificate and attestation ecosystem itself, including token revocation.

The consequences run from inconvenient to existential for a small provider:

• Removal from the Robocall Mitigation Database, which downstream carriers treat as a signal to start blocking your traffic.
• Direct FCC fines for non-compliance with filing or signing obligations.
• STI-GA token revocation, which cuts off your ability to sign calls at all until resolved.

Three failure patterns account for the overwhelming majority of enforcement actions: defective or stale RMD filings, patterns of improper attestation (assigning A without proper verification), and failure to respond to industry traceback requests within expected timeframes.

The August 2025 enforcement wave that removed nearly 1,400 providers from the RMD wasn’t a crackdown on bad actors running fraudulent robocall operations. Most of those removals traced back to filing defects: stale contact information, mismatched network descriptions, or missed recertification. That distinction should change how compliance officers prioritize their time. The administrative side of STIR/SHAKEN carries as much enforcement risk as the technical side, arguably more, because it’s easier to overlook.

Avoiding a similar outcome comes down to discipline rather than technical sophistication: recertify on time, keep your named contact reachable, and respond to traceback requests inside your committed window every single time, not just when convenient.

How Do You Get an STI Certificate?

Getting your STI certificate starts with the SPC token process. You register with the Policy Administrator, receive your Service Provider Code token confirming your identity as a legitimate carrier, and then present that token to an authorized STI-CA to receive your actual signing certificate. In the U.S. market, providers typically work with certificate authorities such as iconectiv or TransUnion (formerly Neustar), both of which operate as authorized STI-CAs under the governance framework.

Before signing with any vendor, whether for certificate issuance or third-party signing services, ask these questions directly:

• Can they sign calls using your certificate specifically, preserving your attestation control, or do they sign under their own credential?
• What records do they maintain, and for how long, in case of a traceback request or FCC inquiry?
• What’s their service-level commitment for incident response and traceback turnaround?
• What contract language protects your right to control attestation decisions even though they handle the technical signing mechanics?

1. Register with the Policy Administrator for your SPC token.
2. Select an authorized STI-CA and submit your token for certificate issuance.
3. Confirm your signing infrastructure, whether in-house or vendor-managed, uses your certificate specifically.
4. Get contract terms in writing confirming attestation control stays with you, not your signing vendor.

That last point isn’t a formality. The FCC’s rule requiring providers with implementation obligations to sign with their own certificate took effect September 18, 2025, and it specifically constrains how much technical signing you can outsource without losing accountability. A vendor can perform the mechanics. You still own the decision.

How Do You Test and Monitor Compliance for Traceback Readiness?

A functioning STIR/SHAKEN implementation needs regular testing, not just a one-time integration checkmark. Build a test plan that covers the full range of real-world conditions:

1. End-to-end signing tests confirming outbound calls carry a correctly formatted PASSporT.
2. Verification checks on inbound traffic, confirming your system correctly validates certificate chains.
3. Invalid-signature scenarios, testing how your system handles a deliberately malformed or expired signature.
4. Gateway edge cases, confirming C attestation applies correctly at every non-IP interconnection point.

Instrument these metrics continuously rather than checking them quarterly:

• Signed call ratio: the percentage of your outbound calls carrying a valid signature.
• Attestation distribution: the breakdown of A, B, and C attestations across your traffic.
• Verification failure rate: how often inbound calls fail signature validation.
• Traceback response latency: how quickly you can produce origid-linked records when an industry traceback request arrives.

Pro Tip: Keep signed call logs and attestation decision records for at least as long as your longest realistic traceback window, and package them in a format you could hand to an FCC investigator without a scramble. Coordinate log retention policies with your upstream and downstream partners too, since chain-of-custody during an incident only holds together if everyone in the call path can produce matching records on the same timeline.

How Does a Compliance-Focused Platform Handle This for You?

A telephony platform built around regulated industries has to treat STIR/SHAKEN as infrastructure, not an afterthought bolted onto a dialer. That means drawing a clear line between what the platform handles and what stays with you as the customer of record.

Here’s how that division of responsibility typically works:

• Platform responsibility: technical signing integration, certificate lifecycle support, verification on inbound traffic, and monitoring dashboards that surface attestation drift or verification failures in real time.
• Customer responsibility: KYC decisions that justify attestation levels, ownership of the underlying customer relationship, and sign-off on the robocall mitigation plan filed to the RMD.
• Shared responsibility: audit trail maintenance, traceback response coordination, and periodic review of attestation accuracy.

1. Confirm the platform signs calls using infrastructure that preserves your certificate ownership.
2. Confirm reporting output maps directly to what RMD recertification and internal audits require, not a generic dashboard.
3. Confirm the platform’s mitigation plan support gives you a documented, named-contact process rather than a vague promise of “compliance features.”

Providers scaling fast, going from a dozen agents to well over a hundred, often discover their original telephony setup wasn’t built to keep attestation policy consistent across that growth. A platform that bakes compliance infrastructure into its core, alongside predictive dialing and CRM connectivity, removes a layer of manual tracking that otherwise falls on whoever happens to own compliance that quarter. That matters most for regulated sectors like healthcare, where TCPA and STIR/SHAKEN obligations stack on top of each other, and a workflow gap in one often surfaces problems in the other.

Pro Tip: When evaluating any platform partner for signing support, ask specifically whether contractual terms preserve your attestation decision authority and certificate ownership. A platform that can’t answer that clearly in writing is asking you to accept the FCC’s own-certificate accountability without giving you the contractual control that accountability requires.

Where Should Compliance Teams Focus in the Next 90 Days?

The technical side of STIR/SHAKEN gets most of the engineering attention, and the administrative side gets almost none, which is exactly backward given where enforcement actually lands. My honest read after working through this framework: providers treat certificate issuance and PASSporT signing as the hard part and RMD filing as a formality. The August 2025 removal of nearly 1,400 providers proves the opposite. The paperwork is the risk.

Here’s how I’d sequence the next 90 days if I were running compliance for a mid-sized CSP:

Days 1 to 30: Audit your RMD entry line by line against your actual network configuration. Confirm your named contact is reachable and your mitigation plan description matches what you’re actually doing operationally, not what you filed three years ago.

Days 31 to 60: Verify certificate ownership and SPC token control, especially if you use any third-party signing arrangement. Get contract language in writing confirming you retain attestation authority under the FCC’s own-certificate rule.

Days 61 to 90: Review your attestation policy for drift. Pull your A versus B/C ratio over the last two quarters and investigate any unexplained shift. Stand up monitoring for verification failures if you haven’t already.

Pro Tip: Set an automated calendar reminder for January 15 every year, a full six weeks ahead of the March 1 recertification deadline, and assign a named backup owner in case your primary compliance contact is unavailable during the filing window. SPC token renewal deadlines deserve the same treatment. Losing track of either one is an entirely avoidable way to lose network access.

How Does Revring Support Stir Shaken Compliance?

Compliance infrastructure only works if it’s actually built into your calling platform rather than layered on top as a separate system to babysit. Revring is the alternative to stitching together a signing vendor, a compliance spreadsheet, and a separate monitoring tool: it gives regulated sales and client-intake teams one connected system where signing, attestation reporting, and robocall mitigation documentation live alongside the predictive dialer they’re already using every day.

The platform’s compliance infrastructure, covering TCPA, DNC, and HIPAA BAA requirements alongside STIR/SHAKEN signing support, is built for teams in insurance, real estate, and healthcare who can’t afford a gap between their dialing infrastructure and their regulatory obligations. Automations reduce the manual entry errors that drive most RMD filing defects, and built-in monitoring surfaces attestation drift before it becomes a downstream carrier’s problem, or an FCC inquiry. Clients have used that connected infrastructure to scale from 12 agents to 180 without losing their compliance footing along the way, a growth curve that breaks most patchwork setups.

If your compliance stack is currently spread across three vendors and a shared drive of PDFs, start with a demo of RevRing’s platform to see how signing, monitoring, and mitigation reporting fit together, or check current pricing plans to map the cost against what you’re spending on fragmented tools today.

Frequently Asked Questions

Do all voice providers need to comply with STIR/SHAKEN? Most facilities-based voice service providers and many non-facilities-based providers carry an implementation obligation. Confirm your specific status against current FCC rules rather than assuming, since obligations vary by provider type and network architecture.

What happens if I miss the RMD recertification deadline? Your RMD entry can lapse, and downstream carriers are entitled to treat that as grounds to block your traffic. Recertify between February 1 and March 1 every year without exception.

Can I use a third-party vendor to sign my calls? Yes, but under the FCC’s own-certificate rule you must retain attestation decision control and sign using your own certificate, even when a vendor performs the technical signing work. Get that control specified in your vendor contract.

Why does attestation level matter for my business, not just compliance? A-level attestation is linked to meaningfully better branded-calling performance and answer rates. Consistent B or C attestation on traffic that should qualify for A can quietly cost you connections without an obvious cause.

What’s the difference between authentication and verification? Authentication happens on the originating side, where you sign the call and assign an attestation level. Verification happens on the terminating side, where the receiving carrier checks your signature and certificate chain. You control authentication; you don’t control how downstream carriers verify it.

Sources

Regulatory obligations and technical standards come from different bodies, and it helps to know which is which when you’re citing a rule internally or training your team.

Regulatory sources (FCC):

• Robocall Mitigation Database | Federal Communications Commission
• STI-GA guidance on improper authentication and attestation
• What Are the Attestation Levels for STIR SHAKEN | TransUnion

Standards and technical sources (ATIS, STI-GA, IETF):

Recommended

• Healthcare | RevRing Industries
• TCPA Compliance in 2026: What Every Insurance Agent Needs to Know Before They Dial | RevRing Blog
• Lead Generation | RevRing Industries