> ## Documentation Index
> Fetch the complete documentation index at: /docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Vulnerability detection and response

> Find every kind of vulnerability in your cloud service offering through persistent, mostly automated detection, then mitigate or remediate it within class-based timeframes.

> [!NOTE]
>
> **Official source:** [Vulnerability Detection and Response](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/) (`VDR`), FedRAMP Consolidated Rules release `2026.10.14.01`. This page is a plain-English summary. The official rule text governs.

## In short

You must persistently find, track and manage all vulnerabilities in your cloud service offering, not only CVE-type findings from scanners. A failure in your own detection and response process counts as a vulnerability, and so does an out-of-date control statement in your Security Decision Record. Detection frequency and the time allowed to mitigate or remediate depend on your class: Class D has the tightest timeframes. These rules are mandated by CISA BOD 26-04, and providers must meet them by 2026-12-07, for both 20x and Rev5.

The VDR works together with [Vulnerability evaluation and reporting](/docs/rules/vulnerability-evaluation-and-reporting.md) (`VER`). VER tells you how to rate each vulnerability (including its Potential Agency Impact N-rating, or PAIN) and how to report it. VDR sets the detection cadence and the mitigation timeframes that use that rating.

## Who it applies to

| Subset | Type | Path | Class | Audience |
| - | - | - | - | - |
| [General Provider Responsibilities](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#general-provider-responsibilities) | 20x, Rev5 | Program, Agency | B, C, D | Providers |
| [Timeframes](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#timeframes) | 20x, Rev5 | Program, Agency | B, C, D | Providers |

Upstream describes the General Provider Responsibilities subset as applying "to all providers with FedRAMP Certifications of any type."

> [!NOTE]
>
> Both subsets list Classes B, C and D, but several timeframe rules also state a Class A variant (`VDR-TFR-PDD`, `VDR-TFR-PCD`, `VDR-TFR-PVR`, `VDR-TFR-PSD`, `VDR-TFR-MVX`). For Class A, [`FRC-CLA-MFR`](https://www.fedramp.gov/2026/reference/fedramp-certification/#mandatory-fedramp-rules-for-class-a) makes `VDR-CSO-DET` mandatory, and [`FRC-CLA-RFR`](https://www.fedramp.gov/2026/reference/fedramp-certification/#recommended-fedramp-rules-for-class-a) recommends `VDR-TFR-MVX`, `VDR-TFR-PCD`, `VDR-TFR-PDD`, `VDR-TFR-PSD` and `VDR-TFR-PVR`. See [FedRAMP certification](/docs/rules/fedramp-certification.md).

## Key dates

The same dates apply to 20x and Rev5.

| | 20x and Rev5 |
| - | - |
| Status | Required (mandated by CISA BOD 26-04) |
| Optional adoption allowed | 2026-07-04 |
| Obtaining initial certification | 2026-12-07 |
| Maintaining ongoing certification | 2026-12-07 |
| Grace period ends | 2027-03-07 |

## What you need to do

### General provider responsibilities

| Rule | Force | What it means for you |
| - | - | - |
| [`VDR-CSO-DET`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#vulnerability-detection) | MUST | Systematically, persistently and promptly discover vulnerabilities using appropriate techniques, such as assessment, scanning, threat intelligence, vulnerability disclosure, bug bounties, penetration testing, incident response, automated control testing and supply chain monitoring. This includes persistently verifying and validating that information resources and processes work as intended and documented. |
| [`VDR-CSO-RES`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#vulnerability-response) | MUST | Systematically, persistently and promptly track, evaluate, monitor, mitigate, remediate, assess exploitation of, report and otherwise manage all detected vulnerabilities. |
| [`VDR-CSO-FAV`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#failures-are-vulnerabilities) | MUST | Treat problems or failures in your own vulnerability detection and response processes as vulnerabilities. |
| [`VDR-CSO-DFR`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#design-for-resilience) | SHOULD | Make design and architecture decisions that mitigate vulnerabilities by default and make detection and response simpler and less risky. |
| [`VDR-CSO-ADT`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#automate-detection) | SHOULD | Use automated services to improve and streamline detection and response. |
| [`VDR-CSO-DAC`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#detect-after-changes) | SHOULD | Automatically run vulnerability detection on representative samples of new or significantly changed information resources. |
| [`VDR-CSO-MSP`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#maintain-security) | SHOULD NOT | Don't weaken the security of information resources just to make scanning, detection or assessment easier. |
| [`VDR-CSO-AKE`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#avoid-kevs) | SHOULD NOT | Don't deploy or activate new machine-based information resources that have Known Exploited Vulnerabilities (KEVs). |
| [`VDR-CSO-SIR`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#sampling) | MAY | Sample effectively identical information resources (especially machine-based ones) during detection, unless sampling would make detection less efficient or effective. |

> [!WARNING]
>
> Upstream states that vulnerability detection and response "is NOT limited to traditional vulnerability scanning or testing." An out-of-date control statement in your [Security Decision Record](/docs/rules/security-decision-record.md) is a vulnerability you must detect and remediate like any other.

The notes on these rules also say:

* If you can't fully mitigate or remediate a vulnerability, you SHOULD partially mitigate it promptly, progressively and persistently (`VDR-CSO-RES` note).
* FedRAMP doesn't treat "mitigation" and "remediation" as the same thing. Mitigation reduces risk, up to and including full mitigation. Remediation removes the vulnerability entirely. A fully mitigated vulnerability still exists until it is remediated.
* FedRAMP strongly discourages running a separate VDR process for FedRAMP reporting through an independent compliance branch, unless that process consumes data directly from the teams that actively maintain the service (`VDR-CSO-DET` note).

### Timeframes

| Rule | Force | What it means for you |
| - | - | - |
| [`VDR-TFR-NMV`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#non-machine-verification-and-validation) | MUST | Verify and validate the status of non-machine-based information resources at least once every 3 months. |
| [`VDR-TFR-PDD`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#persistent-drift-detection) | SHOULD (all classes) | Run vulnerability detection on all information resources likely to drift, at a frequency set by class. See the [detection cadence table](#detection-and-verification-cadence-by-class). |
| [`VDR-TFR-PCD`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#persistently-complete-detection) | SHOULD (all classes) | Run vulnerability detection on all information resources NOT likely to drift, at a frequency set by class. |
| [`VDR-TFR-PSD`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#persistent-sample-detection) | SHOULD (all classes) | Run vulnerability detection on representative samples of similar machine-based information resources, at a frequency set by class. |
| [`VDR-TFR-MVX`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#persistent-machine-verification-and-validation-for-20x) | Varies by class (SHOULD for A, MUST for B and C) | 20x only: verify and validate the status of machine-based information resources at a frequency set by class. |
| [`VDR-TFR-MVF`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#persistent-machine-verification-and-validation-for-rev5) | Varies by class (SHOULD for B, MUST for C and D) | Rev5 only: verify and validate the status of machine-based information resources at least once every month. |
| [`VDR-TFR-PVR`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#mitigation-and-remediation-expectations) | SHOULD (all classes) | Partially mitigate, fully mitigate or remediate each vulnerability to a lower PAIN rating within the timeframes from evaluation shown in the [mitigation tables](#mitigation-and-remediation-timeframes-by-class). |
| [`VDR-TFR-RMN`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#remaining-vulnerabilities) | SHOULD | Mitigate or remediate remaining vulnerabilities during routine operations, as you determine necessary. |
| [`VDR-TFR-KEV`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#remediate-kevs) | SHOULD | Remediate KEVs by the due dates in the CISA Known Exploited Vulnerabilities Catalog, even if they are fully mitigated, as required by [CISA BOD 26-04](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk) or successor CISA guidance. |

## Differences by class

### Detection and verification cadence by class

Each cell is the minimum frequency ("at least once every…") stated upstream. A dash means the rule has no variant for that class.

| Rule | Force | Class A | Class B | Class C | Class D |
| - | - | - | - | - | - |
| `VDR-TFR-PDD` Resources likely to drift | SHOULD | 3 months | 1 month | 14 days | 7 days |
| `VDR-TFR-PCD` Resources NOT likely to drift | SHOULD | 6 months | 6 months | 1 month | 1 month |
| `VDR-TFR-PSD` Representative samples of similar machine-based resources | SHOULD | 14 days | 7 days | 3 days | 1 day |
| `VDR-TFR-MVX` Verify and validate machine-based resources (20x) | A: SHOULD; B, C: MUST | 1 month | 7 days | 3 days | — |
| `VDR-TFR-MVF` Verify and validate machine-based resources (Rev5) | B: SHOULD; C, D: MUST | — | 1 month | 1 month | 1 month |
| `VDR-TFR-NMV` Verify and validate non-machine-based resources | MUST (no class variants) | 3 months | 3 months | 3 months | 3 months |

### Mitigation and remediation timeframes by class

`VDR-TFR-PVR` (SHOULD for every class) sets the time you have, counted from evaluation, to reduce a vulnerability to a lower PAIN rating. The timeframe depends on the current PAIN rating (defined in [`VER-EVA-EPA`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#estimate-potential-agency-impact)), whether the vulnerability is likely exploitable (LEV) or not (NLEV), and whether it is internet-reachable (IRV) or not (NIRV).

#### Class A and Class B (identical)

| PAIN rating | LEV + IRV | LEV + NIRV | NLEV |
| - | - | - | - |
| PAIN-5 | 4 days | 8 days | 32 days |
| PAIN-4 | 8 days | 32 days | 64 days |
| PAIN-3 | 32 days | 64 days | 192 days |
| PAIN-2 | 96 days | 160 days | 192 days |

#### Class C

| PAIN rating | LEV + IRV | LEV + NIRV | NLEV |
| - | - | - | - |
| PAIN-5 | 2 days | 4 days | 16 days |
| PAIN-4 | 4 days | 8 days | 64 days |
| PAIN-3 | 16 days | 32 days | 128 days |
| PAIN-2 | 48 days | 128 days | 192 days |

#### Class D

Upstream calls these the "maximum timeframes from evaluation" for Class D.

| PAIN rating | LEV + IRV | LEV + NIRV | NLEV |
| - | - | - | - |
| PAIN-5 | 12 hours | 1 day | 8 days |
| PAIN-4 | 2 days | 8 days | 32 days |
| PAIN-3 | 8 days | 16 days | 64 days |
| PAIN-2 | 24 days | 96 days | 192 days |

The tables stop at PAIN-2: upstream gives no `VDR-TFR-PVR` timeframe for PAIN-1 or PAIN-0. `VDR-TFR-RMN` says you SHOULD mitigate or remediate remaining vulnerabilities during routine operations, as you determine necessary. Separately, [`VER-TFR-MAV`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#mark-accepted-vulnerabilities) requires you to categorize any vulnerability that isn't or won't be fully mitigated or remediated within 192 days of evaluation as an accepted vulnerability.

## What FedRAMP staff have said

> [!NOTE]
>
> **The mitigation clock resets after a meaningful mitigation.** When a mitigation lowers a vulnerability's PAIN rating, the new evaluation starts a new `VDR-TFR-PVR` clock. In the example asked about, a Class C PAIN-3 LEV+IRV vulnerability mitigated to PAIN-2 LEV+NIRV on day 16 gets 128 days from that new evaluation, not from the original one. pete-gov also said the deadlines are "absolute worst-case." [pete-gov, 2026-09-08, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18356896)

> [!NOTE]
>
> **Deadlines run from evaluation, not detection.** You report the time between detection and evaluation, and you're expected to begin evaluation promptly. During the transition, you should re-evaluate older vulnerabilities, prioritize the serious ones and start reporting. Long-standing legacy POA\&M items can generally move over as accepted vulnerabilities. [pete-gov, 2026-10-13, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18909538) and [follow-up, 2026-10-14](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18923577)

> [!NOTE]
>
> **Sampling is always optional.** `VDR-CSO-SIR` lets you meet monitoring requirements by sampling identical resources, such as containers from the same image. `VDR-TFR-PSD` still sets the detection frequency, which you can meet by scanning everything or by scanning samples. [dan-fedramp, 2026-08-14, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18021674)

> [!NOTE]
>
> **`VDR-TFR-NMV` covers documentation, personnel and budgets.** Staff confirmed a reading that non-machine resources (documentation, personnel and budgets) must be verified and validated every 3 months. This is distinct from the periodic policy review in SP 800-53 "-1" controls. Tracking last-verified dates in your Minimum Assessment Scope inventory makes sense, and you should summarize this work in your VDR activity reports. [pete-gov, 2026-09-13, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18425215)

> [!NOTE]
>
> **The approach is yours to choose.** For `VDR-CSO-DET`, FedRAMP doesn't prescribe a technical process (for example, whether SCA or SBOM scans must be included). You decide the approach, document it and share it so agencies can judge it. Staff strongly recommend logical groupings at scale to reduce noise. [pete-gov, 2026-10-08, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18817958)

> [!NOTE]
>
> **What happens after 2026-12-07.** FedRAMP will request a corrective action plan from services that don't meet VDR/VER and move them to an "In Remediation" status. After 2027-03-07, FedRAMP will revoke certification from services that still don't meet the rules. [pete-gov, 2026-09-11, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18405212)

> [!NOTE]
>
> **What "meeting VDR/VER" means on 2026-12-07.** All applicable VDR and VER rules must be addressed. The VER Reporting outputs are sufficient evidence until your Security Decision Record is updated, and independent verification can come later in your normal assessment cycle. A SHOULD rule counts as addressed if you explain your decision and identify the risk to agency customers. [pete-gov, 2026-10-05, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18758517)

> [!NOTE]
>
> **How FedRAMP will check, and what it expects on 2026-12-07.** On 2026-10-22, **pete-gov** said FedRAMP will ask you and review your required VDR and VER activity reports. It isn't planning to evaluate your progress along the way. Full implementation is expected by 2026-12-07. If you aren't done, you must supply a corrective action plan to finish by 2027-03-07. **pete-gov** added that the grace period applies only to FedRAMP Certification, and that it doesn't protect you from agencies. Agencies must report their status under BOD 26-04 on 2026-12-07, and staff said that after past BOD deadlines, agencies have been forced to turn off non-compliant services within a few months. [Discussion #146 comment](https://github.com/FedRAMP/community/discussions/146#discussioncomment-19131028)

> [!NOTE]
>
> **Detection time, drift and unpatched vulnerabilities.** On 2026-10-20, **pete-gov** answered a provider with a continuous scanner. Track detection time as when the detection system found the vulnerability, not when a later system pulled or processed it. The `VDR-TFR-PVR` timelines run from evaluation, so keep the gap between detection and evaluation as close to zero as you can. Whether IaC-managed resources are unlikely to drift is for your engineering team to decide, because it depends on how you deploy and manage them. If a vendor fix isn't available yet, mitigate the vulnerability instead of only accepting it. Mitigation is now expected by default, and if you don't mitigate, you need to explain the risk and impact to customers. [Discussion #146 comment](https://github.com/FedRAMP/community/discussions/146#discussioncomment-19073144)

> [!NOTE]
>
> **Mitigated KEVs.** In the same comment, **pete-gov** said a fully mitigated KEV still needs to be remediated, and gave 14 days. The published [`VDR-TFR-KEV`](https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/#remediate-kevs) is a SHOULD that uses the due dates in the CISA catalog, even if the vulnerability is fully mitigated. It doesn't state 14 days, so the rule text governs. In a follow-up on 2026-10-22, **pete-gov** said the SHOULD can rest on valid technical reasons you can't compensate for, such as no vendor remediation or a fix owned by a leveraged provider. FedRAMP wouldn't revoke certification over that, but agency customers may not accept your reasons. [Discussion #146 follow-up](https://github.com/FedRAMP/community/discussions/146#discussioncomment-19131580)

> [!NOTE]
>
> **Adopting VDR/VER is a significant change.** Transitioning to VDR/VER should be handled as a significant change (through SCR or SCN), and staff expect most of these transitions to be adaptive. [paulagosta, 2026-08-26, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18162066), [nicole-gov, 2026-10-05](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18759086)

## Related

* [Vulnerability evaluation and reporting](/docs/rules/vulnerability-evaluation-and-reporting.md): PAIN ratings, evaluation and reporting
* [Incident evaluation and communication](/docs/rules/incident-evaluation-and-communication.md)
* [Significant change notification](/docs/rules/significant-change-notification.md)
* [Security decision record](/docs/rules/security-decision-record.md)
* [Minimum assessment scope](/docs/rules/minimum-assessment-scope.md)
* [Rev5 questions on the 2026 rules](/docs/discussions/rev5-cr26-questions.md)
* [Notable staff answers](/docs/discussions/notable-staff-answers.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.