Stop Treating VDR/VER as a Scanner Reconfiguration Project

The Conventional Approach

Many providers view the VDR/VER migration as a simple vulnerability management upgrade. They plan to adjust the scanner, update CVE/CVSS-to-SLA mappings, revise SOPs, tweak POA&M processes, and ensure reports are generated on a new schedule. The goal is to complete this by December 7, 2026. This approach seems logical since FedRAMP mandates that Vulnerability Detection and Response and Vulnerability Evaluation and Reporting rulesets apply to every FedRAMP Certified cloud service.

Why This Approach Falls Short

Treating this migration as a mere upgrade misses the broader requirements. Three key expectations from the program don't align with this view.

First, the focus isn't just on scoring hygiene. CISA's Binding Operational Directive 26-04 aims to move away from CVE/CVSS score-based prioritization with extended response windows. The directive highlights the threat of AI-enabled attackers shortening the gap between patch release and exploitation. FedRAMP's deadlines align with this directive, emphasizing risk-based prioritization that considers context, reachability, and mitigation. Simply shortening response times without changing the prioritization model won't suffice.

Second, reporting must be machine-readable. VER-RPT-PER (Persistent Reporting) requires a machine-readable activity report, while VER-TFR-MHR (Monthly Activity Report) covers the human-readable aspect. If your reporting is manually compiled in spreadsheets, you're facing a pipeline issue, not just a policy one.

Third, FedRAMP has indicated this is the first of several migrations. Annual paperwork exercises are no longer enough, and automated assurance expectations will continue to evolve. A one-time project won't meet these ongoing obligations.

Evidence of the Shift

The migration progress report requirements highlight FedRAMP's expectations:

• Providers must report the implementation status for each VDR/VER rule, with explanations and a Corrective Action Plan for any unimplemented rules, delivered as a VDR/VER Mini-Security Decision Record (Mini-SDR).
• A sample machine-readable activity report under VER-RPT-PER, with at least five vulnerabilities of each type.
• A sample human-readable activity report under VER-TFR-MHR, with at least five vulnerabilities of each type.

Notably absent are scan exports, patch counts, or SLA charts. The samples should use example entries for vulnerabilities likely to be exploited, indicating that FedRAMP is testing your reporting capability, not your current exposure.

The Mini-SDR can be in CSV or JSON, supporting both manual and automated generation. However, it's temporary until you transition to full Security Decision Record rules. Building it manually now means rebuilding later.

Consequences are tied to dates, not scores:

• If not fully migrated by December 7, 2026, you must explain corrective actions per rule with timelines.
• Planning to finish after February 3, 2027, puts you in remediation, marking your Marketplace entry as "FedRAMP Certified (In Remediation)."
• Without full migration or an approved Corrective Action Plan by March 8, 2027, certification is revoked, and you're banned from FedRAMP for a year.
• Extended grace beyond March 7, 2027, requires an approved plan and a FedRAMP-coordinated red team assessment.

Consider a provider treating the migration as a scanner project. They adjust priorities and timelines, only to find in November that their reporting can't produce structured output. They arrive at the December test with an unexpected Corrective Action Plan. This scenario illustrates the pitfalls of viewing this as mere tool tuning.

What to Do Instead

Approach this as a data and engineering project with a policy component.

1. Start with the Report, Not the Scanner. Define the machine-readable output first, then work backward to gather the necessary data. Use FedRAMP's Mini-SDR formats and the VDR/VER Migration Resources site as your guide.
2. Prioritize Risk Context. Capture reachability, exploitability, and mitigation status as data fields, not analyst notes, to ensure prioritization doesn't default to CVSS.
3. Develop Corrective Action Plans per Rule. Provide rule-by-rule explanations with timelines. A single global plan won't meet the required detail. If a rule won't be ready by December 7, specify a defensible date.
4. Plan for the February 3 Threshold. Anything completed after this date triggers the In Remediation status. Identify which rules could cause this and decide early if they need to be prioritized.
5. Budget for Continuous Change. FedRAMP expects ongoing operational improvements. Allocate resources for a continuous capability, not just a one-time project.
6. Monitor Updates. Requirements may change until the Emergency Test notification in early December. Follow the migration site's RSS feed or public repository for updates.

When the Conventional Approach Works

If your team already produces structured vulnerability data, considers reachability in remediation, and runs a mature vulnerability management program, the migration may be closer to a mapping exercise. Validate output formats, but extensive rebuilding may not be necessary.

Small providers without automation can use the CSV Mini-SDR path; FedRAMP supports this for the current reporting cycle. A manual approach can meet the migration report requirements but isn't a sustainable long-term model given future Certification Data Sharing rules.

Agency-provided offerings are exempt from VDR/VER rules and follow CIO and CISO guidance under BOD 26-04. If this applies to you, these steps aren't necessary.

The deadline is December 7, 2026. Your approach depends on whether you're tuning a tool or building a lasting capability.