FedRAMP 2026 vulnerability deadlines, worked through a real scan

For years, FedRAMP vulnerability deadlines were a lookup on scanner severity: High in 30 days, Moderate in 90, Low in 180. Monthly continuous monitoring was largely the work of tracking those clocks in a POA&M.

The Consolidated Rules for 2026 end that model. The deadline now depends on what the vulnerability could actually do in your environment. This post walks through the new logic and how I implemented a first pass of it in VulnAnalyzer, the scan analysis tool I built for POA&M work. For the wider set of changes, see FedRAMP's 2026 rules: what changes for continuous monitoring.

Three questions replace one

Under the Vulnerability Evaluation and Reporting rules, a provider must evaluate every detected vulnerability for three things:

Two details are easy to miss.

Internet-reachable is not internet-accessible. A service with no route to the internet still counts if a payload from the internet can reach it indirectly. FedRAMP's own examples are SQL injection through an application tier, and Log4Shell triggered deep in a stack by a logged string.

Impact is about customers, not CVSS. N1 is a minimal effect on agencies using the service. N5 is a debilitating effect on more than one agency. A critical CVSS score on a host that holds nothing does not make an N5.

The deadline comes from all three

The timeframe to reduce a finding's impact rating is set by its N-rating, whether it is likely exploitable, whether it is internet-reachable, and the offering's Certification Class. This is rule VDR-TFR-PVR. For Class C, in days:

Class B is more lenient (4 days at the top left) and Class D stricter (12 hours). N1 has no fixed timeframe.

Three more rules sit on top of the table:

• 192 days is the ceiling. Anything not fully mitigated or remediated within 192 days of evaluation must be reported as an accepted vulnerability (VER-TFR-MAV). This is the replacement for the long-lived POA&M item.
• Some findings are incidents. A likely exploitable, internet-reachable finding rated above N3 should be treated as a FedRAMP Reportable Incident for Class C and D until it is mitigated to N3 or below (VER-TFR-IRI).
• KEV has its own clock. Known Exploited Vulnerabilities should be remediated by CISA's due date even if they have been fully mitigated (VDR-TFR-KEV).

What the same scan looks like under each model

I ran VulnAnalyzer's example scan under both profiles. Five findings show the difference.

The old model gave both Log4Shell findings the same 30 days and both Terrapin findings the same 90. The new one separates them by a factor of four and eight. A "Medium" on the wrong host now has a 16-day clock, which no severity-based process would have produced.

How VulnAnalyzer proposes each answer

A scan export contains none of the three answers directly, so the tool derives a proposal for each and records the evidence.

Likely exploitable. Yes if the CVE is in CISA's KEV catalog, if its EPSS score is at or above 10%, or if the scanner reports an available exploit. FedRAMP explicitly declines to prescribe a framework here, so this is my rule, not theirs, and the threshold is configurable. One deliberate choice: if exploit intelligence cannot be fetched, the finding is assumed likely exploitable. Reporting "not likely" with no evidence is the outcome the rule warns about.

Internet-reachable and asset impact. No scanner knows these. They come from a small asset context file:

host,internet_reachable,impact
203.0.113.0/24,yes,N4
10.20.1.15,yes,N5
10.20.2.0/24,no,N4
10.20.3.*,no,N2

Hosts missing from the file fall back to an assumption the analyst selects, and every value derived that way is marked as assumed in the output.

Impact rating. The lower of two limits: the asset's impact rating, and a cap from scanner severity (Critical N5, High N4, Medium N3, Low N2). The asset limits how bad it can be; the severity limits how much of that this particular finding could deliver.

The deadline is then a table lookup:

# {class: {PAIN: (LEV + IRV, LEV + not IRV, not LEV)}}
PVR_DAYS = {
    "B": {5: (4, 8, 32),  4: (8, 32, 64), 3: (32, 64, 192), 2: (96, 160, 192)},
    "C": {5: (2, 4, 16),  4: (4, 8, 64),  3: (16, 32, 128), 2: (48, 128, 192)},
    "D": {5: (0.5, 1, 8), 4: (2, 8, 32),  3: (8, 16, 64),   2: (24, 96, 192)},
}

def due_days(cert_class, pain, lev, irv):
    row = PVR_DAYS[cert_class].get(pain)
    if row is None:               # N1: no fixed timeframe
        return None
    if not lev:
        return row[2]
    return row[0] if irv else row[1]

What a tool cannot do here

The rules require the provider to evaluate each vulnerability in the context of the cloud service. A heuristic over a CSV does not meet that bar, and I have tried to be honest about it in the tool:

• Everything it produces is labeled as a proposal for an analyst to confirm, with the basis shown for each value.
• Deadlines count from first discovery. The rules count from completed evaluation, which a scan does not record. Discovery is earlier, so the tool errs strict.
• The severity cap is a simplification. A medium-severity flaw that exposes credentials for a high-impact system deserves a higher rating than the cap gives it. That is exactly the judgment the analyst is there to make.
• The export lists the fields the reporting rule requires, but it has not been validated against FedRAMP's published schema.

What the tool does well is the part that used to consume the week: merging scanner formats, applying the lookup consistently, and showing which findings moved. That leaves the analyst's time for the evaluation itself, which is where the 2026 rules want it spent.

Sources

• Vulnerability Evaluation and Reporting
• Vulnerability Detection and Response
• CISA Known Exploited Vulnerabilities catalog
• VulnAnalyzer on GitHub

Rules are as published on fedramp.gov on October 1, 2026, and are still being revised.

← All writing