By Mario Lunato, Knox Field CISO, and Chris Hughes, Resilient Cyber
On June 10, 2026, CISA released Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk." It tells federal civilian agencies to stop treating every vulnerability on the same flat clock and to prioritize instead by public exposure, Known Exploited Vulnerability status, exploit automatability, and technical impact. One of us wrote a comprehensive blog post on the topic, breaking it down, and also was advocating for this approach several years ago, in a book titled “Effective Vulnerability Management”.
Six days after CISA’s BOD, on June 16, FedRAMP responded with Public Notice NTC-0014.
The notice did something FedRAMP had previously promised to do slowly and gently. It pulled the mandatory adoption of its new Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) rules forward to December 7, 2026, and it put every Rev5 Certified cloud service on notice that the legacy monthly scanning process is, in FedRAMP's own words, insufficient. There’s no doubt that part of the sense of urgency is being driven by AI-driven vulnerability discovery, and the broader “Vulnpocalypse” narrative.
For most cloud service providers in the FedRAMP marketplace, this is the single largest operational change to continuous monitoring since the program started. The monthly authenticated scan, the CVSS-ranked POA&M, the 30/90/180-day clock measured from scan time, all of it is being replaced by a continuous, exposure-and-threat-based loop that runs at the speed of the threat rather than the speed of the reviewer.
And the timeline is not negotiable anymore.
The Monthly Scan Was Always a Snapshot of a Moving Target
The model that has governed FedRAMP continuous monitoring for a decade is conceptually simple but structurally broken and insufficient. A provider runs authenticated vulnerability scans across the boundary once a month, exports the findings, maps them into a Plan of Action and Milestones (POA&M), and ships the package to agency reviewers. CVSS severity-based prioritization occurs, such as High findings get 30 days, moderate findings get 90, low findings get 180. The clock starts at scan time and the severity comes from a CVSS base score. It’s worth noting that a similar approach has long been the standard for vulnerability management in Federal systems as well, under NIST’s RMF.
The problem is that every part of that sentence describes a point in time, and threats do not operate in points of time. A monthly scan tells you the state of the boundary on the day it ran. It says nothing about the twenty-nine days in between, when an image drifted, a dependency shipped a new CVE, or an internet-reachable service started processing a payload it should have rejected. The cadence was built around the convenience of the reviewer, not the behavior of the adversary.
Orienting around CVSS base severity scores makes it worse. A base score measures theoretical badness in the abstract, divorced from whether the vulnerable code is reachable, whether an exploit exists, and whether anyone is actually using it in the wild. Most criticals a scanner surfaces are not exploitable in the context of the deployment. Meanwhile a "medium" buried deep in an application stack can be the one that gets you, as Log4Shell demonstrated to everyone in 2021. The industry has known this for years. KEV and EPSS exist precisely because severity-by-CVSS does not survive contact with operational reality.
Adding another layer of complexity to the situation is that the latest frontier models have been shown to be able to chain multiple low and moderate vulnerabilities together to still have a significant impact on production systems.
FedRAMP is now saying the quiet part out loud, which is that the monthly scan was never continuous monitoring, it was a recurring snapshot dressed up as one, and a broader part of the security theater most of our industry participates in.
What VDR and VER Actually Are
VDR and VER are FedRAMP's replacement for that whole apparatus, and they split the lifecycle into two rulesets that do different jobs.
Vulnerability Detection and Response is the detection-and-action half. Its two anchor rules read like a thesis statement for the entire pivot. VDR-CSO-DET requires that providers "systematically, persistently, and promptly discover and identify vulnerabilities" using whatever techniques actually find them: scanning, yes, but also threat intelligence, vulnerability disclosure programs, bug bounties, and supply-chain monitoring. VDR-CSO-RES is the mirror, providers must "systematically, persistently, and promptly track, evaluate, monitor, mitigate, remediate, assess exploitation of, report, and otherwise manage all detected vulnerabilities." The operative word in both, repeated deliberately, is persistently. Detection is no longer an event you schedule, it is a property of the system that has to hold continuously.
Vulnerability Evaluation and Reporting is the half that decides what a vulnerability means and tells the government about it. This is where the risk model lives. Under VER-EVA-ELX, providers must evaluate whether a detected vulnerability is a likely exploitable vulnerability. Under VER-EVA-EIR, they must evaluate whether it is internet-reachable, a deliberately broader test than internet-accessible, because the standard is whether a service might receive a payload from the Internet at all, even indirectly through a load balancer and three hops of private network. Under VER-EVA-EPA, providers assign a Potential Agency Impact rating, a five-level scale from N1 (minimal customer effect) to N5 (debilitating effect across more than one agency). And under VER-EVA-AIA, the new "Assume It's Automatable" rule, providers must assume an exploit can be automated unless they have evidence proving otherwise. It is worth calling out that this still allows for the provider to arbitrarily set the impact rating for the agency, but it is a step in the right direction nonetheless.
The reporting rules close the loop. VER-RPT-PER makes vulnerability reporting persistent and treats those reports as Certification Data subject to FedRAMP's data-sharing rules. VER-RPT-VDT specifies eleven fields per vulnerability, including the provider's internal tracking identifier, time and source of detection, current and historical impact ratings, the next planned reduction in impact, and a flag for whether the item is or is likely to become an overdue vulnerability. That last field is indicative of course in terms of ongoing risks and exposure. The system is built to expose its own backlog in machine-readable form, ideally alleviating a lot of the pain of rationalizing the swatch of data that will be received, ingested, normalized etc. to provide a coherent picture of risk across CSPs for the Federal government.
This is detection, evaluation, response, and reporting rebuilt as a continuous loop instead of a monthly ritual that’s performative in nature but does little to actually manage or reduce organizational risks.
The Pivot From Severity to Exposure
The conceptual shift underneath all of this is a move from base score severity-based prioritization to exposure-and-threat-based prioritization, and it is the most important thing for a provider to internalize and adapt towards.
The old question was "how bad is this CVE in theory." The new question is a stack of operational ones, such as:
- Is it likely exploitable?
- Is it reachable from the internet?
- How automatable is the exploit?
- What would exploitation actually do to an agency that depends on this service?
FedRAMP even publishes the factors it expects providers to weigh in VER-EVA-EFA, which include: criticality, reachability, exploitability, detectability, prevalence, privilege, proximate vulnerabilities, and known threats.
None of those is a CVSS base score.
This is the same intellectual lineage as CISA's KEV catalog and FIRST's EPSS, and as MITRE and CMU's SEI work on Stakeholder-Specific Vulnerability Categorization.
It is also the model the exposure-management vendors have been selling for years, as vulnerability management evolved into Continuous Threat and Exposure Management (CTEM). Tenable, which originated the exposure-management category, has argued the position publicly, and so have the cloud-native players like Wiz that built reachability analysis into their platforms among others such as Zafran and Endor Labs. The difference is that FedRAMP is no longer treating risk-based prioritization as a nice-to-have a mature provider might adopt. It is becoming the floor for handling vulnerabilities associated with cloud services in the U.S. Federal government that are authorized under FedRAMP.
There is a hard edge to the new model that providers should not miss as well. VER-TFR-MAV says any vulnerability not fully mitigated or remediated within 192 days of evaluation must be categorized as an accepted vulnerability, with a written explanation of why. We personally think that timeline is fairly extensive, especially given how quickly exploitation is happening based on metrics from reports such as the 2026 DBIR, but there are some positives as well. For example, forcing the written risk acceptance will lead to many providers opting to remediate the risks rather than just kicking them down the road indefinitely.
The evaluation clock itself is also tight, where VER-TFR-EVU expects a Class C provider to evaluate every detected vulnerability within five days of detection, and a Class D provider within two. The remediation windows that follow scale by impact, reachability, and exploitability rather than by a flat 30/90/180 schedule, so an internet-reachable, likely-exploitable, high-impact finding gets days, not months.
Severity told you how loud the alarm was, but exposure tells you whether the door is actually open.
BOD 26-04 Is the Forcing Function
None of this would carry a December 2026 deadline without CISA. BOD 26-04 is the most aggressive federal vulnerability directive in the program's history, and it is what gives FedRAMP both the cover and the mandate to move. It’s also long overdue, as we have been advocating for true risk-based prioritization in industry for years, but better late than never.
The directive throws out the flat timelines of its predecessors and replaces them with a four-variable risk model. The variables are binary, including:
- Is the asset publicly exposed
- Is the CVE in CISA's Known Exploited Vulnerabilities catalog
- Can an adversary automate the full exploit
- Does exploitation yield total or only partial control of the system.
Those four binaries produce a sixteen-tier remediation matrix in Appendix A.
The worst combination, a KEV that grants total control, requires remediation within three days plus mandatory forensic triage to determine whether the system has already been compromised. Lower-risk combinations get fourteen days or sixty, and the combination that meets none of the criteria can be deferred to the next system upgrade cycle. CISA publishes the answers for three of the four variables through its Vulnrichment program, and agencies determine public exposure themselves. We also want to highlight that there are challenges here too, such as the fact that CISA’s Vulnrichment program only provides SSVC coverage for 45.8% of CVE’s, as highlighted in blog by VulnCheck, which leaves a lot of the work up to the providers and agencies to sort through.
The directive revokes and replaces both BOD 22-01, the 2021 directive that created the KEV catalog and assigned flat remediation deadlines, and BOD 19-02 from 2019. The methodology now draws on CISA's Stakeholder-Specific Vulnerability Categorization rather than CVSS alone. This is the federal government formally retiring "patch everything eventually" as a strategy.
Two forces drove the timing, and CISA named both in their publications.
The first is that traditional vulnerability management is losing. Citing the 2026 Verizon Data Breach Investigations Report, CISA noted that only 26 percent of KEV-listed vulnerabilities were fully remediated by organizations in 2025, down from 38 percent the year before, with the median time to fully resolve a vulnerability climbing to 43 days.
The second is artificial intelligence (AI). CISA stated plainly that AI is accelerating both the discovery and the weaponization of vulnerabilities, compressing the window between disclosure and exploitation.
"The legacy monthly vulnerability scanning process that most FedRAMP Rev5 Certified cloud services currently follow is insufficient." — FedRAMP, NTC-0014
When the nation's cyber defense agency tells civilian agencies to patch on a three-day clock for the worst cases, a cloud provider feeding those agencies cannot keep reporting once a month.
How FedRAMP Mapped Itself Onto the Directive
What makes NTC-0014 more than a deadline change is that FedRAMP did the alignment work in the open, mapping its rules onto the directive line by line.
VER-EVA-EIR, the internet-reachability evaluation, exceeds BOD 26-04's requirement to assess public exposure, because reachability is the broader and harder test. VER-EVA-ELX, exploitability, covers the directive's KEV-status and exploit-automation variables. VER-EVA-EFA's eight factors supplement the directive's impact assessment. The new VER-EVA-AIA rule, assume it's automatable, deliberately goes beyond the directive by flipping the default, where BOD 26-04 asks agencies to evaluate automatability, FedRAMP tells providers to presume it until proven otherwise, and VDR-TFR-KEV requires providers to remediate KEVs on CISA's published due dates, the same dates the directive runs on.
FedRAMP's own framing, confirmed with CISA, is that a provider following the VDR and VER rules "will meet or exceed the expectations for the protection of federal information required by BOD 26-04." That is the strategic move in this by FedRAMP, which is rather than bolt a second compliance regime onto providers, FedRAMP positioned its continuous-monitoring rewrite as the implementation vehicle for the directive for CSP’s. Under Director Pete Waterman, the program has consistently argued that 20x replaces spreadsheet-and-screenshot review with continuous automated validation. VDR and VER are that argument applied to one of the processes that most resisted it, vulnerability management.
The directive set the destination. FedRAMP drew the route its providers will take to get there.
The Timeline Just Collapsed
The part that should command attention in every provider's program-management meeting this quarter is how much the calendar moved.
VDR was not new. It was introduced in RFC-0012 in August 2025, released as a process for FedRAMP 20x in late 2025, and run as a Rev5 Open Beta from February through May of 2026. The original plan was gradual: mandatory adoption on June 1, 2027, with a grace period extending to January 1, 2028. Providers had every reason to believe they had until 2028 to fully transition.
BOD 26-04 erased that runway. NTC-0014 states that CISA "will not accept slow incremental adoption" of updated vulnerability methodologies, and that FedRAMP is required to align with CISA guidance on protecting federal information. So the new schedule is this: the VDR and VER rules become mandatory for all cloud service offerings obtaining or maintaining FedRAMP Certification on December 7, 2026. FedRAMP will provide a grace period through March 7, 2027, during which a non-compliant offering can maintain certification only under a corrective action plan, with notice to all of its agency customers. After March 7, certification will be revoked for any offering not following the rules.
That is roughly five months of preparation from the notice, and a hard revocation cliff three months after the deadline. The provider who reads this as a 2028 problem will spend 2027 explaining to agencies why their authorization is on a corrective action plan.
The runway did not shorten. It mostly disappeared.
What This Requires of Providers
The honest assessment is that VDR and VER are not a documentation change, they are a capability change, and the providers who treat them as a paperwork exercise will fail the transition.
Continuous detection has to be real. The cadence rules expect a Moderate-equivalent provider to be running sampled detection every few days and a High-equivalent provider daily, with drift detection on top of that. That is not a monthly Nessus job, it is instrumentation wired into the pipeline and the runtime as a compliance-as-code discipline. Detection, evaluation, and the eleven-field vulnerability record all have to emit continuously and in a consistent format, because under VER-RPT-PER those reports are now Certification Data, retrievable by agencies through an API rather than mailed monthly as a spreadsheet.
The harder lift is exposure tracking. The entire risk model assumes a provider knows, in close to real time, which of its assets are internet-reachable and what the blast radius of each one is. An asset that moves from internal to internet-reachable changes its remediation clock immediately under both the directive's logic and FedRAMP's. As Robert Huber put it, an organization that cannot maintain real-time visibility into which assets are internet-facing cannot comply with a dynamic, graduated model. You cannot prioritize by exposure if you cannot see your exposure, and most legacy continuous-monitoring programs were never built to see it.
There is also a quiet relief buried in the new model, and providers should claim it. CISA found that at one large civilian agency, only one percent of vulnerability instances landed in the three-day tier while more than sixty percent qualified for deferral. The point of risk-based prioritization is not to make everything urgent. It is to make the few things that are actually urgent impossible to miss, and to stop spending remediation capacity on findings that were never going to be exploited. The same logic that compresses the worst cases relaxes the rest. That is the bargain, and it is a better one than the flat schedule ever offered.
The monthly scan is over. The continuous loop is the requirement. And the providers who start building the detection, evaluation, and exposure plumbing this quarter are the ones who will still hold a certification in the spring.
_Horizontal_RGB.png)
