Beyond the Screenshot

Anyone who has been through a security audit knows the folder. It holds screenshots of settings, exported policies and a spreadsheet of owners, all neatly named and dated to the week of the assessment. It looks reassuring. It also tells you very little about whether the control is working today, or what would warn you if it stopped.

The Shift from Narrative to Automation

That gap between paperwork and reality is the problem FedRAMP 20x was designed to close. The programme, which governs how cloud services are cleared to work with the US federal government, has spent years leaning on long System Security Plans, in some cases hundreds of pages of narrative. Under the traditional Rev5 route, getting an agency authorisation could take 12 to 18 months or more. 20x was announced in March 2025 with a bold goal: certify providers in weeks, using automation and machine-readable evidence.

It’s no longer an experiment. According to coverage of the June 2026 announcement, FedRAMP finalised its Consolidated Rules for 2026, known as CR26, and made 20x a widely available certification path. The rules arrive in plain language, with direct must and must not statements, and they’re published as machine-readable files. Rev5 and 20x run side by side for now, though FedRAMP recommends 20x. The CR26 rules become mandatory for all stakeholders on 1 January 2027, new Rev5 applications stop being accepted on 11 June 2027, and existing Rev5 authorisations are expected to sunset toward the end of 2028.

Key Security Indicators: Continuous vs. Periodic

The mechanics matter, because they change what a provider actually has to do. In place of narrative control descriptions, 20x uses Key Security Indicators. There are 56 in the Low baseline and 61 in Moderate, spread across twelve security domains. Indicators that a machine can check are revalidated every few days, and those that depend on process are checked at least quarterly. Evidence is expected to be machine-readable, aligned to the OSCAL standard where it applies, and accompanied by a short human summary. One analysis of the programme says FedRAMP expects automation to cover at least 70% of the indicators.

If that sounds technical, the shift in philosophy is simple. Trust moves from what a provider documented to what its systems can currently demonstrate. As one commentator put it, security can be measured rather than described. A provider can’t retrofit a PDF at assessment time, because the evidence has to be generated by the systems themselves, over time, and regenerated on demand.

When Compliance Becomes Engineering

Practitioners who’ve spent careers in governance, risk and compliance describe this as the point where compliance becomes engineering. The good version of the idea is easy to sketch. Pull evidence straight from the systems doing the work. Give each piece an owner, a timestamp and a test you can repeat. Reuse the same evidence across several requirements where that makes sense. Show exceptions openly, including who accepted the risk and when it comes up for review. It’s the opposite of a beautifully organised folder.

There are honest costs. Smaller providers face a real entry fee in instrumentation and continuous validation, and the tooling and assessor market around 20x is still maturing. Several of the more enthusiastic accounts come from vendors who sell compliance automation, which is worth remembering when you read their forecasts. The programme’s own timeline also has moving parts, with different sources giving slightly different dates for individual steps, so anyone planning against it should check the official FedRAMP site before committing.

Speed and Rigour in Practice

Speed is part of the appeal, and the early signals are encouraging if you accept the caveat about sources. One vendor summary reports that average agency review time has fallen to around five weeks, that Rev5 authorisations more than doubled over a six month period, and that dozens of cloud services have entered the marketplace through the 20x pilots. Treat those numbers as directional until the programme publishes its own figures. The direction, though, is hard to miss.

Teams that have delivered rapid certifications tend to say the same few things. Keep the scope tight. Name owners early. Find the hard dependencies before they find you. Run the technical work and the assessment work side by side. Leave polishing internal workflows for later, but never the required controls. Speed has to come from making decisions and removing avoidable rework, not from quietly accepting a gap nobody wants to talk about.

Lessons for the Broader Market

There’s a lesson here beyond government cloud. Customers across the private sector are tired of questionnaires and PDFs, and procurement teams increasingly ask for proof they can check. A company that can show live evidence, with exceptions visible and owners named, will answer a buyer’s due diligence in days rather than months. A company that can’t will keep sending screenshots.

Automation helps, but it doesn’t remove judgment. Someone still has to decide whether the system is checking the right thing, and a perfectly green dashboard that measures the wrong control is worse than none. The strongest programmes keep a human asking a simple question: if this stopped working tomorrow, what would tell us?

FedRAMP 20x won’t fix compliance on its own. What it does is move the burden of proof to where it belongs, onto the systems. For an industry that has long relied on paper, that is a significant change, and the providers who treat it as an engineering project rather than a paperwork project will be the ones who barely notice the deadline.