Everyone agrees FedRAMP 20x is the right direction. Almost no one agrees on what a finished authorization—err…certification?— should mean.
I walked away from the Summit on FedRAMP with an interesting observation about FedRAMP 20x. After conversations with agency representatives, 3PAOs, CSPs, and other people who spend far too much of their lives thinking about authorization packages, there actually seems to be a surprising amount of agreement about one thing: FedRAMP is moving in the right direction.
Automation? Yes, hold my beer.
Machine-readable security data? Absolutely, keep it coming.
Continuous validation instead of periodic archaeology expeditions through 700-page System Security Plans? Burn them and let’s move on, yeah!
Replacing screenshots, spreadsheets, and carefully curated evidence packages with repeatable queries against actual system state? Sign me up yesterday.
That part really isn't controversial anymore. The uncomfortable part is that I am increasingly convinced that we do not all agree on what FedRAMP 20x is supposed to mean once a Cloud Service Provider (CSP) actually finishes the FedRAMP process. And that is a much bigger problem than it sounds.
The Technology Is Changing Faster Than the Mental Model
For decades, federal authorization has largely been built around documents. We describe security controls in prose, periodically collect evidence, hand it to assessors, remediate findings, and eventually present an Authorizing Official with enough information to make a risk decision. FedRAMP 20x changes that model substantially.
The emerging approach is built around machine-readable requirements, Key Security Indicators (KSIs), automated validation, structured evidence, and continuously observable system state. It is a move away from telling an assessor that a security capability exists and toward allowing the assessor to verify that capability directly. Good. Excellent. Awesome, even.
Frankly, overdue. We have been advocating this model for years at stackArmor because modern cloud systems already work this way. Infrastructure is code. Configuration is data. Telemetry is available through APIs. There is no logical reason that proving a disk is encrypted should require an engineer to log into a console, arrange the screen just so, take a screenshot, paste it into Word, and hope everyone remembers what it represented six months later.
That's not evidence collection. That's compliance theater.
But modernizing the technology underneath FedRAMP only solves half the problem. The other half is getting the federal ecosystem to agree on what that evidence means.
My Biggest 20x Concern Isn't 20x
The concern I heard repeatedly at the Summit was not that 20x would fail to authorize cloud services. Quite the opposite.
There is real optimism that the new model could dramatically accelerate a CSP's ability to complete the FedRAMP process. That alone is enormously valuable, particularly if it removes some of the traditional sponsorship bottlenecks that have prevented otherwise capable providers from getting into the federal marketplace. The concern is what happens next.
Imagine a CSP completes the 20x process using KSIs, automated validation, and the new CR26 machine-readable formats. Great. They walk into Agency A.
"That's nice. Now send us your traditional SSP, POA&M, control implementation statements, and our agency-specific evidence workbook. Don't forget that insanely expensive 3PAO assessment."
Wants something slightly different.
Accepts some of the FedRAMP artifacts but wants its own assessment of another subset.
Has a template lovingly maintained since approximately the George W. Bush administration and, my goodness, someone is going to fill it out.
Congratulations.
We just reinvented the world FedRAMP was created to fix. 2011 was a heck of a year…
Welcome Back to Pre-FedRAMP
The fundamental promise of FedRAMP was never merely that a CSP could survive an assessment. The value was standardization and reuse. Assess once. Establish a common body of security evidence. Allow agencies to leverage that work while making their own mission-specific risk decisions.
That distinction matters.
An agency absolutely owns its authorization decision (it always has). It should understand the data being processed, the mission impact, the system's dependencies, and risks specific to its use of the service. FedRAMP should never become a substitute for an Authorizing Official (AO) exercising judgment.
But there is a huge difference between evaluating mission-specific risk and re-performing the underlying cloud service assessment because one agency prefers a different spreadsheet over another.
If every agency develops its own interpretation of what the KSIs prove, what CR26 evidence it trusts, and what additional documentation it requires, then we haven't created reciprocity. We've created a really fast, overly complex, stupidly expensive way to reach the starting line.
That would be a spectacularly unfortunate outcome.
20x Still Has Enormous Value
This is why I don't subscribe to the argument that uncertainty around agency adoption makes 20x pointless. It doesn't. Even in a messy implementation scenario, 20x could fundamentally improve market access.
If a CSP can establish its FedRAMP status in weeks rather than spending months or years navigating sponsorship and package development, it can begin meaningful conversations with agencies substantially earlier. That matters commercially, and it matters to agencies that want access to innovative cloud capabilities. So yes, 20x can absolutely be an accelerator.
But we should aspire to more than accelerating CSPs toward fifty different agency authorization processes.
The bigger win is establishing a common language of assurance that follows the service.
That is where CR26, KSIs, machine-readable evidence, and automated assessment must come together.
The Ecosystem Needs a Shared Definition of “Done”
This, to me, is the next major challenge for FedRAMP. We need alignment among FedRAMP, agencies, CSPs, and 3PAOs around what a 20x authorization actually conveys.
What security assertions can an agency reasonably inherit?
What evidence has already been validated?
What should an agency be able to ask a CSP to demonstrate again?
And, perhaps most importantly, what information is legitimately agency-specific because it relates to mission risk rather than the security of the underlying cloud service?
Those boundaries need to become boringly clear.
Because ambiguity has a predictable result in federal compliance: everyone asks for everything. Nobody gets fired for requesting another document. The CSP just gets to maintain two compliance systems.
Where stackArmor Fits
This is also why I increasingly describe stackArmor less as a traditional compliance company and more as an assurance engineering company. Our job is to connect system operations, security telemetry, compliance requirements, and authorization decisions.
We collect evidence from the running environment, normalize it, evaluate it against requirements, and make the result understandable to the humans ultimately responsible for risk. The same underlying system state should be capable of supporting FedRAMP, a 3PAO assessment, an agency risk review, and continuous monitoring without repeatedly recreating the evidence from scratch. That is the promise of machine-readable compliance.
Not putting lipstick on your paperwork. There is a better way.
Let's Make 20x Mean Something
FedRAMP 20x has the potential to be one of the most important changes to federal cloud security in years. The technical direction is right. The automation is right. The emphasis on continuously validated security capabilities is right.
Now comes the harder part: getting the ecosystem to agree on what all of that buys us. If 20x becomes merely a faster FedRAMP credential followed by the same bespoke agency-by-agency documentation gauntlet, we will have modernized the machinery without fixing the process. We can do better.
FedRAMP 20x shouldn't simply make the old road faster. It should give us a better road.