FedRAMP 20x: what changed

Check the date on whatever you read last

FedRAMP 20x was announced in March 2025 and ran as two consecutive pilots. Phase One handled low-impact offerings from April to September 2025, with the program receiving 26 complete packages between May 30 and August 18, 2025 and completing 13 reviews. Phase Two, the moderate pilot, ran from November 18, 2025 into March 2026, restricted to Phase One participants and prioritized offerings; the first cohort was authorized on March 6, 2026 and six more providers followed by April 27, 2026. That is the history. The present tense is different, and the program says so in one line on its own program page: the pilots are over.

What replaced them is not a lighter version of the old process. In late June 2026 the program published the Consolidated Rules for 2026, which folded scattered guidance, baselines and policy memos into a single versioned ruleset with a public changelog and a machine-readable source of truth on GitHub. The vocabulary changed with it. Certification pipelines opened in August 2026 on a published schedule. A hard date now exists for the end of new Rev5 packages. Anyone still planning against a 2025 description of the program is planning against a document the program itself has superseded.

Everything below is drawn from fedramp.gov, the Consolidated Rules for 2026 reference site, FedRAMP public notices, the United States Code, and GovRAMP's published program materials. Rule identifiers are quoted so a reader can look up the exact text rather than take a summary on faith.

Authorization became certification, and the word carries weight

The old vocabulary described a package that an agency reviewed and a sponsoring official signed. The new vocabulary describes a status a cloud service offering holds. FedRAMP now defines FedRAMP Certified as "the status of a cloud service offering that has received FedRAMP Certification and meets the legal requirement to be FedRAMP authorized." The phrase at the end is doing real work. It ties the program's own status word back to the statute rather than replacing it.

That statute is the FedRAMP Authorization Act, enacted as part of Public Law 117-263 and codified at 44 U.S.C. sections 3607 through 3616. The provision buyers care about is section 3613, which states that "the assessment of security controls and materials within the authorization package for a FedRAMP authorization shall be presumed adequate for use in an agency authorization to operate cloud computing products and services." The same section preserves an agency head's authority to determine that there is a demonstrable need for additional security requirements beyond FedRAMP's. Presumed adequate is not the same as automatically accepted, and it never was. An agency can still add requirements; it simply has to decide to.

The renaming is not cosmetic. It moves the center of gravity from a package a single sponsoring agency approves toward a status the program itself confers and maintains, which any agency can then rely on under the statutory presumption. That is why the program can talk about throughput at all.

Three impact levels became four certification classes

Low, Moderate and High described the sensitivity of the data. Classes A through D describe the assurance the provider supplies. FedRAMP's own definition is explicit about the direction of travel: a certification class is "the category of assurance that a cloud service offering supplies to federal government customers following FedRAMP Practices, increasing from minimal assurance at Class A to significant assurance at Class D."

Class C is where the substance sits today, and it is not small. The Class C reference carries 168 rules across 15 rulesets, all marked stable: certification, marketplace listing, minimum assessment scope, cryptographic module use, secure configuration guide, significant change notification, vulnerability detection and response, vulnerability evaluation and reporting, independent verification and validation, collaborative continuous monitoring, certification data sharing, incident evaluation and communication, security decision record, and addressing FedRAMP communication. A buyer who was told 20x means "less paperwork" should read that list before repeating it.

Every rule carries a stable identifier. The format is a triplet of three-letter keys — ruleset, subset, and a human-readable rule key — written as MAS-CSO-TPR or VDR-RPT-VDT. The full set ships as fedramp-consolidated-rules.json with a published JSON schema in the FedRAMP rules repository, and the program released a browser-based schema validator in July 2026. For anyone writing contract language or a vendor questionnaire, that means a requirement can now cite a specific rule key instead of paraphrasing a PDF.

The calendar is the actual news

Program philosophy is interesting. Dates are actionable. The Consolidated Rules for 2026 publish a timeline, and it is short enough to hold in your head.

Two of those dates change how a procurement should be written this year. July 28, 2026 ended FedRAMP Ready as a thing a vendor can newly claim, which matters because Ready appeared in a great many market-research memos and draft requirements as a soft qualifier. January 1, 2027 makes the Consolidated Rules mandatory for everyone, including providers already holding a Rev5 certification. A contract that runs past that date and references a Rev5 artifact by name should say what happens when the artifact stops existing in that form.

The temporary Rev5 pipelines that opened on August 10, 2026 exist for two specific situations, both of which are recognizable if you have watched a cloud vendor stall: lost sponsor, where an agency sponsor walked away mid-process, and ready conversion, where a provider had completed the old readiness step and needed somewhere to go. Providers using those pipelines still have to meet the minimum Rev5 requirements. It is a bridge, not an amnesty.

The annual assessment gave way to a reporting cadence

The single biggest operational change is the replacement of a staged yearly audit with a running one. The program states the goal directly: key security indicators "can demonstrate security posture in near real time, replacing static yearly manual assessments," and security "should be continuously enforced, monitored, and reported — not staged for a point-in-time audit."

Under the Collaborative Continuous Monitoring ruleset, a provider must supply an Ongoing Certification Report to all necessary parties every three months (CCM-OCR-AVL). The report contents are enumerated: changes to certification data, planned changes for the coming three months, accepted vulnerabilities, transformative changes, security recommendations, the agency user list, reportable incidents or an attestation that there were none, and lessons learned. A provider must also publish the target date for its next report (CCM-OCR-NRD), which turns the cadence into something a customer can hold a vendor to.

Class C providers additionally have to host a synchronous Quarterly Review open to all necessary parties (CCM-QTR-MTG), scheduled at least three business days after the report is released and within ten business days of it (CCM-QTR-SAR). Agencies receive the report, an asynchronous feedback channel, an invitation to the review, and recordings where they are provided. That is a meaningful shift in the buyer's position. Under the old model, an agency customer read a package. Under this one, an agency customer gets a standing quarterly meeting with the provider's security team and a written record it can cite.

Vulnerabilities are now rated by what they would do to an agency

The severity model moved away from a raw scanner score toward a judgment about federal customer consequence. Under the Vulnerability Evaluation and Reporting ruleset, a provider assigns a Potential Agency Impact N-rating (VER-EVA-EPA) on a five-step scale, and the language is about effect on agencies rather than about the vulnerability in isolation.

• N1 — exploitation "could be expected to have minimal customer effects on one or more agencies."
• N2 — "narrow customer effects on one or more agencies."
• N3 — "a disruptive customer effect on one agency."
• N4 — "a debilitating customer effect on one agency OR a disruptive customer effect on more than one federal agency."
• N5 — "a debilitating customer effect on more than one agency."

Two more axes sit alongside the rating. A provider evaluates whether a detected vulnerability is a likely exploitable vulnerability given the context of the offering (VER-EVA-ELX), and whether it is internet-reachable (VER-EVA-EIR). One rule deserves special attention from anyone who has argued with a vendor about theoretical exploitability: VER-EVA-AIA requires the provider to assume exploitation is automatable. The burden runs the other way from how many commercial risk registers are written.

Those three inputs produce a remediation clock. The Class C timeframes under VDR-TFR-PVR are counted in days from evaluation, and they tighten sharply for anything both likely exploitable and internet-reachable.

Detection cadence is specified separately and is tighter than most commercial programs run. Class C providers must verify and validate the status of machine-based information resources at least once every three days (VDR-TFR-MVX). Resources likely to drift get checked at least every 14 days (VDR-TFR-PDD); stable resources at least monthly (VDR-TFR-PCD). Known exploited vulnerabilities follow the due dates in the CISA Known Exploited Vulnerabilities Catalog (VDR-TFR-KEV), an alignment FedRAMP made explicit in Public Notice 14 responding to CISA Binding Operational Directive 26-04 in June 2026. Reporting runs monthly, and anything unresolved at 192 days is categorized as an accepted vulnerability (VER-TFR-MAV) rather than quietly aging out of view.

Change notification stopped being a negotiation

The old significant-change process was a common source of delay because the definition of significant was argued case by case. The Significant Change Notification ruleset replaces the argument with categories and day counts.

Routine recurring changes. Exempt. Providers "should not make formal Significant Change Notifications for routine recurring changes" (SCN-RTR-NNR).

Adaptive changes. Notify all necessary parties within 10 business days after the change is finished (SCN-ADP-NTF). No advance notice, no waiting.

Transformative changes. Four notifications: an initial one at least 30 business days before starting (SCN-TRF-NIP), a final one at least 10 business days before starting (SCN-TRF-NFP), one within 5 business days after finishing (SCN-TRF-NAF), and one within 5 business days after verification completes (SCN-TRF-NAV).

Advance approval is not the default. FedRAMP may require a provider to delay significant changes or submit them for approval in advance, but only as a condition of a formal Corrective Action Plan (SCN-FRP-CAP). Emergencies may proceed without advance notice provided they are documented afterward (SCN-CSO-EMG). If you are drafting a change-control clause for a cloud service, these numbers are the ones to mirror; writing your own tighter set mostly produces a conflict the vendor will price.

GovRAMP is now a recognized on-ramp, which matters for state and local buyers

This is the change most likely to be missed, and it runs in the direction state and local governments have wanted for years. Class A eligibility under rule FRC-CLA-ASF requires a provider to have completed, within the previous 12 months, a certification from one of three named frameworks: FedRAMP Rev5 including FedRAMP Ready at any historical impact level, SOC 2 Type II, or GovRAMP at any historical impact level.

GovRAMP is the nonprofit formerly known as StateRAMP. It reports more than 1,200 member organizations, more than 70 government organizations engaged, and more than 330 products in its program, on a ladder that runs from a Security Snapshot against roughly 40 NIST controls up through Core and Ready verifications to an Authorized or Provisional verification against 300-plus controls. Until 2026 that ladder was a parallel track: a vendor built a GovRAMP posture for state customers and a FedRAMP posture for federal ones, and neither counted for the other.

Naming GovRAMP in the Class A eligibility rule changes the economics for a company selling into both markets. The work a vendor did to satisfy states now buys a documented position in the federal entry tier. For a state or county buyer, the read is different and just as useful: a vendor with a GovRAMP verification now has a defined federal path, which is worth asking about during market research and worth scoring in an evaluation.

Two boundaries are worth stating plainly, because vendors will overstate this. First, the program was explicit when it opened the external-framework door through RFC-0022 that "no reciprocity is intended or will be granted in this process." Recognition as an eligibility input is not equivalence. Second, Class A itself is designed to be temporary. The program describes Class A certifications as "intended to be transitory and replaced by a Class B, C, or D FedRAMP Certification," with early RFC material describing a two-year window and the current rules tying the clock to federal use: once a cloud service offering has a federal customer using the service, it has 12 months to begin transition to a Class B or higher certification. Read the current rule text rather than the RFC summary; this is exactly the sort of parameter that has moved during the transition.

Scope did not get easier

One thing the modernization did not do is relax the boundary question, which is where most first-time efforts actually stall. Under the Minimum Assessment Scope ruleset, providers must identify a set of information resources to assess that "includes all information resources that are likely to handle federal customer data or likely to impact the confidentiality, integrity, or availability of federal customer data handled by the cloud service offering" (MAS-CSO-IIR). Information flows and security categories must be identified, documented and explained for all information resources in the offering (MAS-CSO-FLO).

Third-party resources get their own rule (MAS-CSO-TPR): document each one's usage, configuration, justification for use, mitigation measures, and compensating controls that reduce potential impact to federal customer data. For a stack with a dozen managed services and several analytics and observability vendors wired in, that is the largest documentation task in the package, and the one that benefits most from being generated out of infrastructure definitions rather than assembled by hand.

The exclusions are narrow. Products or services the OMB Director specifies as out of scope are excluded, as is software delivered separately for installation on agency systems — agents, clients, mobile apps — that is not operated under the shared responsibility model. Everything else that touches federal customer data is in.

Where the picture is genuinely unsettled

Three items are in flux, and a buyer is better served knowing which parts of this are still moving.

Class D does not exist yet. High-impact workloads have no 20x class today. Phase Four is estimated for FY27 Q1 to Q2, and Phase Five, the end of life for Rev5 certifications, is estimated for FY27 Q3 to Q4. Those are estimates on a roadmap, not published deadlines like June 11, 2027. A program planning a high-impact cloud deployment in that window should be tracking the roadmap, not assuming a date.

The statutory clock and the program clock are not aligned. The FedRAMP provisions at 44 U.S.C. 3607 through 3616 carry a repeal effective five years after December 23, 2022, which is December 23, 2027, under section 5921(d)(1) of Public Law 117-263. Congress may extend or replace those provisions; that is ordinary. But the sunset sits roughly six months after the last date on FedRAMP's own published transition calendar and inside the estimated window for Rev5 end of life. Anyone writing a multi-year cloud services contract that leans on the section 3613 presumption should know that the presumption has a statutory expiration on the books today.

Volume is early. In the first days of August 2026 FedRAMP's own counters showed 529 certified services in total and 28 of them certified under 20x, with the program reporting nearly 30 Marketplace Provider Listing Forms received within 30 days of the Consolidated Rules launch. Those numbers are moving weekly and should be re-checked rather than quoted. The honest summary is that the machinery is live and the population running through it is still small.

What to do with this in the next quarter

• Re-read any requirement document that says "FedRAMP Ready." That status stopped accepting new submissions on July 28, 2026. If it is a qualifier in your draft solicitation, replace it with a class.
• Say which class you need, and say why. Class B and Class C are distinguished by whether an entire agency is likely to rely on the service for important work. That is a business judgment your program office can make and should write down.
• Ask a prospective vendor for its next Ongoing Certification Report date. It is a published data point under CCM-OCR-NRD, and a vendor that cannot answer is not operating the cadence.
• Put the quarterly review on your calendar, not theirs. Class C providers must host it and open it to necessary parties. Attending it is the cheapest continuous oversight a customer will ever get.
• Mirror the change-notification day counts rather than inventing your own. 30 and 10 business days before a transformative change, 5 after, 10 after an adaptive change.
• If you buy for a state, county or city, ask about GovRAMP and about Class A together. They are now connected by rule, and the answer tells you whether a vendor has a real federal path or a slide about one.
• Cite rule identifiers in contract language. The rules are versioned and machine-readable. A clause that names VDR-TFR-PVR ages better than one that paraphrases a remediation table.

Bottom line

FedRAMP 20x is no longer a pilot, no longer optional to understand, and no longer described accurately by most of the material written about it in 2025. The program traded a document review for a running obligation: continuous verification on a three-day floor, severity judged by consequence to agencies, remediation clocks in days, quarterly reports and a live quarterly meeting, and change notifications counted in business days. It also opened one door that was closed before, by naming GovRAMP alongside Rev5 and SOC 2 Type II as a path into the entry class. The dates through June 11, 2027 are published. The class you need is a decision your program can make this quarter. Everything else is reading the rule text, which is, for the first time, actually available as text.

Frequently asked questions