Skip to main content
Dark green background, "Weak Application Security Can Cost You Millions," 3 slanted images of fingers pointing to digital locks, and a "Learn the Basics" button
FedRAMP VDR/VER Compliance Checklist for December 7thFedRAMP Program
5 min readFor Cloud Service Providers (DoD/FedRAMP)

FedRAMP VDR/VER Compliance Checklist for December 7th

If you're maintaining a FedRAMP certified cloud service, you have six months to revamp your vulnerability management process. CISA's Binding Operational Directive 26-04 has moved FedRAMP's planned June 2027 migration timeline to a firm December 7, 2026 deadline. Monthly vulnerability scanning won't suffice anymore.

This checklist guides you through the necessary steps to comply with the new Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) rules. Each item includes the specific requirement identifier and what successful implementation looks like.

Checklist Overview

This checklist covers the mandatory VDR and VER requirements that replace your current FedRAMP Rev 5 vulnerability scanning process. You're moving from a schedule-based scanning model to an exposure and threat-based approach that evaluates internet-reachability, exploitability, and Known Exploited Vulnerability (KEV) status. If you don't complete this transition by December 7, 2026, you'll operate under a corrective action plan (with agency notification) until March 7, 2027. After that date, FedRAMP will revoke your certification.

Prerequisites

Before starting, confirm:

  • Access to your current FedRAMP continuous monitoring documentation
  • Identification of all internet-facing components in your boundary
  • A method to track KEV catalog updates from CISA
  • A change management process that can handle accelerated remediation timelines
  • Review of the Consolidated Rules for 2026 (final release expected end of June 2026)

Compliance Checklist

1. Implement VER-EVA-EIR (Evaluate Internet-Reachability)

Determine if each identified vulnerability is reachable over the internet. Don't just check if the component is internet-facing; assess if the specific vulnerable code path or service is accessible externally.

Success looks like: You maintain a current inventory of internet-reachable services and can map each vulnerability to a reachability determination within 24 hours of discovery. Your assessment includes network topology, firewall rules, and application-layer exposure.

2. Implement VER-EVA-ELX (Evaluate Exploitability)

Assess if vulnerabilities are likely exploitable by checking KEV status and evaluating exploit automation potential. This replaces the generic CVSS score approach.

Success looks like: You check every vulnerability against the CISA KEV catalog immediately upon discovery. For non-KEV vulnerabilities, document whether public exploits exist and whether exploitation requires user interaction or can be automated.

3. Apply VER-EVA-EFA (Evaluation Factors)

Consider supplementary factors beyond KEV status and automation, including technical impact, compensating controls, data sensitivity, and threat intelligence.

Success looks like: You maintain a documented evaluation framework that weighs multiple factors. Your assessment considers whether the vulnerable component processes Controlled Unclassified Information (CUI), whether defense-in-depth controls reduce exploit likelihood, and whether threat actors are actively targeting similar vulnerabilities in your sector.

4. Apply VER-EVA-AIA (Assume It's Automatable)

Assume exploits are automatable unless specific evidence proves manual exploitation is required.

Success looks like: Your vulnerability records show "automatable" as the default state. When marking a vulnerability as requiring manual exploitation, document the specific user interaction or complex preconditions that prevent automation.

5. Implement VDR-TFR-KEV (Remediate KEVs)

Remediate KEVs according to BOD 26-04 timelines unless valid technical reasons are documented. The directive's timelines are maximums; remediate faster when possible.

Success looks like: You track KEV remediation separately from other vulnerabilities. When unable to meet the timeline, document the technical constraint (not resource or scheduling issues) and implement compensating controls. Your tracking shows actual remediation times averaging well below the maximum allowed.

6. Implement VDR-CSO-RES (Vulnerability Response)

Maintain ongoing mitigation and remediation of vulnerabilities. You can mitigate a vulnerability (reducing its reachability or automatability) rather than fully remediating it, but you must document this decision.

Success looks like: You maintain a vulnerability response log showing mitigation and remediation actions. When mitigating instead of remediating, document how the mitigation changes the vulnerability's exposure profile (e.g., "Blocked internet access to vulnerable service; no longer meets VER-EVA-EIR criteria for internet-reachable").

7. Update Continuous Monitoring Processes

Replace your monthly vulnerability scanning schedule with continuous vulnerability detection that feeds into the VDR/VER evaluation workflow.

Success looks like: You run vulnerability scans at least weekly for internet-facing systems and have automated processes that flag new vulnerabilities for VER evaluation within 24 hours. Your continuous monitoring plan explicitly references VDR and VER requirements instead of legacy scanning procedures.

8. Prepare Reporting for Non-CDS Providers

If you're not following the Certification Data Sharing rules yet, prepare for additional reporting guidance that FedRAMP will release.

Success looks like: You've identified which FedRAMP reporting requirements apply to your service offering and have a communication channel established with your FedRAMP Security Inbox. You're monitoring for the additional reporting guidance and have assigned responsibility for implementing it.

Common Mistakes

Treating this as a documentation exercise. The VDR/VER rules require operational changes to how you discover, evaluate, and respond to vulnerabilities. You can't just relabel your existing monthly scan reports.

Waiting for final rule publication. The Consolidated Rules for 2026 may see minor changes before final release at the end of June, but the core VDR/VER requirements are stable. Start implementation now.

Assuming CVSS scores determine priority. The new approach prioritizes based on exposure and exploitability, not just severity scores. A CVSS 7.5 vulnerability that's internet-reachable and in the KEV catalog outranks a CVSS 9.2 vulnerability with no public exploit and no internet exposure.

Ignoring the grace period implications. Operating under a corrective action plan between December 7, 2026, and March 7, 2027, means FedRAMP notifies all your agency customers that you're non-compliant. That's not a soft deadline.

Next Steps

By July 2026: Review the finalized Consolidated Rules for 2026 and map your current vulnerability management process against VDR/VER requirements. Identify gaps.

By August 2026: Implement internet-reachability evaluation (VER-EVA-EIR) and KEV tracking (VDR-TFR-KEV). These are your highest-priority changes.

By October 2026: Complete implementation of all VER evaluation requirements and VDR response requirements. Begin generating compliance evidence.

By November 2026: Run a full compliance validation against the checklist. Address any gaps before the December 7th deadline.

December 7, 2026: You're either compliant or you're operating under a corrective action plan with agency notification. Plan accordingly.

a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.

You Might Also Like