FedRAMP Rev. 5 providers who thought FedRAMP 20x was a future problem just received a very clear update: arts of the 20x operating model are becoming mandatory this year.
CISA recently released Binding Operational Directive (BOD) 26-04, which changes how federal agencies prioritize vulnerability remediation. FedRAMP then released Notice 0014, which applies that direction to FedRAMP cloud services and accelerates adoption of the new Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) rules.
On the same day, FedRAMP also released Notice 0013, which makes something broader clear. Rev. 5 is already being reshaped around many of the responsibility, flexibility, automation, and continuous assurance expectations behind FedRAMP 20x.
These updates fit together. BOD 26-04 changes how the federal government thinks about vulnerability risk. Notice 0014 turns that into an accelerated operational requirement for FedRAMP cloud service providers. Notice 0013 shows that this is part of a much larger transition away from the traditional Rev. 5 model.
Learn how to achieve FedRAMP certification for your cloud offering.
Watch the full discussion below:
Prefer to read? Dive in below.
BOD 26-04 Changes How Vulnerabilities are Prioritized
For years, federal vulnerability management has relied heavily on severity ratings and standard remediation timelines. A finding gets identified, assigned a score, entered into a tracking process, and expected to be resolved within a certain window.
The problem is that the volume of vulnerabilities has become too large for that model to work well. As Spence Witten explained during our discussion, federal agencies can carry enormous backlogs of high-severity vulnerabilities. At the same time, AI is making it easier to discover vulnerabilities and, in some cases, easier to develop working exploits.
We are not going to patch our way out of that volume. There are simply too many findings, too much variation in actual risk, and too little time to investigate every item manually. The only realistic option is to prioritize more intelligently.
That is what BOD 26-04 is trying to do. It asks agencies to evaluate vulnerabilities using four specific factors: whether the affected asset is publicly exposed, whether the vulnerability appears in CISA’s Known Exploited Vulnerabilities (KEV) Catalog, whether exploitation can be automated, and what technical impact successful exploitation would have.
That is a much more useful way to make remediation decisions than looking at severity alone. Two findings can carry the same CVSS score and still present completely different risks. One may sit deep inside a well-protected internal environment. The other may affect an internet-facing service, have a known exploit, and give an attacker broad control of the system.
The new model is designed to distinguish between those situations and direct the fastest response toward the vulnerability that presents the greatest actual threat.
Learn more: Is FedRAMP 20x More Secure Than Rev. 5?
The Real Change is the Analysis Behind the Scan
Operationally, this means teams need to do more than collect vulnerability findings. They need to understand the context around them.
As Sam Leestma put it, if a team has 45 high-severity vulnerabilities, the question is no longer simply whether all 45 meet the definition of “high.” The question is: Which one is the highest?
To answer that, teams need to know where the vulnerability exists, what kind of device or service it affects, whether that system handles government data, whether the asset is exposed or reachable from the internet, whether exploitation is occurring in the wild, and what could happen if an attacker succeeds.
That analysis cannot happen one finding at a time through manual research. The volume is too high, and the decisions need to happen too quickly. Providers need to connect vulnerability data with asset inventory, system context, threat intelligence, exposure information, and potential business or mission impact.
This is where automation becomes essential. The difficult part is not finding vulnerabilities. Most organizations already find plenty. The difficult part is taking thousands of findings and consistently deciding which ones demand immediate action.
Notice 0014 Brings That Model Into FedRAMP
BOD 26-04 is directed at federal agencies, but FedRAMP Notice 0014 makes clear that cloud service providers cannot treat this as an agency-only issue.
FedRAMP had already been developing a similar model through its Vulnerability Detection and Response requirements. Notice 0014 aligns those requirements with the new CISA directive and separates out the Vulnerability Evaluation and Reporting responsibilities so providers have clearer expectations around both the operational response and the reporting process.
The overlap between the two models is significant. Both focus on contextual risk rather than static severity alone. Both require teams to consider exposure, exploitability, and potential impact. FedRAMP goes further in several areas, particularly around internet reachability and the assumption that exploitation can be automated unless the provider has evidence showing otherwise.
Notice 0014 also establishes an aggressive timeline. VDR and VER become mandatory on December 7, 2026, for cloud service offerings obtaining or maintaining FedRAMP Certification. That includes existing Rev. 5 providers, not just organizations entering through 20x.
Providers that are not ready may temporarily remain certified under a corrective action plan through March 7, 2027, with their agency customers notified. After that point, providers that still have not adopted the requirements risk losing their FedRAMP Certification.
That makes December 7 an implementation deadline, not a date to begin planning. Providers need enough time to design the process, integrate the data, assign ownership, validate the workflow, and operate it before the requirement becomes mandatory.
Why Monthly Scanning Is No Longer Enough
FedRAMP says directly that the traditional monthly vulnerability-scanning process used by many Rev. 5 providers is insufficient, and both Sam and Spence agreed that this is long overdue.
The issue is not simply that monthly scanning is too infrequent. Many cloud providers already scan every few hours, scan continuously, or trigger scans whenever the environment changes. The larger problem is that the traditional FedRAMP process often treated vulnerability management as a reporting exercise.
Providers submitted large scan files, tracked findings against remediation timelines, requested extensions, and sometimes submitted requests to lower the risk rating of a vulnerability. That process created a record of what had been found and how long the provider had to address it, but it did not necessarily change the risk.
As Sam said during the conversation, the monthly scan and submission process was often a compliance exercise, not a security exercise. It showed the government what had been found and what was being tracked, but it did not always produce the kind of real-time prioritization and response that modern vulnerability management requires.
VDR changes that. It expects providers to continuously detect weaknesses, evaluate their context, prioritize their response, mitigate risk where immediate remediation is not possible, remove vulnerabilities where it is, and communicate meaningful status to the government.
It also looks beyond conventional scanner output. Vulnerabilities can come from configuration drift, penetration testing, supply-chain issues, process failures, bug bounty reports, or security research. A mature program needs to bring those sources together and evaluate them as part of one operational process.
Publicly Exposed and Internet-Reachable Are Not the Same Thing
One of the more important distinctions between BOD 26-04 and the FedRAMP rules is the difference between a publicly exposed asset and an internet-reachable component.
A publicly exposed asset sits directly on the edge of the environment and can communicate with the internet. A VPN gateway, bastion host, public web interface, or other perimeter service may fit that description.
An internet-reachable component may sit several layers deeper inside the architecture. It may not have a public IP address, and users may not communicate with it directly, but internet-originated input can still reach it through the application.
Spence used the example of a modern web application. Traffic may enter through a web application firewall, pass into a front-end service, travel through another security boundary, and eventually reach a backend microservice or container cluster. That backend component is not directly exposed, but an attacker may still be able to manipulate input that reaches it.
That is why FedRAMP’s broader definition matters. Modern cloud attacks do not stop at the first device on the network edge. Attackers use application flows, chained services, libraries, APIs, and backend systems. Providers need to understand the full path an attacker can take, not just whether a component is directly visible from the internet.
FedRAMP also says providers should assume that exploitation can be automated unless they can demonstrate otherwise. That changes the burden of proof. Teams cannot casually dismiss a vulnerability as too difficult to exploit. If they want to treat it as lower risk, they need evidence to support that conclusion.
Mitigation and Remediation Serve Different Purposes
Notice 0014 also makes an important distinction between mitigation and remediation.
Remediation removes the underlying vulnerability. That could mean applying a patch, upgrading a component, fixing code, replacing a product, or otherwise eliminating the weakness.
Mitigation reduces the risk while the vulnerability still exists. A provider might isolate the affected component, restrict access, add filtering, block a specific attack path, disable vulnerable functionality, or reduce the blast radius if exploitation occurs.
This matters because patches are not always available when a vulnerability is discovered. Even when a patch exists, applying it immediately may create operational problems or require testing before it can safely go into production.
In those situations, teams still need to respond. They may not be able to remove the vulnerability immediately, but they can reduce the likelihood of exploitation or limit the damage an attacker could cause.
As Sam explained, mitigation is about getting the risk down to a negligible or manageable level when full remediation is not yet possible. That becomes increasingly important as vulnerabilities are discovered faster than vendors can release patches.
Spence took that point one step further. The future of vulnerability management may depend not only on faster patching but also on automated mitigation. Organizations may need systems that can change access, introduce protective controls, isolate components, or alter traffic flows automatically when a high-risk vulnerability is discovered.
Quick remediation remains essential, but it may no longer be enough on its own.
Notice 0013 Makes Clear That Rev. 5 is Going Away
Notice 0014 creates the immediate vulnerability-management deadline. Notice 0013 explains the broader direction.
The biggest takeaway is that Rev. 5 is not going to remain the long-term FedRAMP model. FedRAMP plans to stop accepting new Rev. 5 Certification requests in 2027, and the program has made clear that existing Rev. 5 Certifications will eventually transition as well.
In the past, providers could sometimes assume that a federal deadline would move. FedRAMP 20x has not followed that pattern. The program has been moving quickly and, so far, has largely met the timelines it has announced.
That means providers should not build their strategy around the assumption that Rev. 5 will remain available indefinitely or that implementation deadlines will automatically slip.
Notice 0013 also changes how FedRAMP thinks about control parameters, additional guidance, and documentation. These changes are designed to reduce unnecessary divergence between commercial cloud practices and government-specific implementations.
Learn more: FedRAMP Rev. 5 or FedRAMP 20x: Which One Should You Pursue?
Providers Will Have More Flexibility—and More Responsibility
FedRAMP is removing most of its assigned control parameter values. Historically, many NIST controls included organization-defined values, and FedRAMP filled those values in for providers. These could include frequencies, thresholds, time periods, or other implementation details.
That approach created consistency, but it could also create strange outcomes. In some cases, a provider’s commercial security practice was stronger or more modern than the assigned FedRAMP value, yet the provider still had to align documentation and assessment activity to the federal parameter.
Spence described situations where providers were effectively pushed to meet the exact FedRAMP value even when their actual practice was more stringent. The new approach is intended to avoid that kind of compliance theater.
Providers will increasingly define their own values based on how their systems actually operate. That does not mean they can choose whatever is easiest. It means they need to make a defensible decision, document it, implement it consistently, and show that it produces the intended security outcome.
FedRAMP is also removing most of the additional control guidance that historically embedded government-specific requirements inside individual controls. Unique FedRAMP obligations will increasingly move into explicit rules that apply across the certification model.
The goal is to make those requirements easier to find and reduce the tendency to build a separate government-only operating model simply because federal guidance was written differently from commercial practice.
The Security Decision Record Introduces a New Documentation Model
Notice 0013 also gives providers more direction on what the certification package will look like.
The Certification Package Overview will replace much of the traditional System Security Plan and summarize the service and its boundary. The Secure Configuration Guide will replace the traditional Control Implementation Summary or Customer Responsibility Matrix and explain how customers need to configure and use the service securely.
The Security Decision Record, or SDR, is the most interesting new artifact. It is intended to explain the provider’s security decisions, how requirements are implemented, and why those decisions make sense for the system and its customers.
Sam described it as a way for providers to communicate their risk and security philosophy rather than producing a massive SSP filled with repetitive control statements that nobody wants to read.
Spence agreed with the intent but raised an important concern about how the SDR currently combines implementation, verification, and validation.
Traditional compliance models usually separate those functions. The provider documents what it does, and an independent assessor evaluates whether the implementation is appropriate and operating as described. The emerging SDR model appears to ask the provider to explain not only what it is doing, but also how the implementation has been verified and validated.
That could create a stronger and more complete record of the provider’s security decisions. It could also create a significant documentation burden if teams interpret validation as requiring large volumes of screenshots and point-in-time evidence inside the SDR itself.
The model is still evolving, and both Sam and Spence expect FedRAMP to refine it as more mature systems move through the process. The underlying direction, however, is clear: documentation is shifting away from static templates and toward a maintained record of security decisions, supporting rationale, and operational proof.
Rev. 5 or 20x Depends on How the Provider Operates Today
For providers deciding between Rev. 5 and 20x, the right answer depends heavily on architecture and operating maturity.
Organizations with older environments, highly manual production access, limited automation, and traditional change processes may face a significant engineering lift under 20x. Those providers may still have a reason to pursue Rev. 5 while the window remains open, particularly if they already have an agency sponsor or substantial investment in the process.
But Rev. 5 should not be treated as a way to avoid modernization. VDR and VER are already becoming mandatory, and broader transition requirements are coming. A provider that chooses Rev. 5 still needs to think about the automation, architecture, and continuous reporting expectations that will follow.
For cloud-native providers with modern architectures, infrastructure as code, controlled access, automated evidence, and mature vulnerability processes, 20x may align much more naturally with how the service already operates.
As Spence put it, 20x is a far better fit for providers that have already done the hard work of modernizing their environments. It also reduces the burden on agency customers. Instead of sponsoring and reviewing a large traditional package, agencies can access the provider’s trust center and evaluate the security information being reported.
The decision should therefore be based not only on which path looks easier today, but also on how much technical debt each path creates for the transition that is already coming.
Learn more: FedRAMP Rev. 5 or FedRAMP 20x: Which One Should You Pursue?
What Existing Rev. 5 Providers Should Do Now
For existing Rev. 5 providers, the most immediate priority is VDR and VER readiness.
Providers should begin by comparing their current vulnerability-management process against the new requirements. They need to understand whether asset and vulnerability data can be connected to exposure, internet reachability, exploitability, KEV status, system context, and potential agency impact.
They should also look closely at where the current process still depends on monthly scans, spreadsheets, manual POA&M work, or delayed risk decisions. Teams need clear ownership for evaluation, mitigation, remediation, escalation, reporting, and customer communication.
Sam’s advice was straightforward: if a provider does not yet have the automation around vulnerability management, that is the first thing to address. The December deadline is close enough that waiting several more months will create a serious implementation risk.
Beyond VDR and VER, providers need a broader modernization plan. Rev. 5 will not remain the permanent model, and organizations that want to continue serving the wider federal market will need modern architecture, better automation, and the ability to support continuous validation.
The Bottom Line
BOD 26-04 changes how the federal government prioritizes vulnerabilities by focusing on exposure, known exploitation, automation, and technical impact. Notice 0014 brings that model into FedRAMP and creates an accelerated deadline for VDR and VER. Notice 0013 confirms that Rev. 5 is already transitioning toward the more flexible, automated, and continuously validated model behind FedRAMP 20x.
The first major deadline is December 7, 2026, but the work required to meet it starts well before then. Providers need time to connect data, redesign workflows, assign ownership, test the process, and make sure their vulnerability-management program can make risk decisions quickly enough to matter.
For Rev. 5 providers, the question is no longer whether vulnerability management and FedRAMP reporting will change. It is whether the organization can make that change in time.
Not sure how these updates affect your current FedRAMP program?
38North Security can help you evaluate VDR and VER readiness, identify automation and architecture gaps, and determine the right transition path for your cloud service.
Talk to our team about preparing for the new FedRAMP requirements: https://38northsecurity.com/contact/
About the Authors
