Updated July 2026 to reflect the FedRAMP Consolidated Rules for 2026, released June 25, 2026.

What it is

The FedRAMP Consolidated Rules for 2026 split vulnerability management into two rule sets. Vulnerability Detection and Response (VDR) covers detection cadences, machine verification and validation, and mitigation and remediation timeframes. Vulnerability Evaluation and Reporting (VER) covers contextual evaluation, the PAIN impact ratings, accepted vulnerabilities, and reporting. The pilot-era standard was a single VDR family that did all of this; the final rules divide the work but keep the intent: replace CVSS-only severity with contextual evaluation based on exploitability, internet-reachability, and potential agency impact.

Both rule sets are mandated by CISA BOD 26-04 and share the same clock: providers MUST obtain compliance by December 7, 2026, and the grace period ends March 7, 2027. They apply to FedRAMP 20x and Rev5 alike.

Under the historical model, vulnerability management was CVSS-driven. Scan, get a score, remediate by severity tier. A Critical vulnerability on an air-gapped internal tool and a Critical vulnerability on an internet-facing authentication service got the same treatment. The scan frequency, remediation SLAs, and reporting cadence were prescribed: 30 days for Critical and High, 90 for Moderate, 180 for Low. Simple to audit. Poor at prioritizing actual risk.

The new rules force providers to evaluate each finding in the context of their environment. The evaluation produces a three-part risk picture: is the vulnerability likely exploitable? Is it internet-reachable? What is the potential impact to agency customers? The answers drive mitigation and remediation urgency.

One more structural change matters: POA&Ms are gone as a FedRAMP artifact. 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 (VER-TFR-MAV), with documented justification. There is no deviation request to FedRAMP, no milestone date to push. Either you fix it, or you accept it in public view.

What it requires

VER defines how you evaluate and report. VDR defines how fast you detect and respond. The MUST vs SHOULD distinction matters when you design the workflow, so it is called out throughout.

The evaluation trio (VER, all MUST)

Every finding is evaluated against three questions. Two of the answers are binary determinations, not scores.

LEV or NLEV (VER-EVA-ELX). LEV means Likely Exploitable Vulnerability: the vulnerability is not fully mitigated, is reachable by a likely threat actor, and that threat actor would likely cause an adverse impact by exploiting it. The determination is contextual and binary, not a numeric value: CISA KEV status, EPSS data, and threat intelligence are evidence for the call, but the output is LEV or NLEV (Not Likely Exploitable Vulnerability). The rules set one hard floor: any vulnerability that an automated unauthenticated system can exploit over the internet is a likely exploitable vulnerability. And per VER-EVA-AIA, providers MUST assume exploitation can be automated unless they have evidence proving otherwise.

IRV or NIRV (VER-EVA-EIR). IRV means Internet-Reachable Vulnerability: a vulnerability in a machine-based resource that might be exploited or triggered by a payload originating from the public internet. Also binary. The word is reachable, not accessible: a database behind a load balancer and firewall with no route to the internet is still internet-reachable if an application can pass it a hostile payload. SQL injection and Log4Shell are the canonical examples. Deflect or sanitize the triggering payload before it reaches the vulnerable resource and the finding stops being an IRV.

PAIN N1-N5 (VER-EVA-EPA). PAIN is the Potential Agency Impact N-rating. Providers MUST assign one of five levels based on the expected customer effect of exploitation:

• N1: minimal customer effects on one or more agencies
• N2: narrow customer effects on one or more agencies
• N3: a disruptive customer effect on one agency
• N4: a debilitating customer effect on one agency, or a disruptive effect on more than one agency
• N5: a debilitating customer effect on more than one agency

The effect words are defined terms, and the rating is provider-evaluated based on the resource’s role, the data it handles, and the blast radius. An RDS instance that stores federal CUI rates higher than one that stores application logs. The evaluation is contextual, which is the entire point.

The SHOULD side of evaluation: group findings that affect similar resources so response is consolidated (VER-EVA-GRV), evaluate false positives (VER-EVA-EFP), and weigh the eight defined evaluation factors, from criticality and reachability to prevalence and proximate vulnerabilities (VER-EVA-EFA). VER-TFR-EVU sets evaluation speed targets by Certification Class: complete the evaluation within 14 days of detection for Class A, 7 days for Class B, 5 days for Class C, 2 days for Class D.

Detection cadences and machine verification (VDR)

VDR-CSO-DET (MUST): systematically, persistently, and promptly discover and identify vulnerabilities. This is broader than scanning: assessment, threat intelligence, disclosure programs, penetration testing, incident response, automated control testing, and supply chain monitoring all count. FedRAMP is explicit that an out-of-date control statement in the Security Decision Record is a vulnerability to be detected and remediated like any other.

VDR-CSO-RES (MUST): track, evaluate, monitor, mitigate, remediate, and report all detected vulnerabilities. Silence is not a response. FedRAMP also separates the terms: mitigation reduces risk and impact, remediation eliminates the vulnerability entirely. A fully mitigated vulnerability still exists until it is remediated.

VDR-CSO-FAV (MUST): failures in your detection and response process are themselves vulnerabilities. A broken scanner is a finding.

The detection cadences are class-based:

• VDR-TFR-NMV (MUST): verify and validate non-machine-based resources at least once every 3 months.
• VDR-TFR-PDD (SHOULD): detect on resources likely to drift: every 3 months (Class A), monthly (B), every 14 days (C), every 7 days (D).
• VDR-TFR-PCD (SHOULD): detect on resources not likely to drift: every 6 months (A and B), monthly (C and D).
• VDR-TFR-PSD (SHOULD): detect on representative samples of similar machine-based resources: every 14 days (A), 7 days (B), 3 days (C), daily (D).
• Machine verification and validation: for 20x, VDR-TFR-MVX is a SHOULD monthly at Class A but a MUST every 7 days at Class B and every 3 days at Class C. For Rev5, VDR-TFR-MVF is a SHOULD monthly at Class B and a MUST monthly at Classes C and D.

VDR-CSO-AKE (SHOULD NOT): do not deploy or activate new machine-based resources with Known Exploited Vulnerabilities. A deployment guardrail, not an after-the-fact finding.

Mitigation and remediation timeframes (VDR-TFR-PVR, SHOULD)

The old 30/90/180 SLAs are gone. VDR-TFR-PVR sets timeframes from evaluation to partially mitigate, fully mitigate, or remediate to a lower PAIN rating, driven by the PAIN rating and the two binary determinations. The Class C table (Class C is the successor to Moderate):

Classes A and B share a slower table (PAIN-5 LEV+IRV is 4 days; PAIN-2 NLEV is 192 days). Class D is the fastest: PAIN-5 LEV+IRV is 12 hours. PAIN-1 has no timeframes at all; VDR-TFR-RMN says providers SHOULD handle remaining vulnerabilities during routine operations as they determine necessary. The three-part evaluation drives the timeline, not the CVSS score.

VDR-TFR-KEV (SHOULD): remediate Known Exploited Vulnerabilities according to the due dates in the CISA KEV Catalog, even if the vulnerability has been fully mitigated, as required by CISA BOD 26-04. KEV due dates override your PAIN-based math.

Reporting and the 192-day rule (VER)

VER-TFR-MHR (MUST): a human-readable report of vulnerability detection and response activity, in a consistent format, at least monthly.

VER-RPT-PER (MUST): report activity to all necessary parties persistently, summarizing all activity since the previous report. These reports are FedRAMP Certification Data, subject to the Certification Data Sharing (CDS) rules, which means they flow through your trust center.

VER-RPT-VDT (MUST): detailed per-vulnerability information: tracking identifier, time and source of detection, time of completed evaluation, IRV status, LEV status, historical and current PAIN, each completed PAIN reduction, the estimated next reduction, overdue status with explanation, supplementary information, and final disposition. FedRAMP publishes a JSON schema for this report.

VER-TFR-MAV (MUST): 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. In the pilot this rule lived at VDR-TFR-MAV; it moved to VER when the standard split. Accepted vulnerabilities require the VER-RPT-AVI documentation: tracking identifier, detection and evaluation times, IRV and LEV status, current PAIN, an explanation of why the vulnerability is accepted, and supplementary information for agency risk decisions. This is the transparency mechanism. The rules do not say you must fix everything in 192 days. They say you must be transparent about what you have not fixed.

VER-TFR-MRH: historical activity in JSON for automated retrieval, updated at least monthly (MAY at Class A, SHOULD at Class B), every 14 days (SHOULD, Class C), or every 7 days (SHOULD, Class D), against the official FedRAMP schema.

VER-TFR-IRI and VER-TFR-NRI: the incident bridge. Internet-reachable likely exploitable vulnerabilities with PAIN above N3 SHOULD be treated as a FedRAMP Reportable Incident at Classes C and D (MAY at A and B) until partially mitigated to N3 or below. Non-internet-reachable LEVs at PAIN N5 get the same treatment at Class D. A bad enough vulnerability is not just a finding; it is an incident.

graph LR
    FIND[Finding] --> EVAL[Evaluate: LEV? IRV? PAIN N1-N5]
    EVAL --> TFR[VDR-TFR-PVR timeframe: 12 hours to 192 days]
    TFR --> REM[Mitigated or Remediated]
    TFR -->|not fixed within 192 days| ACC[Accepted Vulnerability]

    style FIND fill:#2b5797,stroke:#5b9bd5,color:#fff
    style EVAL fill:#5c4a1a,stroke:#ffc857,color:#fff
    style TFR fill:#4a1a5c,stroke:#c77dff,color:#fff
    style REM fill:#1a5c3d,stroke:#51cf66,color:#fff
    style ACC fill:#5c1a3d,stroke:#ff6b9d,color:#fff

Why it matters

VDR and VER move vulnerability management from a checkbox (“scan monthly, remediate by CVSS severity”) to a risk-based methodology that weighs environment context.

The old approach treated all Criticals the same and did not account for exploitability: a theoretical vulnerability with no known exploit got the same 30-day SLA as one with active exploitation and a CISA KEV listing.

The final rules fix this by forcing contextual evaluation: two binary determinations plus a five-level impact rating instead of one score. The result is sharper prioritization: a PAIN-5 LEV+IRV finding on a Class D system gets a 12-hour timeframe, while a PAIN-3 NLEV finding on a Class C system gets 128 days. The binary framing also ends the score-debate culture: you are not arguing whether a finding is a 6.8 or a 7.2; you are answering yes/no questions and estimating agency impact.

The 192-day accepted-vulnerability rule adds transparency. Under the old model, a finding could sit on a POA&M indefinitely with a vague “planned remediation” status and a milestone date that kept moving. Nobody forced the conversation: is this actually going to be fixed, or should we accept it? VER-TFR-MAV forces that conversation at 192 days. Either you fixed it, or it is an accepted vulnerability with documented justification (VER-RPT-AVI). POA&Ms and the FP/OR/RA deviation requests to FedRAMP are gone entirely; the accepted-vulnerability list is what replaced them. No more indefinite deferral.

The MUST vs SHOULD distinction matters for implementation. VER-TFR-MAV (192-day classification) is a MUST. VDR-TFR-PVR (remediation timeframes) is a SHOULD, but SHOULD rules must be addressed in your security documentation with an explanation of your decisions; they are not free to ignore. Build the workflow around the MUSTs; run it against the SHOULD timeframes.

The two standards also connect to the rest of the Consolidated Rules. Accepted vulnerabilities are required content in the Ongoing Certification Report every 3 months (CCM-OCR-AVL). Vulnerability reports are Certification Data shared through your trust center under the CDS rules. And VER-TFR-IRI hands qualifying vulnerabilities to the incident process. The rule sets are designed to work together.

The pain we lived

We ran multiple scanners across environments: infrastructure scanners, web application scanners, container scanners, database scanners. Each produced results in its own format with its own severity scale.

The first problem was normalization. Qualys, Nessus, AWS Inspector, Burp Suite. Different finding formats, different CVE mappings, different severity scores for the same vulnerability. A finding that Qualys rated as a 4 (Critical) might appear as a 9.8 CVSS from Nessus and a “High” from Inspector. Before we could do anything useful with the results, we had to normalize them into a common schema. We could not afford a six-figure enterprise vulnerability aggregation platform for each client, so we did it by hand. Every ConMon cycle, hours spent mapping scanner outputs into a common format.

The second problem was lifecycle tracking. Which findings were new this scan cycle? Which were remediated since last month? Which were closed last month but reappeared? A finding that changed CVE identifiers between scanner versions looked like a new finding even though it was the same vulnerability on the same host. A finding that was patched and then reappeared because a rollback happened looked like a new finding unless you tracked the history. Every ConMon cycle, reconciling the current scan against the prior scan consumed hours of manual comparison.

The third problem was context. CVSS was the only input. A Critical finding on a development server and a Critical finding on a production authentication service got the same 30-day SLA. Nobody had time to evaluate exploitability, reachability, and environmental impact for every finding manually. So everything was prioritized by CVSS, which was better than nothing but worse than risk-based prioritization.

The fourth problem was deviation management. Findings that could not be remediated on the standard timeline (false positives, operational requirements, risk adjustments) each needed documented justification and approval. The deviation lived in a separate tracker from the scan results. Mapping between the two was manual. When an assessor asked “show me the deviation for this finding,” someone had to cross-reference two systems.

Long-lived findings were a chronic issue. Findings sat on POA&Ms for months or years with “planned remediation” status and a milestone date that kept moving. Nobody forced the “accept or fix” conversation. The 192-day clock did not exist under the old model, but the problem it addresses, indefinite deferral without transparency, was real.

How we automate it

VDR and VER shift vulnerability management from “scan and remediate by CVSS” to “evaluate exploitability, reachability, and agency impact for every finding, then respond on a computed clock.” That evaluation is hard to do manually at volume. Enrichment and environmental context are the core of any implementation. Here is how we approach it in Stratus GRC-ITSM.

1. Scanning across the environment, one data model. Infrastructure, containers, applications, databases, web apps. Multiple sources, one normalized intake. Scanner findings become Issue tickets: one umbrella Issue per distinct CVE or weakness, with per-asset child Issues underneath. Finding, asset, CVE, detection source, and detection timestamp are captured the same way regardless of scanner. Lifecycle tracking falls out of the structure: the umbrella persists across scan cycles while children open and close per asset.
2. Enrichment on intake. Every finding is enriched with CISA KEV status, EPSS data, and threat intelligence. No manual CVE lookups. The enrichment is evidence for the binary LEV determination, not a substitute for it: the provider still makes the yes/no call in context, and the evidence trail shows why.
3. Environmental context from live asset inventory. The platform knows which assets can receive internet-originated payloads (drives the IRV determination), which handle federal data or CUI, and what the blast radius is (drives the PAIN rating). Context comes from the asset inventory and its relationships, not a per-finding manual lookup. Ambiguous cases are flagged for human evaluation within the VER-TFR-EVU targets.
4. Remediation clocks per certification regime. The VDR-TFR-PVR timeframes are applied as SLA targets computed from the PAIN rating and the LEV/IRV determinations, tracked automatically per regime, so a system certified under both Rev5 and 20x sees the right clock for each. CISA KEV catalog due dates are enforced on top: a KEV listing overrides the computed date when it is earlier. Approaching deadlines escalate automatically.
5. Deviations that cascade. False-positive, risk-adjustment, and operational-requirement deviations are tickets parented to the Issues they cover, with rationale and evidence. Approval stays human. When a deviation is approved, its status and risk posture cascade to every covered Issue automatically, SLA-aware across the remediation regimes. When an assessor asks “show me the deviation for this finding,” it is one click, not two systems, and these records feed the accepted-vulnerability reporting when a finding crosses the line.
6. Vulnerability-to-incident escalation. Qualifying findings, internet-reachable likely exploitable vulnerabilities above PAIN N3, escalate into Incident tickets per the FedRAMP escalation rules (VER-TFR-IRI), where the incident reporting lifecycle takes over until the finding is mitigated below the threshold.
7. The 192-day accepted-vulnerability workflow. Findings approaching the VER-TFR-MAV threshold are surfaced early, and the responsible party is prompted: remediate, or prepare to accept. When a finding crosses the line, the accepted-vulnerability record is populated from data already on the ticket: tracking identifier, detection and evaluation times, IRV and LEV status, current PAIN. The human writes the explanation and the supplementary guidance for agencies. Nothing is assembled from scratch.
8. Reports generated from live data. The monthly human-readable activity report (VER-TFR-MHR) and the machine-readable vulnerability detail and accepted-vulnerability reports (VER-RPT-VDT, VER-RPT-AVI) are generated views of the same Issue data, so they are always consistent, and they publish through the trust center as the CDS rules require.
9. A scheduled coverage sweep. A recurring automated check verifies operations against the vulnerability-evaluation rules: findings without completed evaluations, evaluations past the class target, clocks not running. Failures in the process are themselves vulnerabilities (VDR-CSO-FAV), so the sweep treats gaps as findings.
10. Evidence as a byproduct. Remediating an Issue on time is not just hygiene; it self-generates validation evidence for the machine verification and validation cadence. The act of operating the process produces the proof the process works.

The throughline: the rules want contextual evaluation and computed response clocks, not CVSS scores and spreadsheet reconciliation. The evaluation is computed with human judgment where it belongs, the timeframes run automatically, the 192-day clock never gets forgotten, and the reports generate from the same data that runs the work.

Compliance is a byproduct of operations, not a separate workstream.

FAQ

This article is part of a 15-part series on the operational disciplines that CMMC, FedRAMP Rev5, and FedRAMP 20x all test. [Read the series overview: Stop Building for Compliance. Build for Operations.]