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 Rev 5 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, 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.
Who must care now? Who can safely wait?
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 Rev 5 (most current CSPs)
- 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
So, in plain English – if you’re a Rev 5 CSP not in the VDR Closed Beta, you do not need to change your current program. Keep doing Rev 5 ConMon. Track VDR, but you’re not on the hook yet unless you opt in.
What's actually inside VDR?
VDR asks providers to run a continuous vulnerability program that is:
- Automated and persistent – scanners plus threat intel, disclosure, bug bounty, supply chain signals; not one tool or one pattern.
- Risk driven. You evaluate each finding in context: reachability from the internet, likely exploitability, blast radius, privilege gained, prevalence, detectability, and interactions with other weaknesses.
- Outcome-oriented. You’re measured on how fast you reduce potential adverse impact, especially for internet-reachable and likely exploitable issues.
- 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 impact level, the faster you evaluate and reduce risk. For example, at Moderate, providers are guided to:
- Evaluate all new vulnerabilities within five days of detection.
- Treat internet-reachable, likely exploitable N4/N5 findings as security incidents until reduced to N3 or below.
- Make recent vulnerability program history machine-readable and refreshed 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 SQL injection or a Log4Shell style code path. 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.
How VDR interacts with POA&Ms and current controls
Once a CSP is approved to adopt VDR for their offering, FedRAMP indicates that older vulnerability – related requirements and POA&M – heavy processes are superseded. Until then, your current Rev 5 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 service.
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.
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://fortreumstage.wpenginepowered.com/contact/