Official source: 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 (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
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 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.Key dates
The same dates apply to 20x and Rev5.What you need to do
Evaluation (providers)
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
FromVER-EVA-EPA:
The effect levels (minimal, narrow, disruptive, debilitating) are defined terms. See FedRAMP definitions.
Reporting (providers)
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):
- Your internal tracking identifier
- Time and source of detection
- Time of completed evaluation
- Whether it is internet-reachable
- Whether it is likely exploitable
- Historical and current estimated PAIN rating
- Time and PAIN rating of each completed and evaluated reduction in PAIN rating
- Estimated time and target PAIN rating of the next reduction
- Whether it is, or is likely to become, an overdue vulnerability, with an explanation
- Supplementary information that will help agencies assess or mitigate risk to federal customer data
- Final disposition
VER-RPT-AVI accepted vulnerability details:
- Your internal tracking identifier
- Time and source of detection
- Time of completed evaluation
- Whether it is internet-reachable
- Whether it is likely exploitable
- Current estimated PAIN rating
- Explanation of why it is an accepted vulnerability
- Supplementary information that will help agencies assess or mitigate risk to federal customer data
VER-RPT-PER, VER-RPT-VDT), Accepted Vulnerability Info (VER-RPT-AVI) and Historical VER Activity (VER-TFR-MRH).
Timeframes (providers)
A vulnerability treated as a FedRAMP Reportable Incident follows the reporting rules and timeframes in Incident evaluation and communication.
FedRAMP responsibilities
Agency guidance
These rules apply to agencies, not to you, but they tell you how your reports will be used.Differences by class
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
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 #146PAIN 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
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
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 #146Evaluation factors aren’t optional extras. On 2026-10-28, pete-gov said the
VER-EVA-EFA 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 commentN5 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, nicole-gov, 2026-10-27.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 commentUser 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 #146False 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 #146Track 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 #147Schemas 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
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 and follow-upDetection 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 for the rest of that answer. Discussion #146 commentDeadlines 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 and 2026-10-05, discussion #146
Related
- Vulnerability detection and response: detection cadence and mitigation timeframes by PAIN
- Incident evaluation and communication: what to do when a vulnerability is treated as a reportable incident
- Certification data sharing
- Collaborative continuous monitoring: accepted vulnerabilities in the Ongoing Certification Report
- Rev5 questions on the 2026 rules
- 20x questions on the 2026 rules