What is the difference between VDR and VER?

VER stands for Vulnerability Evaluation and Reporting. It contains the evaluation and reporting rules that were carved out of VDR into a separate ruleset when FedRAMP published its Consolidated Rules for 2026. VER covers contextual evaluation, the PAIN impact ratings, accepted vulnerabilities, and the structured reporting format. In short: VDR is the detect-and-respond lifecycle, VER is how you rate and report what you find.

Are the 30, 90, and 180-day remediation windows going away?

Yes. Under VDR/VER, findings are no longer prioritized by CVSS severity with flat 30/90/180-day deadlines. Priority now depends on the affected asset’s potential impact to the agency, whether the vulnerability is exploitable, and whether the asset is reachable from the internet. A high-CVSS finding on an isolated, non-exploitable asset can rank below a lower-CVSS finding that is internet-reachable and actively exploited.

What is the 192-day rule?

Any vulnerability that is not, or will not be, fully mitigated or remediated within 192 days of evaluation must be categorized as an accepted vulnerability. That record has to include the vulnerability’s internet-reachable (IRV) and likely-exploitable (LEV) status, its current PAIN rating, and the documented reason for acceptance. It is a hard cutoff, not a rolling extension.

How does OscalIQ help with VDR and VER?

OscalIQ evaluates each POA&M item the VDR way instead of by CVSS: it checks whether the vulnerability is likely exploited by cross-referencing the CISA Known Exploited Vulnerabilities (KEV) catalog, whether the affected asset is internet-reachable using your FedRAMP inventory, and factors in the system’s impact level - producing a contextual priority. It tracks the 192-day acceptance clock per finding and flags items that are overdue for an acceptance decision. And because OscalIQ is OSCAL-native, its records are structured and schema-shaped from the start, not monthly scan spreadsheets.

FedRAMP VDR & VER: The End of CVSS Scanning

Q: What is FedRAMP VDR?

VDR stands for Vulnerability Detection and Response. It is FedRAMP’s replacement for the legacy RA-5 scan-and-remediate model. VDR covers how a cloud service provider detects vulnerabilities, how often it verifies its resources, and how quickly it mitigates or remediates them. Detection is defined broadly - assessment, scanning, threat intelligence, vulnerability disclosure programs, bug bounties, penetration testing, incident response, automated control testing, and supply chain monitoring - and is explicitly not limited to traditional scanning. It began as RFC-0012 in August 2025, became the FedRAMP 20x VDR process in late 2025, and ran as a Rev5 Open Beta from February to May 2026.

Executive summary. FedRAMP is replacing the vulnerability model that most authorization packages are still built on. The legacy RA-5 approach - scan on a schedule, sort by CVSS, remediate inside flat 30/90/180-day windows, and report it in a monthly spreadsheet - is giving way to VDR (Vulnerability Detection and Response) and VER (Vulnerability Evaluation and Reporting). Under the new model, a finding’s priority is driven by whether it is exploitable, whether the affected asset is reachable from the internet, and what its potential impact to the agency is - not by a raw CVSS score. Records must be structured and valid against FedRAMP’s published schemas. If your RA-5 narratives and POA&M still read like a Nessus export, this is the shift to plan for now.

Where VDR and VER came from

VDR started life as RFC-0012 in August 2025, became the FedRAMP 20x VDR process in late 2025, and then ran as a Rev5 Open Beta from February to May 2026. When FedRAMP published its Consolidated Rules for 2026, the evaluation and reporting portions were split out into a separate ruleset for convenience - and that ruleset is VER. So the two are halves of one model: VDR is the detect-and-respond lifecycle, VER is how you rate and report what you find.

Crucially, VDR defines detection broadly. It is explicitly not limited to traditional scanning. Assessment, scanning, threat intelligence, vulnerability disclosure mechanisms, bug bounties, penetration testing, incident response, automated control testing, and supply chain monitoring all count as detection. The old mental model - “RA-5 means we run authenticated scans every 30 days” - is exactly what is being retired.

What actually changes

1. Priority is contextual, not CVSS

This is the headline change. Findings are no longer prioritized by CVSS severity with fixed remediation windows. Priority now depends on three things:

the affected asset’s potential impact to the agency,
whether the vulnerability is exploitable - the Likely Exploitable (LEV) question, and
whether the asset is reachable from the internet - the Internet Reachable (IRV) question.

New to these terms? Our FedRAMP acronyms glossary defines IRV, LEV, PAIN, KEV and the rest of the new FedRAMP 20x vocabulary in one place.

The practical effect: a CVSS 9.8 on an internal, non-exploitable component can rank below a CVSS 6 that is internet-facing and on CISA’s Known Exploited Vulnerabilities list. The PAIN impact rating in VER is how that context gets expressed. Teams that have spent years chasing every “critical” to hit a 30-day clock will need to re-learn what “critical” means.

2. Mitigation can count, not just full remediation

Under the legacy model, the clock only stopped on full remediation. VDR recognizes mitigation: a provider may mitigate a vulnerability until it is no longer automatable or no longer internet-reachable, and at that point full remediation is not required. That rewards putting a compensating control in front of a weakness - a WAF rule, network isolation, an access restriction - as a legitimate outcome rather than a placeholder note in a POA&M.

3. Accepted risk has a hard 192-day cutoff

Any vulnerability that is not, or will not be, fully mitigated or remediated within 192 days of evaluation must be categorized as an accepted vulnerability. And that acceptance is not a one-line note: it has to document the finding’s IRV and LEV status, its current PAIN rating, and the reason for acceptance. There is no rolling extension - once you cross 192 days, the finding is either resolved or it is a formally accepted, fully-documented risk.

4. Reporting is structured, not spreadsheets

Finally, records must be structured and valid against FedRAMP’s published schemas, rather than delivered as monthly scan spreadsheets. This is the quiet requirement that trips up the most teams, because it means your tooling has to emit machine-validated records - not a workbook that a human reformats each month.

What this means for your RA-5 narratives

If your current System Security Plan describes vulnerability management as periodic scanning plus CVSS-tiered remediation timelines, those narratives are written against the model that is going away. You do not need to panic - the underlying obligation to find and fix vulnerabilities has not changed - but you do need to be able to answer three new questions for every finding: Is it exploitable? Is it internet-reachable? What is its impact if it is? And you need to answer them in a form a machine can validate.

How OscalIQ helps

OscalIQ is an OSCAL-native FedRAMP compliance platform, and it now evaluates vulnerabilities the VDR/VER way. Instead of sorting your POA&M by CVSS, OscalIQ scores each item on the axes the new model actually cares about:

Likely Exploitable (LEV). OscalIQ cross-references each finding’s CVEs against the CISA Known Exploited Vulnerabilities (KEV) catalog - the authoritative signal that a weakness is being exploited in the wild - and can factor in EPSS exploit-prediction scores.
Internet Reachable (IRV). OscalIQ reads whether the affected asset is public directly from your FedRAMP integrated inventory, so reachability is derived from your own system of record rather than guessed.
Contextual priority. It combines exploitability and reachability with the system’s impact level to produce a contextual priority - the VER PAIN-style rating - instead of a bare CVSS number.
The 192-day clock, tracked automatically. OscalIQ records the evaluation date on each finding, computes the 192-day acceptance deadline, and flags items that are overdue for a mitigation, remediation, or a formal acceptance decision - before an assessor does.
Structured, schema-shaped records. Because OscalIQ is OSCAL-native, your POA&M has always been structured data, not a spreadsheet - which is exactly the direction VER reporting is headed.

The result is a POA&M you can actually defend under the new rules: every item carries its exploitability and reachability status, a context-driven priority, and a clear acceptance deadline, all in a structured format. That is the difference between reformatting a scan export every month and running a real Vulnerability Detection and Response program.

What to do now

Inventory your reachability. Make sure your integrated inventory accurately marks which assets are internet-facing - IRV depends on it.
Wire in exploitability. Start tagging findings against CISA KEV today; it is the single strongest exploitability signal and it is free.
Re-read your RA-5 narratives. If they describe CVSS-tiered windows, mark them for revision toward contextual VDR language.
Fix your reporting format. Move off spreadsheets toward structured, schema-valid records now, so the transition is a switch and not a rebuild.

VDR and VER are not a tweak to RA-5 - they are a different way of thinking about risk, closer to how attackers actually pick targets. The providers who adapt early will spend less effort chasing non-exploitable “criticals” and more on the vulnerabilities that genuinely matter. If you want to see your POA&M evaluated the VDR way, get in touch and we will walk you through OscalIQ.