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

# Vulnerability evaluation and reporting

> Evaluate every detected vulnerability for exploitability, internet-reachability and Potential Agency Impact, then report vulnerability activity to all necessary parties on a fixed cadence.

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

## In short

For every vulnerability you detect, you must decide three things: whether it is likely exploitable, whether it is internet-reachable, and how badly exploitation would affect agency customers. That last rating is the Potential Agency Impact N-rating (PAIN), from N0 to N5. Those three answers drive the mitigation timeframes in [Vulnerability detection and response](/docs/rules/vulnerability-detection-and-response.md) (`VDR`). You must also report vulnerability activity to all necessary parties at least monthly, in a human-readable format. FedRAMP staff say that, for Rev5 providers, these reports replace the legacy POA\&M. Like VDR, these rules are mandated by CISA BOD 26-04 and must be met by 2026-12-07.

## Who it applies to

| Subset | Type | Path | Class | Audience |
| - | - | - | - | - |
| [FedRAMP Responsibilities](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#fedramp-responsibilities) | 20x, Rev5 | Program, Agency | B, C, D | FedRAMP |
| [Agency Guidance](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#agency-guidance) | 20x, Rev5 | Program, Agency | B, C, D | Agencies |
| [Evaluation](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#evaluation) | 20x, Rev5 | Program, Agency | B, C, D | Providers |
| [Reporting](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#reporting) | 20x, Rev5 | Program, Agency | B, C, D | Providers |
| [Timeframes](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#timeframes) | 20x, Rev5 | Program, Agency | B, C, D | Providers |

> [!NOTE]
>
> The subsets list Classes B, C and D, but several timeframe rules also state a Class A variant (`VER-TFR-MRH`, `VER-TFR-EVU`, `VER-TFR-IRI`, `VER-TFR-NRI`). For Class A, [`FRC-CLA-RFR`](https://www.fedramp.gov/2026/reference/fedramp-certification/#recommended-fedramp-rules-for-class-a) recommends `VER-TFR-EVU`, `VER-TFR-IRI`, `VER-TFR-MRH` and `VER-TFR-NRI`. No VER rule is on the Class A mandatory list in [`FRC-CLA-MFR`](https://www.fedramp.gov/2026/reference/fedramp-certification/#mandatory-fedramp-rules-for-class-a).

## 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

### Evaluation (providers)

| Rule | Force | What it means for you |
| - | - | - |
| [`VER-EVA-ELX`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#evaluate-exploitability) | MUST | In the context of your offering, decide whether each detected vulnerability is a likely exploitable vulnerability (LEV). |
| [`VER-EVA-EIR`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#evaluate-internet-reachability) | MUST | Decide whether each detected vulnerability is an internet-reachable vulnerability (IRV). |
| [`VER-EVA-EPA`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#estimate-potential-agency-impact) | MUST | Estimate the likely impact of exploitation on government customers and assign a PAIN rating from N0 to N5 (see [PAIN ratings](#pain-ratings)). |
| [`VER-EVA-AIA`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#assume-its-automatable) | MUST | Assume exploitation can be automated unless you have evidence proving otherwise. |
| [`VER-EVA-GRV`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#group-vulnerabilities) | SHOULD | Group affected information resources logically. VDR rules then apply to the grouping instead of each individual instance. |
| [`VER-EVA-EFP`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#evaluate-false-positives) | SHOULD | Decide whether each detected vulnerability is a false positive. |
| [`VER-EVA-EFA`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#evaluation-factors) | SHOULD | Consider at least these factors: criticality, reachability, exploitability, detectability, prevalence, privilege, proximate vulnerabilities and known threats. |

The notes on `VER-EVA-EIR` explain why FedRAMP uses "internet-reachable" rather than "internet-accessible." A resource deep in your stack can still receive a triggering payload from the internet (SQL injection and Log4Shell are the upstream examples). Once you intercept, filter or otherwise deflect triggering payloads before they reach the vulnerable resource, the vulnerability should no longer be considered internet-reachable.

The notes on `VER-EVA-ELX` warn that evaluating vulnerabilities as not likely exploitable "without careful consideration" raises your risk. If done recklessly or deliberately, it will have a negative impact on your FedRAMP Certification.

#### PAIN ratings

From `VER-EVA-EPA`:

| Rating | Meaning |
| - | - |
| N0 | Exploitation is extremely unlikely to have any adverse effects on agencies that use the offering. |
| N1 | Exploitation could be expected to have minimal customer effects on one or more agencies. |
| N2 | Exploitation could be expected to have narrow customer effects on one or more agencies. |
| N3 | Exploitation could be expected to have a disruptive customer effect on one agency. |
| N4 | Exploitation could be expected to have a debilitating customer effect on one agency, or a disruptive customer effect on more than one agency. |
| N5 | Exploitation could be expected to have a debilitating customer effect on more than one agency. |

The effect levels (minimal, narrow, disruptive, debilitating) are defined terms. See [FedRAMP definitions](https://www.fedramp.gov/2026/definitions/#potential-agency-impact).

### Reporting (providers)

| Rule | Force | What it means for you |
| - | - | - |
| [`VER-RPT-PER`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#persistent-reporting) | MUST | Persistently report vulnerability detection and response activity (including persistent verification and validation) to all necessary parties, summarizing ALL activity since the previous report. These reports are FedRAMP Certification Data and fall under [Certification data sharing](/docs/rules/certification-data-sharing.md). |
| [`VER-RPT-VDT`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#vulnerability-details) | MUST | For each detected vulnerability that isn't accepted, report (if applicable) the items listed below. |
| [`VER-RPT-AVI`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#accepted-vulnerability-info) | MUST | For each accepted vulnerability, report the items listed below, including why it is accepted. |
| [`VER-RPT-NID`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#responsible-disclosure) | MUST NOT / MUST | Don't irresponsibly disclose sensitive details that would likely lead to exploitation. You MUST still disclose enough for informed, risk-based decisions to all necessary parties. |
| [`VER-RPT-HLO`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#high-level-overviews) | SHOULD | Include high-level overviews of ALL detection and response activity in the period, such as vulnerability disclosure programs, bug bounties, penetration testing and assessments. |
| [`VER-RPT-RPD`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#responsible-public-disclosure) | MAY | Responsibly disclose vulnerabilities publicly or to other parties if you determine doing so will NOT likely lead to exploitation. |

The `VER-RPT-NID` note says it will be superseded by formal action related to an investigation or corrective action plan.

**`VER-RPT-VDT` vulnerability details** (if applicable):

1. Your internal tracking identifier
2. Time and source of detection
3. Time of completed evaluation
4. Whether it is internet-reachable
5. Whether it is likely exploitable
6. Historical and current estimated PAIN rating
7. Time and PAIN rating of each completed and evaluated reduction in PAIN rating
8. Estimated time and target PAIN rating of the next reduction
9. Whether it is, or is likely to become, an overdue vulnerability, with an explanation
10. Supplementary information that will help agencies assess or mitigate risk to federal customer data
11. Final disposition

**`VER-RPT-AVI` accepted vulnerability details:**

1. Your internal tracking identifier
2. Time and source of detection
3. Time of completed evaluation
4. Whether it is internet-reachable
5. Whether it is likely exploitable
6. Current estimated PAIN rating
7. Explanation of why it is an accepted vulnerability
8. Supplementary information that will help agencies assess or mitigate risk to federal customer data

FedRAMP publishes JSON schemas for these reports: the [Vulnerability Detail Report](https://fedramp.gov/schemas/fedramp-vulnerability-detail-report-schema-2026-06-24.json) (`VER-RPT-PER`, `VER-RPT-VDT`), [Accepted Vulnerability Info](https://fedramp.gov/schemas/fedramp-accepted-vulnerability-info-schema-2026-06-24.json) (`VER-RPT-AVI`) and [Historical VER Activity](https://fedramp.gov/schemas/fedramp-historical-ver-activity-schema-2026-06-24.json) (`VER-TFR-MRH`).

### Timeframes (providers)

| Rule | Force | What it means for you |
| - | - | - |
| [`VER-TFR-MHR`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#monthly-activity-report) | MUST | Report vulnerability detection and response activity to all necessary parties at least monthly, in a consistent, human-readable format. |
| [`VER-TFR-MAV`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#mark-accepted-vulnerabilities) | MUST | Categorize any vulnerability that is not or will not be fully mitigated or remediated within 192 days of evaluation as an accepted vulnerability. |
| [`VER-TFR-MRH`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#historical-activity) | Varies by class (MAY for A, SHOULD for B, C, D) | Make recent historical detection and response activity available in JSON for automated retrieval (for example, through an API), updated at a frequency set by class. |
| [`VER-TFR-EVU`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#evaluate-vulnerabilities-quickly) | SHOULD (all classes) | Complete the `VER-EVA` evaluation of ALL vulnerabilities within a number of days of detection set by class. |
| [`VER-TFR-IRI`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#internet-reachable-incidents) | Varies by class (MAY for A and B, SHOULD for C and D) | Treat internet-reachable, likely exploitable vulnerabilities with a PAIN rating greater than 3 as a FedRAMP Reportable Incident until they are partially mitigated to N3 or below. |
| [`VER-TFR-NRI`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#non-internet-reachable-incidents) | Varies by class (MAY for A, B and C, SHOULD for D) | Treat likely exploitable vulnerabilities that are NOT internet-reachable with a PAIN rating of 5 as a FedRAMP Reportable Incident until they are partially mitigated to N4 or below. |

A vulnerability treated as a FedRAMP Reportable Incident follows the reporting rules and timeframes in [Incident evaluation and communication](/docs/rules/incident-evaluation-and-communication.md).

### FedRAMP responsibilities

| Rule | Force | What it means for you |
| - | - | - |
| [`VER-FRP-ARP`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#additional-requirements) | MAY | FedRAMP may require you to share additional vulnerability information, alternative reports or reports at a different frequency as a condition of a Corrective Action Plan or other agreements with agencies. |
| [`VER-FRP-ADV`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#sensitive-details) | MAY | FedRAMP may require you to share additional details, including sensitive information that would likely lead to exploitation, during review, response or investigation by necessary parties. |

### Agency guidance

These rules apply to agencies, not to you, but they tell you how your reports will be used.

| Rule | Force | What it means for you |
| - | - | - |
| [`VER-AGM-RVR`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#review-vulnerability-reports) | SHOULD | Agencies should review your vulnerability reports at intervals that match their Authorization to Operate, and should process your machine-readable data automatically. The note recommends agencies review only overdue and accepted vulnerabilities with PAIN greater than 2, unless you recommend mitigations or the service is part of a higher-risk system. |
| [`VER-AGM-MAP`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#maintain-agency-plans-of-action-and-milestones) | SHOULD | Agencies should use your vulnerability information to maintain their own Plans of Action and Milestones when relevant under their security policies. |

## Differences by class

| Rule | Class A | Class B | Class C | Class D |
| - | - | - | - | - |
| `VER-TFR-EVU` Evaluate all vulnerabilities within… of detection | SHOULD, 14 days | SHOULD, 7 days | SHOULD, 5 days | SHOULD, 2 days |
| `VER-TFR-MRH` Historical activity in JSON, updated at least every… | MAY, 1 month | SHOULD, 1 month | SHOULD, 14 days | SHOULD, 7 days |
| `VER-TFR-IRI` Treat IRV + LEV with PAIN greater than 3 as a reportable incident | MAY | MAY | SHOULD | SHOULD |
| `VER-TFR-NRI` Treat NIRV + LEV with PAIN of 5 as a reportable incident | MAY | MAY | MAY | SHOULD |

`VER-TFR-MHR` (monthly human-readable report) and `VER-TFR-MAV` (192 days to accepted) are MUST rules with no class variants.

## What FedRAMP staff have said

> [!NOTE]
>
> **VDT and the monthly report replace the POA\&M.** When you transition to VDR/VER, POA\&M requirements go away. You move to the Vulnerability Detail Report (`VER-RPT-VDT`) and a human-readable Monthly Activity Report (`VER-TFR-MHR`). [paulagosta, 2026-08-24, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18139695)

> [!NOTE]
>
> **PAIN is cumulative across agencies.** A vulnerability that is disruptive to one agency is N3, but disruptive to more than one is N4. A shared resource such as a core database is likely to affect all customers, which raises the PAIN. Computing PAIN from your inventory with a rules engine is the intended approach. If only one agency uses a sub-service, you can scope that sub-service's vulnerabilities to that customer. [pete-gov, 2026-09-10, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18391276)

> [!NOTE]
>
> **No PAIN without agency impact.** If your offering has only one agency customer, N5 never applies. With no federal customers, there is no PAIN, but staff expect serious providers to simulate PAIN or apply it to commercial customers. Evaluating all vulnerabilities as if they impact multiple agencies is the conservative approach, and staff agreed with it. [pete-gov, 2026-09-11, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18402431)

> [!NOTE]
>
> **Rate the vulnerability, not just the component.** A vulnerability's PAIN can be well below the PAIN of the component it sits on when its achievable effect is narrower. Staff called a documented method that does this "STRONGLY ENCOURAGED." You may adjust PAIN for technical impact, but not for reachability or exploitability, which are evaluated separately under `VER-EVA-EIR` and `VER-EVA-ELX`. Staff said PAIN-5 vulnerabilities should be "incredibly rare," even in core components. [pete-gov, 2026-09-28, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18644936)

> [!NOTE]
>
> **Evaluation factors aren't optional extras.** On 2026-10-28, **pete-gov** said the [`VER-EVA-EFA`](https://www.fedramp.gov/2026/reference/vulnerability-evaluation-and-reporting/#evaluation-factors) factors help you do the evaluations the other rules require. You can't accurately decide likely exploitability under `VER-EVA-ELX` without considering the relevant factors. Reachability and exploitability are inputs. "Internet reachable," "likely exploitable" and PAIN are outcomes, so staff said PAIN isn't a ninth factor. `VER-EVA-EFA` is a SHOULD. Staff said that for SHOULD rules you should do what your security and engineering teams support and be ready to explain why it's the right technical approach. They said FedRAMP isn't going to nitpick if you do. [Discussion #146 comment](https://github.com/FedRAMP/community/discussions/146#discussioncomment-19249797)

> [!NOTE]
>
> **N5 needs a debilitating effect, not just an outage.** `VER-EVA-EPA` defines N5 as a debilitating customer effect on more than one agency. A debilitating effect interrupts use for most users or compromises most federal customer data, and an unknown effect is treated as debilitating until proven otherwise. For a service that isn't mission-critical, staff said N5 would not apply and N2 (narrow effect) is more likely. Staff also said to follow the final rules, not the RFC-0031 proposal, and that you don't need to know how agencies use your service, only that they do. [pete-gov, 2026-10-27, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-19226966), [nicole-gov, 2026-10-27](https://github.com/FedRAMP/community/discussions/146#discussioncomment-19225845).

> [!NOTE]
>
> **Reporting false positives.** On 2026-10-26, **pete-gov** said FedRAMP has no specific guidance on how to report false positives, because several approaches make sense. He said `VER-RPT-PER` and the vulnerability details report include false positives by default, since neither excludes them. For `VER-RPT-VDT`, he suggested marking fields that don't apply as not applicable and noting the false positive in the supplementary information item. He also said you could use `VER-EVA-GRV` to keep one "false positives" group. Evaluating a false positive to N0 isn't mandatory, but he called it a reasonable automatic outcome. You should still flag it as a false positive. [Discussion #146 comment](https://github.com/FedRAMP/community/discussions/146#discussioncomment-19203980)

> [!NOTE]
>
> **User interaction is evidence, not proof.** `VER-EVA-AIA` is a MUST: assume exploitation can be automated unless you have evidence it can't. The CVSS user interaction metric can be part of that evidence, but you can't rely on it alone. A flaw that needs a specific action on one walled-off terminal is probably not automatable. One that only needs someone to open an email attachment still is. In general, high user interaction requirements are likely to reduce automatability. [pete-gov, 2026-10-15, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18957963)

> [!NOTE]
>
> **False positives.** Once you determine a finding is a false positive (`VER-EVA-EFP`), its exploitability, reachability and PAIN are effectively null, and you may report them as not applicable. Staff suggested reporting false positives as accepted vulnerabilities in a "false positive" grouping (`VER-EVA-GRV`), and noted a plan to clarify `VER-EVA-EPA` to allow PAIN 0 or N/A. [pete-gov, 2026-10-02, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18714893)

> [!NOTE]
>
> **Track until remediated.** `VER-TFR-MAV` has no special interaction with N0, and you may accept the risk of any vulnerability, even PAIN-5. A fully mitigated vulnerability still exists, so it stays tracked, accepted or not, until it is remediated. [pete-gov, 2026-10-13, discussion #147](https://github.com/FedRAMP/community/discussions/147#discussioncomment-18903585)

> [!NOTE]
>
> **Schemas are minimal on purpose.** Whether a field is optional in a FedRAMP JSON schema doesn't decide whether the information is required. Follow the written rules. [pete-gov, 2026-10-02, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18716792)

> [!NOTE]
>
> **Interim delivery for Rev5 providers not yet on a trust center.** Until you transition to a Certification Data Sharing trust center, use your current mechanism for sharing ConMon materials: for most Class B and C providers that is USDA Connect, and for Class D whatever mechanism you use with your agencies. An updated JSON file there satisfies `VER-TFR-MRH` "as an intermediary," with programmatic access as the long-term goal. Document where reports will live in the SCR or SCN for your VDR/VER transition. [paulagosta, 2026-10-02, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18714482) and [follow-up](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18719569)

> [!NOTE]
>
> **Detection time and evaluation.** On 2026-10-20, **pete-gov** said to track detection time as when the detection system found the vulnerability, not when a later system processed it. The `VDR-TFR-PVR` timelines run from evaluation, and you should keep the gap between detection and evaluation as close to zero as possible. See the [VDR page](/docs/rules/vulnerability-detection-and-response.md) for the rest of that answer. [Discussion #146 comment](https://github.com/FedRAMP/community/discussions/146#discussioncomment-19073144)

> [!NOTE]
>
> **Deadlines and evidence.** After 2026-12-07, FedRAMP will request a corrective action plan from services that don't meet VDR/VER and move them to "In Remediation." After 2027-03-07, it will revoke certification. The reports under the VER Reporting subset are sufficient evidence until your Security Decision Record is updated. [pete-gov, 2026-09-11](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18405212) and [2026-10-05, discussion #146](https://github.com/FedRAMP/community/discussions/146#discussioncomment-18758517)

## Related

* [Vulnerability detection and response](/docs/rules/vulnerability-detection-and-response.md): detection cadence and mitigation timeframes by PAIN
* [Incident evaluation and communication](/docs/rules/incident-evaluation-and-communication.md): what to do when a vulnerability is treated as a reportable incident
* [Certification data sharing](/docs/rules/certification-data-sharing.md)
* [Collaborative continuous monitoring](/docs/rules/collaborative-continuous-monitoring.md): accepted vulnerabilities in the Ongoing Certification Report
* [Rev5 questions on the 2026 rules](/docs/discussions/rev5-cr26-questions.md)
* [20x questions on the 2026 rules](/docs/discussions/20x-cr26-questions.md)


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