FedRAMP is scrapping the annual audit. Here's what 20X actually changes.

Key points

• FedRAMP, the US government programme that decides which cloud services federal agencies are allowed to buy, is retiring its current Rev5 rulebook and replacing it with a new framework called 20X.
• The old system relied on huge PDF audit reports produced once a year; 20X asks for continuous, machine-readable evidence that security controls are actually running.
• Cloud vendors that sell to federal agencies will need to rewire how they collect and share security data, not just how they write it up.
• Organisations that already automate compliance evidence will have a much easier transition than those still exporting screenshots into Word documents.
• No hard cutover date has been published for every provider, but Rev5 authorisations are on borrowed time.

FedRAMP has been the federal government's cloud gatekeeper for over a decade. If you want to sell a cloud service to a US agency, you go through it. Anyone who has actually done a FedRAMP package knows the drill: hundreds of controls, thousands of pages, an assessor on site, and a System Security Plan that nobody reads end to end.

That model's on the way out. The programme is moving from Revision 5, the current control baseline, to something it's calling FedRAMP 20X. As first reported by BleepingComputer, via an explainer from compliance vendor Anecdotes, the shift is less about new controls and more about how you prove the ones you have are working.

What is actually changing?

The evidence model. Rev5 is a point-in-time audit: a snapshot taken once a year, written up, signed off, filed away. 20X wants that evidence produced continuously and in a format machines can read, so an agency can see the state of your controls today, not last March.

In practice that means pulling data directly from the systems where the work happens. Configuration state from AWS Config or Azure Policy. Identity events from Okta or Entra ID. Vulnerability findings from whatever scanner you run against your container images. The evidence is generated by the platform itself, not typed into a spreadsheet by a compliance analyst at quarter end.

Why is FedRAMP doing this now?

Because the old process is slow and genuinely not a great signal of security. A cloud provider can pass a Rev5 assessment in June and be running misconfigured storage buckets by August. The failure mode is well known to anyone who has sat through a SOC 2 readout: the paperwork's pristine, the production environment isn't.

Federal buyers have been pushing for something closer to real-time assurance for years. 20X is the answer. It also lines up with where the private sector is heading, with continuous controls monitoring baked into tools from Wiz and Drata. Our 13 July story on CISA leaving AWS GovCloud keys on GitHub for six months is a fair illustration of what point-in-time assurance misses.

What does this mean for cloud vendors?

More engineering work, less document wrangling. If your compliance programme is a shared drive full of Word files, 20X is going to hurt. Already emitting control evidence as structured data? OSCAL (Open Security Controls Assessment Language, the machine-readable format FedRAMP has been nudging everyone toward) means you're most of the way there.

The vendors who treated FedRAMP as a paperwork exercise will get caught out. The ones who wired their controls into their CI/CD pipeline and their cloud posture tooling had the evidence sitting there already.

Should customers care?

If you're a federal employee using a cloud tool at work, or a citizen whose data sits in one, the practical answer is yes, quietly. Continuous evidence should mean fewer long gaps where a certified vendor has silently drifted out of compliance. Won't stop breaches. Will shorten the window in which nobody notices.

Operational takeaway: if your FedRAMP evidence still lives in a shared drive, start the OSCAL conversation this quarter, not next.