On June 24, 2026, FedRAMP finalized the Consolidated Rules for 2026. That makes FedRAMP 20x real in a way it was not while the program was still moving through drafts, pilots, and public comment, and it starts the clock on a broader transition that affects more than cloud service providers pursuing 20x.
CR26 changes how providers enter FedRAMP, define scope, prove security, maintain certification, and work with federal agencies. Some of those changes apply directly to organizations already operating under Rev. 5.
In this episode of the 38North Security Podcast, Ingrid Velasquez-Woodley speaks with Sam Leestma, Vice President of Solutions Engineering, and Spence Witten, Principal Consultant, about the six parts of CR26 most likely to affect providers and agencies:
- The new certification classes
- Minimum Assessment Scope
- Key Security Indicators and the Security Decision Record
- Vulnerability Detection and Response and Vulnerability Evaluation and Reporting
- Ongoing certification
- New limits on agency-specific FedRAMP requirements
They discuss what these changes are intended to fix, what FedRAMP got right, where the model could create new problems, and what providers should begin preparing for now.
Watch the full discussion:
You can also listen to it here:
If you’d rather read it, here is the full breakdown:
1. Certification Classes Change What FedRAMP Is Measuring
Under Rev. 5, providers and agencies generally talked about Low, Moderate, and High impact levels. CR26 introduces Class A, Class B, Class C, and eventually Class D certifications.
At first glance, it is tempting to treat these as renamed versions of the old impact levels. Class B looks somewhat like Low. Class C looks somewhat like Moderate. Class D will occupy the territory traditionally associated with High. But that comparison only goes so far, because the more important change is what the classes are intended to represent.
CR26 is not simply asking whether a provider has implemented a larger or smaller collection of security controls. The classes reflect the level of assurance the provider must continuously demonstrate, the speed at which it must respond, and the rigor of its reporting and validation.
That is a meaningful shift. Under the old model, moving from Moderate to High often meant adding more controls and tighter parameters, but more controls did not always translate into a system that could respond more effectively to modern threats.
As Spence Witten put it during the discussion, the new model is less about doing entirely different things at higher classes and more about doing the fundamentals “better and faster” when the risk demands it. That is closer to how mature commercial cloud environments operate.
A provider handling more consequential government data may not need a completely different security philosophy. It may need stronger assurance, faster response, better visibility, and less tolerance for uncertainty.
The change also forces agencies to think more carefully about the actual impact of their data. For years, federal buyers have often defaulted to Moderate whether or not the use case genuinely required it. Under CR26, agencies will have to consider not only the type of data involved, but how much assurance they actually need from the provider.
That could create a better buying signal, but it could also create confusion, particularly while agencies and providers continue mentally translating the new classes back into Low, Moderate, and High.
The class structure will work only if agencies understand what each class means and resist treating the highest class as the default or the most marketable option. For providers, the right question is not, “What is the highest class we can pursue?” It is, “What level of assurance do our intended agency customers actually require, and what level can we operate consistently?”
2. Minimum Assessment Scope Could Reduce Waste—But It Introduces Judgment
Minimum Assessment Scope, or MAS, may be one of the most commercially important parts of CR26.
Under Rev. 5, providers often defined broad authorization boundaries that pulled in systems, tools, and integrations because they sat inside the technical environment or connected to it in some way. That led to years of arguments over systems that had little or no meaningful impact on federal data.
A public weather widget could become a FedRAMP discussion. A search feature could trigger questions because it connected to a non-FedRAMP service. Providers and agencies spent time and money analyzing components that did not materially affect the security of the cloud offering.
MAS attempts to focus the assessment on what actually matters. The central question becomes whether a system, component, or service can affect federal data, compromise the offering, or disrupt the government’s use of the service.
That should eliminate a great deal of noise. It should also help providers avoid dragging unrelated parts of a commercial environment into the scope of a FedRAMP assessment simply because they happen to exist nearby.
But MAS does not remove judgment. In some respects, it increases it.
Providers now have greater flexibility to explain why a system belongs inside or outside the assessment scope. That flexibility is useful, but it creates risk when the answer has major engineering and financial consequences.
Consider vulnerability scanners, identity platforms, ticketing tools, and other supporting systems. A provider may conclude that a commercial vulnerability scanner does not handle federal data and therefore does not need to be FedRAMP Authorized. That may be a defensible interpretation.
But what happens if an assessor, agency, or FedRAMP later disagrees?
Replacing that scanner may require months of engineering work. The same is true for identity providers, support platforms, and other tools embedded deeply in the operating environment.
That uncertainty is already affecting architecture decisions. FedRAMP-authorized versions of commercial tools can cost several times more than their standard commercial counterparts. If providers believe they must use the authorized version throughout their company, many will decide that a separate federal environment is still more economical.
That would work against one of the broader goals of 20x: enabling the government to use commercial cloud products more directly, without requiring separate federal versions of every system and process.
MAS is directionally strong because it focuses attention on real impact instead of theoretical connection. But the market still needs clearer norms around which categories of tools must be FedRAMP Authorized, which can be justified through the provider’s scope decision, and how consistently agencies and assessors will accept those decisions.
Until those norms emerge, many providers will take the cautious path, and the cautious path is often the expensive one.
3. KSIs and the SDR Move FedRAMP Toward a More Scalable Model
FedRAMP 20x is built around a simple idea: providers should demonstrate that security is working, not merely document that controls exist.
Key Security Indicators, or KSIs, are central to that model. Instead of relying primarily on point-in-time documentation and large evidence collections, KSIs are intended to show the current condition of important security capabilities using information generated from the system itself.
That is a better fit for modern cloud environments.
Traditional compliance assessments have always had a scaling problem. A provider writes documentation. An assessor reads it, samples evidence, conducts interviews, and determines whether the documented process was operating at a particular point in time.
That process can be useful, but it is expensive, manual, and vulnerable to inconsistency. The wider compliance market has also demonstrated that a completed audit report does not always provide the level of assurance buyers assume it does.
A trust center showing current security results against meaningful indicators may provide a more useful picture than a report based on evidence collected months earlier.
The theory is strong, but the implementation will require refinement. Some KSIs will prove more measurable than others. Providers may demonstrate the same outcome in different ways. FedRAMP, assessors, and the broader community will have to determine where flexibility is useful and where it creates inconsistent interpretations.
The Security Decision Record, or SDR, is intended to provide the narrativeexplanation and demonstration around those decisions and the validation of their implementations. It explains how the provider approaches security, why it made particular implementation choices, how it meets the applicable rules and KSIs, and how the different pieces of the system fit together.
That makes it different from the traditional System Security Plan.
The SSP often became an enormous control-by-control document created largely for assessment purposes. The SDR is supposed to be a maintained record of security decisions, not a document assembled once and allowed to decay.
That distinction matters. A useful SDR should help an agency, assessor, customer, or internal stakeholder understand how the provider’s security program actually works. It should not become a 300-page compliance artifact with a new name.
There is still a legitimate concern that requirements around explanation, verification, and validation could recreate some of the manual evidence burden 20x is trying to eliminate. The division of responsibility between the provider and the independent assessor will need to remain clear.
The provider should explain and support its decisions. The assessor should independently determine whether those decisions are appropriate and working.
If the SDR becomes a repository for screenshots and point-in-time evidence, the model will have drifted back toward the process it was designed to replace. If it remains concise, current, and connected to the actual operation of the system, it could become one of the more useful artifacts in FedRAMP.
4. VDR and VER Will Be the First Major Operational Test
Vulnerability Detection and Response and Vulnerability Evaluation and Reporting become mandatory for FedRAMP-certified cloud services on December 7, 2026. That includes existing Rev. 5 providers.
This may be the most immediate implementation challenge in CR26.
VDR changes the way providers are expected to think about vulnerabilities. Under a traditional model, a provider runs scans, assigns findings to severity categories, tracks them against standard remediation timelines, and reports progress through a POA&M.
VDR requires more context.
The same vulnerability may pose very different risks depending on where it exists, whether the affected asset is internet-reachable, whether exploitation is known or feasible, what data or functions are exposed, and what the potential impact to an agency would be.
A vulnerability that is low risk in one part of the environment may be urgent in another. That is how vulnerability management should work in practice, and VDR formalizes it.
VER then addresses how that evaluation and response information is reported and communicated.
For mature, cloud-native providers with automated asset inventories, vulnerability tooling, ticketing workflows, and response processes, the transition may be manageable. For legacy Rev. 5 environments, it could be substantial.
The difficult part is not necessarily running scans more frequently. Many providers already scan continuously. The difficult part is connecting the data needed to make an informed risk decision:
- What asset is affected?
- What function does it perform?
- Is it reachable from the internet?
- Is the vulnerability known to be exploited?
- Can exploitation be automated?
- What would happen if the vulnerability were successfully used?
- What is the potential impact to the government?
- Can the risk be mitigated if no patch exists?
- When does the condition become reportable?
That level of analysis does not scale manually in a large environment.
Providers will need automation. They will also need operational ownership across security, engineering, compliance, vulnerability management, and incident response. VDR is not a reporting exercise that can be assigned to the FedRAMP team and completed in isolation.
The December deadline is realistic for some providers and extremely aggressive for others. Large organizations may already have capital planning and engineering priorities set for the year. Smaller providers may be more agile but have fewer people available to build and operate the necessary workflows.
The timing is difficult, but the underlying requirement is still worthwhile.
Unlike many compliance projects, implementing VDR properly should improve the way the organization manages vulnerabilities outside FedRAMP as well. It should help teams focus resources on the findings that create the greatest actual risk instead of treating every “high” vulnerability as equally urgent.
The organizations that begin now may emerge with a better vulnerability-management program. The organizations that wait may find themselves trying to automate a complex operating process during the final weeks of the year.
5. Ongoing Certification Should Reduce Point-in-Time Scrambles
CR26 also shifts FedRAMP toward ongoing certification.
That does not mean annual independent assessments disappear. It means the provider is expected to maintain current certification information throughout the year rather than reconstructing its security posture when an assessment approaches.
This is closely related to continuous validation, but the terms are not interchangeable.
Continuous validation refers to the provider’s ability to generate and expose current information about whether security capabilities are operating as intended.
Ongoing certification is broader. It includes the processes, reporting, change notifications, historical records, trust-center data, and independent reviews required to maintain certification over time.
In theory, this should reduce the burden of annual assessments. If the provider has maintained reliable validation information all year, the assessor should not need to recreate the entire picture through a large point-in-time evidence request.
The assessment can focus more heavily on whether the continuous system is accurate, complete, and trustworthy.
That is the promise.
The risk is that providers end up maintaining continuous reporting while still being subjected to the same manual annual process. That would create both a year-round audit and a traditional annual audit rather than replacing one with the other.
The 3PAO community will play an important role here. Assessors will need to adapt their methods and business models to a world in which much of the evidence is already current and available.
The value of the assessment should come from independent judgment, testing, and validation, not from asking providers to repackage information already available in the system.
Continuous visibility also creates a cultural adjustment for providers. Agencies may be able to view security information at any time. A temporary issue that once would have been resolved before the next monthly submission may now be visible as it occurs.
For operationally mature providers, that transparency should build trust. For less mature providers, it may expose gaps in staffing, response coverage, or the reliability of their reporting systems.
The model rewards organizations that can operate security continuously, not merely prepare for it periodically.
6. Agencies Are Being Told to Stop Rebuilding FedRAMP
One of the most consequential parts of CR26 may be the new expectations placed on federal agencies.
FedRAMP was created in part to provide a reusable, government-wide approach to cloud security. In practice, agencies have often layered on their own control sets, documentation requests, assessment processes, and interpretations after a provider has already completed FedRAMP.
That has undermined the promise of reuse.
Providers have spent months responding to requirements that added cost and delay without meaningfully improving security. Agencies then paid for that work through longer implementation timelines, additional contractor hours, and delayed access to cloud capabilities.
CR26 takes a much harder position against that behavior.
Agencies generally should not require additional information or materials from a FedRAMP-certified provider unless they can demonstrate a legitimate need. They also should not insist on a particular certification type or path merely because it matches their historic preference.
That does not remove the agency’s responsibility. An agency must still determine whether a cloud service is appropriate for its specific use, data, mission, and risk, and it must still issue its own authorization to use that service.
But it should use the certification data that already exists instead of rebuilding the provider’s security assessment from scratch.
There will always be legitimate exceptions. An agency may have a mission-specific threat, a unique operational environment, or legal requirements that justify additional scrutiny.
The problem has never been that agencies ask questions. The problem has been the tendency to create parallel FedRAMP programs inside individual agencies, often without a clear explanation of the additional security value.
If agencies follow the new model, providers could see fewer one-off documents, fewer conflicting interpretations, fewer duplicate assessments, and faster adoption across government.
If agencies ignore the intent and continue operating as before, much of CR26’s potential efficiency will disappear.
The success of 20x depends on provider modernization. It also depends on agency behavior.
The Dates Providers Need to Know
The transition is already underway.
June 24, 2026
CR26 became final, establishing the rules and transition schedule.
July 4, 2026
Optional early adoption begins for many of the Consolidated Rules. Providers that are ready can begin moving toward the new operating model before broader adoption becomes mandatory.
July 28, 2026
FedRAMP Ready becomes a legacy designation. Class A is intended to provide a more operationally useful entry point than FedRAMP Ready, including clearer paths for limited government use and pilots.
August 3, 2026
Class A applications open. The final Class A requirements are more substantial than some earlier versions suggested, and providers should review the eligibility, assessment, KSI, and trust-center requirements carefully before assuming it is a lightweight path.
August 10, 2026
Temporary Rev. 5 Class B and Class C pathways open for a limited group of providers, including certain organizations converting from FedRAMP Ready or affected by the loss of an agency sponsor. These are narrow transition pathways, not general alternatives to 20x.
August 31, 2026
The general 20x Class B and Class C application pipelines open.
December 7, 2026
VDR and VER become mandatory for cloud services obtaining or maintaining FedRAMP certification. Providers need the processes to be operational by this date. It is not a date to begin planning.
January 1, 2027
Broader mandatory adoption of CR26 begins. Existing Rev. 5 providers will need to understand which rules apply directly, which are incorporated through future assessments, and what transition work must be completed.
June 11, 2027
FedRAMP stops accepting new Rev. 5 certification applications. After that date, providers seeking a new FedRAMP certification will need to use the 20x model.
What Providers Should Do Now
The right next step depends on where the organization is today.
Providers considering FedRAMP should determine which certification class aligns with their intended agency customers, data, and operating maturity. They should define Minimum Assessment Scope carefully and avoid assuming that 20x automatically means a smaller or less expensive program.
Existing Rev. 5 providers should begin with VDR and VER and apply the MAS rules to properly understand where it applies. They need to map their current vulnerability-management process, determine whether asset and exposure context can be connected to findings, identify where manual analysis is still required, and establish who owns prioritization, mitigation, reporting, and response.
All providers should assess whether their architecture and engineering practices can support continuous validation.
The organizations best positioned for 20x will be those that can generate reliable security information directly from their systems, maintain it over time, and use it to make operational decisions, not simply produce it for an assessor.
CR26 Creates an Opportunity—But Execution Will Decide the Outcome
With CR26 becoming final, the way providers enter FedRAMP, prove security, maintain certification, and work with federal agencies has materially changed. That applies both to CSPs considering FedRAMP 20x and to providers already holding Rev. 5 certifications.
The direction is promising. CR26 could reduce unnecessary scope, improve vulnerability prioritization, replace point-in-time evidence with more useful security information, reduce duplicate agency requirements, and make FedRAMP certification more reusable across government.
But none of those outcomes is automatic.
Providers will need to make careful architecture, tooling, scope, and operational decisions. Assessors will need to adapt to a model built around continuous information rather than recurring evidence scrambles. Agencies will need to use the shared certification model instead of recreating their own.
FedRAMP has finalized the rules. Now the real test begins.
Prepare for CR26 and FedRAMP 20x
38North helps cloud service providers evaluate their FedRAMP path, define Minimum Assessment Scope, prepare for VDR and VER, and build the technical and operational capabilities required for ongoing certification.
Talk with our team about your CR26 readiness and the right path for your cloud service offering.
Request a consultation here: https://38northsecurity.com/contact/
About the Authors
