Inteltech
FedRAMP 20x Changes the Unit of Evidence, Not the Form
OSCAL made the paperwork machine-readable. FedRAMP 20x goes after the review itself, and the review was always the slow part of an ATO.
For years the pitch was that OSCAL would cut an authorization from eighteen months to six. Put the security documentation in a machine-readable format, let the tooling check it, and the queue moves faster.
The format was never the bottleneck. The review was.
That distinction is finally visible in FedRAMP 20x (opens in a new tab), which changes what a provider has to prove rather than what file it submits. If you are planning an authorization in the next year, the difference between those two projects is the difference between a reformatting exercise and a rebuild of your evidence pipeline.
OSCAL changed the container
OSCAL is NIST's set of data models for security documentation: a catalog of controls, a profile that selects and constrains them, a system security plan, an assessment plan, an assessment report, and a plan of action and milestones. FedRAMP publishes its baselines as OSCAL profiles.
That is a real improvement. A machine can validate a document against a schema. Two packages can be compared without a human reading both. A field that is empty is empty everywhere, which is not true of a two thousand page narrative.
But here is what does not change when the SSP becomes JSON. Somebody still has to decide whether the control is implemented. The assessor still reads the evidence, tests a sample, and exercises judgment about whether the description matches the system. Reformatting the description does not shorten that step, and if the queue is long because there are not enough assessors, a tidier package does not add any.
An OSCAL-native package that says the same thing in a structured way gets you a faster intake and a cleaner diff. It does not get you a decision.
What 20x actually changes
The 20x model moves the assessment onto security decisions and away from a control-by-control audit. The provider sets goals, defines measures, and shows continuous evidence that the measures are working. FedRAMP's own principles name it: automatic validation, where status and outcomes are "automatically enforced and validated whenever possible."
That is a different unit of work. Instead of answering five hundred controls in prose, you publish measurements that a machine can check on a schedule. The evidence is the running system, not a screenshot of the running system.
The schedule matters if you are budgeting. The Low pilot closed in September 2025 with 26 submissions. The Moderate pilot ran through early 2026. The rules for Classes A, B, and C are finalized, and the submission pipeline was planned to open in the fourth quarter of fiscal 2026. Class D, the High equivalent, is a pilot estimated for fiscal 2027.
And there is a hard date on the other side. FedRAMP will stop accepting new Rev5 certifications on June 11, 2027.
What it means for the vendor
Three consequences follow, and they are engineering consequences rather than documentation ones.
Your evidence has to be generated, not written. If a measure has to be true continuously, the thing that proves it has to run continuously. That points at configuration scanning, policy as code, and log pipelines that emit structured results, not at a compliance analyst with a template.
Your control set has to be explicit in code. A policy that lives in a wiki cannot be validated automatically. A policy expressed as a rule in your pipeline can. The migration is from "we have a policy" to "the pipeline refuses a deploy that violates the policy," and the second one produces evidence as a side effect.
Your assessor becomes an auditor of your measurement, not of your prose. That is a skill change on both sides of the table. The question shifts from "show me how you meet AC-2" to "show me that this measure has been green for ninety days and that a red one opens a ticket."
None of that is exotic. Most of it is work a competent platform team already does for reliability. The compliance program just has to consume the output instead of commissioning a parallel universe of screenshots.
What it does not fix
The temptation with any automation program is to assume the hard cases disappear. They do not.
Class D is not here yet, so a High-impact system is still on the old path for now, with a pilot estimated for fiscal 2027. Subjective controls still need a person. Tooling maturity is still uneven, and every provider I have seen attempt this has written glue code that nobody wanted to own.
The other thing 20x does not fix is the boundary problem. An authorization covers a defined boundary. If your service spans a commercial region, a government region, and a model endpoint you do not operate, you have more than one thing to describe and the weakest part sets the timeline. Automation makes a boundary cheaper to monitor. It does not make it smaller.
Where I would start
If your authorization is more than a year out, start with the measures rather than the document. Pick ten controls your team already monitors for reliability. Write each one as a check with a threshold and a named owner. Run them for a quarter and see what the false positive rate looks like.
That exercise tells you two things a consultant cannot: whether your evidence is actually continuous, and whether you can afford the review load when a check goes red. Both answers are cheaper to learn now than during an assessment.
An ATO is a decision someone makes about evidence. Automation can produce better evidence. It cannot make the decision for you, and a program that pretends otherwise just moves the queue.
Read the 20x principles and notice what is missing from them. There is no promise of a six-month authorization. There is a promise that the evidence will be current, which is the more useful thing to sell to an agency, and the harder thing to fake.