FedRAMP just published its first Vulnerability Detection and Response (VDR) standard, release 25.09A, and a lot of CSPs are asking, “Do we need to retool our ConMon now?” Short answer: not yet for most Rev5 providers. Below is a clear rundown of what changed, who it applies to, and the timelines so you can plan without scrambling.
FedRAMP's new VDR at a Glance
What is it? A single, outcome-oriented standard for how CSPs find, evaluate, prioritize, and fix vulnerabilities, as well as how they report that work to agencies. It aims to replace the patchwork of scanner– centric rules, Plan of Actions & Milestones (POA&M) gymnastics, and uneven reporting with a more modern, automated approach that reflects how mature cloud programs already operate.
VDR shifts attention from “did you scan on time and file paperwork” to “did you meaningfully reduce risk, quickly, and prove it.” FedRAMP also signals future machine– readable authorization data and comparative scoring across providers.
Here is the Timeline for CSPs
FedRAMP 20x pilots
- Effective on September 15, 2025 for all 20x efforts.
- Phase One Pilot – You’ll have up to one year after authorization to fully implement VDR, with quarterly progress expected.
- Phase Two Pilot – You need to show significant progress before authorization.
So, the bottom line, if you’re in 20x the VDR is in scope right away. Plan and show progress, not perfection on day one.
FedRAMP Rev5 CSOs
- Earliest touchpoint is October 8, 2025 for R5.VDR.B1, tentative.
- This is Closed Beta only, so you must enroll and be approved by FedRAMP before changing anything about your current Rev 5 ConMon.
- FedRAMP is aiming for FY26 Q2 to open the beta more broadly, with optional wider release possibly in FY26 Q3-Q4 (theoretically there would be an allotted one year transition period).
So, in plain English – if you’re a Rev5 CSP not in the VDR Closed Beta, you do not need to change your current program.
You may opt in to the VDR Closed Beta but need approval from FedRAMP before stopping any current Continuous Monitoring processes. Otherwise, continue with your existing processes and keep up to date on the VDR standard.
Here's the new VDR Requirement
The VDR standard asks providers to run a continuous vulnerability program that is:
- Automated and persistent. Scanners, threat intel, disclosure, bug bounty programs, supply chain signals, and other capabilities should all be utilized.
- Risk driven. You evaluate each finding in context: criticality of affected assets, Internet reachability, likely exploitability, detectability by a threat actor, prevalence of CSO affected, privilege gained from exploitation, how can known threats leverage the vulnerability, and interactions with other vulnerabilities.
- Outcome-oriented. You’re measured on how fast you reduce potential adverse impact, especially for Internet-reachable and likely exploitable vulnerabilities.
- Transparent to agencies. Regular reporting, human-readable summaries, and machine-readable data for automation. Share enough for agencies to make risk decisions without leaking exploitation details.
There are timeframe tiers for Low, Moderate, and High authorizations. The higher the authorization level, the faster you evaluate and reduce risk. For example, at Moderate, providers are guided to:
- Evaluate exploitability and reachability of all new vulnerabilities within five days of detection.
- Estimate the impact using potential impact ratings of N1-N5 where N1 is negligible adverse effects and N5 is catastrophic adverse effects.
- Treat Internet-reachable, likely exploitable N4/N5 findings as security incidents until reduced to N3 or below.
- Generate and provide historical and current vulnerability data in a machine-readable format with updates provided at least every 14 days.
At High, expectations tighten further, including daily to weekly detection cadences and two day evaluation windows.
"Internet-reachable" is the new North Star
VDR emphasizes Internet-reachable rather than only “Internet-accessible.” If a payload from the Internet can be relayed into your stack and trigger a vulnerable component, even behind a load balancer or private network, it counts. Think of SQL injection or a Log4Shell vulnerability. While the affected asset might be behind several components within the system, the payload could still reach the affected asset. The cleanest fix is often payload interception and sanitization before the vulnerable component processes it.
This emphasis directly echoes what we outlined in our earlier analysis of RFC-0012, which highlighted Internet-reachable resources as the first line of exposure. The new VDR standard cements that priority into formal policy.
VDR & Rev5 Continuous Monitoring
Once a CSP is approved to adopt VDR for their CSO, FedRAMP indicates that older vulnerability related requirements and POA&M heavy processes are superseded. Until then, your current Rev5 Continuous Monitoring (ConMon) and POA&M processes remain authoritative. Agencies will continue to rely on your existing package unless and until VDR is formally in scope for your CSO.
At that point, CSPs will be expected to hit the ground running by adjusting to several concepts:
- All vulnerabilities will need to be evaluated for exploitability and Internet reachability, rather than simply running scans, taking the data provided, and plugging such data into a POA&M.
- Prioritizing remediation based on CVSS values will be largely replaced by prioritizing potential adverse impact ratings of N1-N5. CVSS could play a part in determining the N value, but it will no longer be the only factor.
- Countless POA&M columns will be replaced with several key indicators such as: internal tracking identifier, time and source of detection, time of completed evaluation, Internet reachability, exploitability, potential adverse impact rating details, and a few other indicators.
- Potentially accelerated timelines on detection, triaging, and response/remediation with adjustments to these timelines based on CSO authorization level.
- All VDR operations evaluated and scored by FedRAMP to inform agencies as to how effective the CSP’s processes are on continuously identifying, analyzing, prioritizing, mitigating, and remediating vulnerabilities.
Practical timelines and decisions
Here’s how we’re advising clients to think about the calendar:
Now – Q4 CY2025
- 20x pilots: Socialize VDR internally, map your current vulnerability lifecycle to VDR requirements, and start instrumenting persistent evaluation and reporting. Show quarterly progress.
- Rev 5 CSPs not in Closed Beta: No immediate changes. Track the standard, identify quick wins you can adopt without disrupting ConMon. For example, tagging internet-reachable and likely exploitable findings and capturing potential adverse impact ratings.
FY26 Q2
- FedRAMP intends to open Rev 5 VDR to a wider Open Beta. Decide whether optional early adoption makes sense for your program maturity and customer needs.
FY26 Q3–Q4
- Potential optional wide release for Rev 5. This could be the moment many CSPs plan a controlled cutover from legacy vulnerability workflows to a VDR aligned model. However, there is precedent (though not confirmed) for FedRAMP to provide a 1 year transition period, per 20X Pilot processes.
What’s the key takeaway? Rev 5 CSPs do not need to worry yet unless you choose to opt in. There’s strategic value in preparing now so the eventual transition is smooth, but you can do that without rewriting your ConMon this quarter.
What to do next
If you’re early stage on ConMon
- Inventory and classify externally reachable surfaces and proxy paths to internal services.
- Tag findings with internet– reachability, likely exploitability, and a simple adverse impact scale.
- Tighten SLAs for anything that is both internet– reachable and likely exploitable.
If you’re mid maturity
- Add automated context: ingress route mapping, exploit intelligence, and asset criticality signals.
- Produce a monthly human-readable rollup plus a machine-readable feed updated at least every 14-30 days depending on impact level.
- Pilot payload interception patterns for known classes of bugs in front of sensitive components.
If you’re advanced
- Implement event driven sampling on newly built or materially changed resources.
- Track and display time to impact reduction metrics, not just time– to– patch.
- Prepare a clean cutover plan that swaps POA&M-heavy mechanics for VDR reporting once FedRAMP greenlights your adoption.
Quick FAQ
Do we need to change our Rev 5 ConMon right now?
No. Unless you are approved for the Rev 5 VDR Closed Beta, keep your current program. Track VDR, pilot nondisruptive improvements, and be ready for Open Beta in FY26 Q2.
Will agencies expect new reports immediately?
Not for standard Rev 5 authorizations outside the Closed Beta. Agencies will continue using your existing package until VDR is formally in scope for your service.
Is VDR just “scan faster”?
No. It’s about reducing risk faster, especially for internet-reachable, likely exploitable issues and proving it with consistent reporting and data.
What can Fortreum do for you?
If you’d like, we can schedule a short working session to translate this into your roadmap and help you decide whether to target Open Beta adoption in FY26 or wait for general availability. In the meantime, you’re safe to continue with Rev 5 ConMon as is and make incremental improvements that align with FedRAMP’s new VDR direction.
For a deeper dive into how these changes build on FedRAMP’s earlier RFC-0012 proposal, including grouping logic and contextual risk scoring, you can revisit our previous blog here.
For more information, visit the Fortreum website or follow the company on LinkedIn at LinkedIn.com/company/fortreum.
Should you have questions about your FedRAMP, XRAMP, cloud and cybersecurity readiness, please reach out to us at Info@fortreum.com or Contact Us at https://fortreum.com/contact/
