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 is on the way out. The programme is moving from Revision 5, the current control baseline, to something it is 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 point is that 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, expensive, and honestly 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 here is well known to anyone who has sat through a SOC 2 readout: the paperwork is pristine, the production environment is not.

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 already heading, with frameworks like continuous controls monitoring baked into tools from Wiz, Vanta, Drata and others.

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. If you already emit control evidence as structured data (OSCAL is the format FedRAMP has been nudging everyone toward), you are most of the way there.

One thing the post-mortem will say, eventually, is that the vendors who treated FedRAMP as a paperwork exercise got caught out. The ones who wired their controls into their CI/CD pipeline and their cloud posture tooling had the evidence already sitting there.

Should customers care?

If you are a federal employee using a cloud tool at work, or a citizen whose data sits in one, the practical answer is yes but quietly. Continuous evidence should mean fewer long gaps where a certified vendor has silently drifted out of compliance. It will not stop breaches. It 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.