What the Robocall Mitigation Program Actually Is
The Robocall Mitigation Program is the FCC’s name for the full compliance framework that sits on top of STIR/SHAKEN. The program is codified in 47 CFR § 64.6305, and it gives providers two ways to satisfy their core obligation.
The first path is full STIR/SHAKEN implementation, which means signing every originated call with the provider’s own certificate at the appropriate attestation level, verifying inbound calls on the terminating side, and certifying that implementation in the RMD. Providers who have implemented STIR/SHAKEN across their IP-based network still need an RMD filing; the implementation itself is a certification answer, not a substitute for the filing.
The second path is a documented robocall mitigation plan, which is a written description of the reasonable steps the provider takes to prevent illegal robocalls from originating, transiting, or terminating on their network. Providers who cannot fully implement STIR/SHAKEN (for example, providers with non-IP segments in their network) rely on this path. Many providers use a combination of both paths, certifying partial STIR/SHAKEN implementation alongside a mitigation plan that covers the parts of their network where signing is not feasible.
Either path requires the same operational commitments: 24-hour response to traceback requests, cooperation with FCC and law-enforcement investigations, and the affirmative customer-onboarding controls described below. A provider who files a mitigation plan and then ignores tracebacks is non-compliant regardless of how well the plan is written.
Who Must Comply
The set of providers subject to the Robocall Mitigation Program has expanded steadily since the original 2021 rules. The categories now in scope are:
Voice service providers include any entity that originates calls on behalf of end-user subscribers. This is the broadest category and the one with the strongest obligations. CLECs, ILECs, interconnected VoIP providers, hosted UC platforms, and contact-center providers all fall here.
Gateway providers cover intermediate carriers that bring foreign-originated calls onto the U.S. network. The FCC treats gateway providers as the U.S. entry point for traffic the rest of the U.S. industry cannot trace, which is why gateway obligations include mandatory authentication of unsigned inbound calls.
Non-gateway intermediate providers handle transit traffic within the U.S. call path. Since the FCC’s Eighth Report and Order (effective September 18, 2025), the first non-gateway intermediate provider in the path of an unauthenticated SIP call from an originating provider must authenticate that call. All non-gateway intermediate providers must also file in the RMD.
Mobile Virtual Network Operators (MVNOs) were clarified as in-scope in 2025. The FCC’s Wireline Competition Bureau confirmed that MVNOs must file or recertify in the RMD by the March 1, 2026 deadline, regardless of whether their underlying mobile network operator already has a filing on file.
If a provider is not in the RMD, downstream U.S. providers are prohibited from accepting their traffic. The practical effect is that an unlisted provider is disconnected from the U.S. phone network. There is no gentler enforcement mechanism than removal from the database.
What a Compliant Robocall Mitigation Plan Must Contain
The plan a provider files in the RMD is not free-form. The FCC has been explicit about the four elements every plan must describe, and recent enforcement actions have removed providers whose filings were too thin to support the certifications they made. A compliant plan addresses four areas.
The reasonable steps to avoid originating, carrying, or processing illegal robocall traffic form the centerpiece of the plan. The specifics depend on the provider’s role in the call path. Originating providers describe the controls applied at customer onboarding and on outbound traffic. Intermediate providers describe the controls applied to traffic transiting their network. Terminating providers describe the controls applied to inbound calls before delivery to the end user. The steps must be specific to the provider’s operations, not generic boilerplate.
The affirmative, effective measures preventing new and renewing customers from originating illegal robocalls apply specifically to voice service providers. This is the Know Your Customer requirement made explicit. The plan must describe how the provider verifies the identity of new customers, what contractual obligations the customer assumes regarding illegal robocalls, what number authorization records are maintained, and how customers are reviewed at renewal. The FCC has rejected filings that describe customer onboarding only as “standard credit checks” without explaining the robocall-specific verification.
The call analytics systems used to identify or block illegal robocall traffic must be named and described, including any third-party analytics vendors. A plan that simply states “we use call analytics” without identifying the system and what it analyzes is not compliant. Providers using third-party platforms like TransNexus ClearIP, SecureLogix, or YouMail-style scoring engines should name them; providers running in-house analytics should describe what signals are scored.
The procedures for knowing the upstream providers handing off traffic apply to every intermediate and terminating provider. The plan must describe how the provider verifies the identity of upstream peers, what contractual or operational records confirm peer status, and how anomalous or unverified peers are handled. This is the “Know Your Upstream Provider” obligation, and it is the most common deficiency cited in 2025 RMD removal orders.
On top of the four documented elements, the plan must include a written commitment to respond to all traceback requests within 24 hours. The commitment is not optional. In September 2025, the FCC issued a group order against 12 providers who had certified the 24-hour commitment in their RMD filings but failed to honor it in practice; the same order set the precedent that a missed traceback is a documented violation of the certification.
The Annual Filing Cycle
The RMD is not a one-time submission. Every provider with a current filing must recertify each year, and several maintenance obligations run continuously alongside the annual cycle.
The recertification window opens February 1 and closes March 1. The most recent window closed March 1, 2026. Recertification requires the provider to verify that every certification in the existing filing remains accurate and that any changes since the prior filing have been reflected. Filings that are not recertified by the March 1 deadline are subject to removal from the RMD.
Material changes must be filed within 10 business days. The 10-business-day update rule applies to both the RMD filing itself and the CORES registration tied to the filer’s FCC Registration Number. A change in the provider’s name, contact information, ownership, STIR/SHAKEN implementation status, or any other material certification element triggers the update obligation. The clock starts on the date the change occurs, not on the date the provider notices it.
The penalty schedule was raised effective February 5, 2026. The base forfeiture for submitting false or inaccurate information to the RMD is now $10,000 per violation. The base forfeiture for failing to update the RMD or CORES within 10 business days is $1,000 per violation. These are base amounts; enforcement actions can scale them up based on the conduct.
The combination of annual recertification, 10-day updates, and per-violation forfeitures means a provider who files once and forgets about the database is exposed on multiple fronts. The administrative cost of staying current is low. The cost of falling behind has climbed to a level where it warrants a calendar reminder and a named owner inside the operations team.
Enforcement Reality in 2025–2026
For most of the program’s history, RMD enforcement was a quiet administrative function. That changed in 2025. The Enforcement Bureau executed the largest set of RMD removals since the program began, and the practical effect was immediate.
August 6, 2025: 185 companies ordered blocked. The FCC’s Enforcement Bureau ordered all U.S. voice service providers to block every call from 185 named companies that had been removed from the RMD or had transmitted suspected illegal robocall traffic. The order took effect immediately, and the listed entities lost the ability to terminate any call into the U.S. phone network.
August 25, 2025: over 1,200 providers removed. The Enforcement Bureau removed more than 1,200 voice service providers’ certifications from the RMD in a single action. Removal carries the same downstream consequence as the blocking order: no U.S. provider may carry traffic from the removed entities. Re-entry into the database requires the consent of both the Enforcement Bureau and the Wireline Competition Bureau, which makes removal effectively permanent for the providers who triggered it through repeat traceback failures or false filings.
September 2025: 12-provider group order on traceback failure. The Enforcement Bureau issued a single order against 12 providers who had certified the 24-hour traceback commitment but failed to respond to specific traceback requests. The group order established that certifications are enforceable as standalone violations: a provider does not have to be caught originating illegal calls to face an enforcement action; failing to honor the procedural commitments in the RMD filing is itself sufficient.
December 2025: first national-security removal. The FCC cited national security as the basis for removing three Chinese telecommunications providers from the RMD. The order extended the program into territory it had not previously occupied and signaled that the database is now a tool of policy enforcement beyond the traditional fraud-prevention scope.
Two patterns emerge from the 2025 enforcement record. The first is that removal from the RMD has become the default sanction rather than a last resort. The second is that the certifications providers make in the filing are independently enforceable; the FCC will act on a missed traceback or a stale filing without requiring proof of illegal originating traffic. Compliance is now a procedural discipline as much as a technical one.
How an SBC Enforces the Operational Obligations
The mitigation plan filed in the RMD is a paper document. The operational obligations it describes (analytics integration, upstream peer authentication, traceback evidence retention, network-based blocking) all run on the voice infrastructure that handles real calls. For most providers, the Session Border Controller is where those obligations are enforced, because the SBC is the device that sees every signaling message and controls every call leg.
STIR/SHAKEN signing and verification on the SBC handles the call-authentication portion of the program. The SBC implementation walkthrough covers the signing and verification flow; the A-Level Attestation article covers the KYC and number-authorization requirements that make A-level signing defensible. The FCC’s own-certificate rule requires that the certificate used in the signing request belongs to the provider, even when a third-party signing service performs the technical act of signing.
Analytics integration on the SBC is what lets the mitigation plan’s “call analytics systems” certification be more than a piece of paper. ProSBC integrates with TransNexus ClearIP, SecureLogix, and YouMail through API modules in the Ruby routing engine. The integration pattern is a per-call HTTP or SIP query to the analytics service that returns a risk score or blocking decision, which the SBC then acts on. Providers who want to upgrade from “we use analytics” to “we use analytics integrated at the signaling layer” can do so without replacing their core infrastructure — the REST API call routing article covers the integration pattern.
Do-Not-Originate and dynamic blocking live in the SBC’s blacklist and access-control layer. ProSBC’s BlackWhiteListing module supports both global and per-NAP allow/block lists, and the Access Control List configuration article covers how to structure ACLs for compliance use cases. Percentage-based greylisting lets a provider apply a graduated response when a source begins to look anomalous but has not yet hit a hard block threshold. The DNO obligation that took effect December 15, 2025 sits on top of these controls; the SBC is where the list is enforced.
Upstream peer authentication (the “Know Your Upstream Provider” obligation) is enforced through NAP-based authentication and IP whitelisting on the SBC. Every accepted peer has a named NAP entry, an authentication mode (IP allowlist, SIP digest, mTLS), and a documented contractual relationship. Unknown sources are rejected at the SBC edge, which both satisfies the certification and reduces the attack surface for the SIP-layer threats described in the SIP DoS prevention guide.
Traceback evidence is the SBC’s least-glamorous compliance role and the one most likely to be tested. When the ITG sends a traceback request, the provider has 24 hours to identify the upstream provider that handed off the call and the relevant CDR. The SBC’s CDR and SIP signaling logs are the authoritative record. Operators who treat traceback response as a forensic exercise on archived logs (rather than a real-time query against a live log store) struggle to hit the 24-hour deadline; the providers in the September 2025 group order are the demonstration of what happens next. Retention windows and queryability of CDRs are practical compliance choices, not just storage choices.
Programmable mitigation actions let the SBC do more than block. A real-world example surfaced in a recent customer call: a hosted-voice provider currently uses an analytics service that returns a 302 Moved Temporarily on flagged calls, redirecting the caller to a challenge prompt before the call is allowed through. The SBC’s routing engine can interpret the 302 redirect and chain to an IVR challenge, a CAPTCHA flow, or a soft warning rather than dropping the call outright. The 302-based pattern is exactly how ProSBC integrates with TransNexus ClearIP today (the integration uses SIP 302 responses to deliver signing results and policy decisions), which means the same mechanism is available for analytics-driven challenge flows. Programmable response is what separates a static blacklist from a mitigation strategy.
Compliance Checklist
Use the following sequence to confirm a provider’s RMP standing. Each item maps to a specific certification or enforcement risk surfaced in the 2025 actions.
1. Confirm in-scope status. Verify which provider category applies (voice service provider, gateway, non-gateway intermediate, MVNO). All four are obligated to file in the RMD.
2. Confirm the RMD filing is current. Check the public RMD listing. A missing or removed entry means downstream providers are not permitted to accept traffic, regardless of any other compliance work.
3. Confirm annual recertification is complete. Recertification runs February 1 through March 1 each year. A filing that was not recertified in the most recent window is delinquent.
4. Confirm the mitigation plan covers the four required elements. Reasonable steps, customer onboarding controls (if applicable), analytics description, and upstream-provider procedures. Generic plans have been removed in 2025 enforcement actions.
5. Confirm the 24-hour traceback commitment is operationally honored. The commitment in the filing must match the operational reality. Have a named owner for traceback response and a queryable CDR store.
6. Confirm CORES information is current within 10 business days. The CORES registration tied to the FRN must reflect any material change to the provider’s information within the 10-business-day window.
7. Confirm the SBC enforces a reasonable DNO list. The December 15, 2025 effective date for DNO blocking applies to all providers in the call path, not just terminating carriers.
8. Confirm STIR/SHAKEN signing uses the provider’s own certificate. The Eighth Report and Order own-certificate rule has been effective since September 18, 2025. Providers using third-party signing services must verify that the signing service is configured with the provider’s SPC-token-derived certificate.
9. Confirm contractual upstream-peer documentation. Every peer NAP on the SBC should map to a written agreement or onboarding record that supports the “Know Your Upstream Provider” certification.
10. Confirm AI-voice handling. The FCC’s February 2024 declaratory ruling extended the TCPA’s “artificial or prerecorded voice” restrictions to AI-generated voices. Customer contracts and onboarding controls should reflect the AI-voice prohibition where applicable.
Frequently Asked Questions
Is filing in the Robocall Mitigation Database the same as implementing STIR/SHAKEN?
No. STIR/SHAKEN is one of two paths a provider can certify in the RMD. The other path is a documented robocall mitigation plan that describes reasonable steps to prevent illegal robocalls. Every provider must file in the RMD regardless of which path they take, and most providers file a combination of both.
What happens if a provider is removed from the RMD?
All U.S. voice service providers, intermediate providers, and gateway providers are prohibited from accepting or carrying traffic from a removed entity. The practical effect is disconnection from the U.S. phone network. Re-entry requires the consent of both the FCC Enforcement Bureau and the Wireline Competition Bureau.
When is the annual RMD recertification deadline?
The recertification window opens February 1 and closes March 1 each year. The most recent window closed March 1, 2026. Filings that are not recertified by the deadline are subject to removal from the database.
Do MVNOs have to file in the RMD?
Yes. The FCC clarified in 2025 that Mobile Virtual Network Operators must file or recertify in the RMD by the March 1, 2026 deadline, even if their underlying mobile network operator already has a filing on file. The MVNO’s filing must reflect its own customer base and onboarding practices.
What does the 24-hour traceback commitment require in practice?
When the Industry Traceback Group sends a traceback request, the provider must investigate the source and respond within 24 hours, identifying the upstream provider that handed off the call. The ITG recommends initiating the investigation within four business hours of receipt. Repeated failure to honor the commitment is itself an enforceable violation of the RMD certification.
What are the penalties for a false or stale RMD filing?
The base forfeiture for submitting false or inaccurate information to the RMD is $10,000 per violation. The base forfeiture for failing to update the RMD or the associated CORES registration within 10 business days of a material change is $1,000 per violation. Both amounts took effect February 5, 2026.
Does the program apply to intermediate carriers that only handle transit traffic?
Yes. Non-gateway intermediate providers must file in the RMD, and the first such provider in the path of an unauthenticated SIP call from an originating provider must authenticate that call under the rules adopted in the Eighth Report and Order (effective September 18, 2025).
Can a third party manage the RMD filing on a provider’s behalf?
A third party can prepare the filing, but the certifications inside it are the provider’s own statements and the provider remains legally responsible. The FCC will not accept “our vendor told us this was accurate” as a defense to a forfeiture action. Internal review of the filing before submission is the practical safeguard.
How does the FCC’s AI-voice ruling interact with the Robocall Mitigation Program?
The February 2024 declaratory ruling treats AI-generated voices as “artificial or prerecorded voice” under the TCPA, which means calls using AI voice cloning require the prior express consent of the called party. The mitigation program’s customer-onboarding controls and analytics descriptions should reflect AI-voice handling, especially for providers serving outbound dialing platforms.
How does an SBC support the operational side of the program?
The SBC enforces what the mitigation plan describes on paper: STIR/SHAKEN signing and verification, analytics integration through API modules, dynamic and static blacklists for DNO enforcement, NAP-based authentication of upstream peers, and CDR retention for traceback evidence. Providers running a programmable SBC can also implement challenge-response flows (such as 302-redirect-to-IVR) for borderline calls rather than dropping them outright.
Turn the Mitigation Plan Into Operational Reality
The Robocall Mitigation Program rewards providers whose documented controls match what their network actually does. ProSBC turns the controls in the plan (analytics integration, peer authentication, DNO enforcement, traceback evidence, STIR/SHAKEN signing with the provider’s own certificate) into a single configurable surface on a session border controller that already sits at the network edge.
For providers who would rather have the operational side managed end-to-end, the ProSBC Managed Service handles STIR/SHAKEN setup, certificate lifecycle, analytics integration, and ongoing compliance monitoring as a single subscription.
Prefer to evaluate on your own first? Start your 30-day free trial.