BOD 26-04 and FedRAMP VDR: what SaaS vendors must change by 7 December 2026

Summary. From 7 December 2026, every cloud service offering that obtains or keeps a FedRAMP certification must follow FedRAMP's Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) rules. FedRAMP brought that date forward from 1 June 2027 to match CISA Binding Operational Directive (BOD) 26-04 of 10 June 2026, which revoked BOD 19-02 and BOD 22-01 and, from 180 days after issue, gives federal civilian agencies risk-based fix windows: 3 days (plus forensic triage in the most serious cases), 14 days, 60 days, or the next system upgrade. Of the 164 entries CISA added to its Known Exploited Vulnerabilities (KEV) catalogue between 10 June and 13 November 2026, 128 carried a 3-day due date. Under FedRAMP's notice NTC-0017 of 10 November, services not fully migrated on 7 December must file per-rule corrective actions, likely by 17 December; those finishing after 3 February 2027 show as In Remediation; and any service neither migrated nor on an approved plan on 8 March 2027 loses its certification and is banned for a year. SaaS vendors outside FedRAMP are not bound directly, but agencies must review their contracts and apply the same requirements to the cloud providers they use.

About this article. For engineering, security and compliance leads at SaaS companies that hold a FedRAMP certification or sell to US federal agencies. We checked every date, rule and timeframe against CISA's directive, guidance and KEV feed and against FedRAMP's notices, rule pages and migration site on 15 November 2026. This is general information, not legal, contracting or certification advice, and FedRAMP's collection details may change until the Emergency Test goes out. Researched with AI assistance and reviewed by our editorial team.

What changes on 7 December 2026, and the dates around it

BOD 26-04 binds federal civilian agencies, and its Phase III, due within 180 days of issue, requires them to remediate on the new timelines. Counting 180 days from 10 June 2026 gives 7 December 2026. FedRAMP's NTC-0014 made its own vulnerability rules mandatory for providers on the same day, calling the legacy monthly scanning most Rev5 services follow insufficient. Both rulesets list optional adoption from 4 July 2026 and a grace period ending 7 March 2027. The timeline below combines FedRAMP's notices and migration site.

The original plan was mandatory adoption on 1 June 2027 with grace to 1 January 2028. FedRAMP wrote that BOD 26-04 showed CISA would not accept slow, incremental change. For the wider 20x and Rev5 calendar, including the estimated 11 June 2027 cutoff for new Rev5 applications, see our FedRAMP 20x class guide.

BOD 26-04 in plain terms: four questions set the clock

BOD 26-04 replaces severity-score patching with four questions about each vulnerable asset:

1. Asset exposure. Can unauthenticated or untrusted parties reach the asset over public networks such as the internet?

1. KEV status. Is the CVE listed in CISA's KEV catalogue?

1. Exploit automation. Can an adversary automate every step of the exploit?

1. Technical impact. Does exploitation give partial or total control of the asset?

CISA publishes the last three answers for every CVE through its Vulnrichment data, and agencies answer the first using CISA's internet exposure guidance. Table 1 of the directive then sets the agency deadline in calendar days, reproduced below from CISA's published table.

Three details matter. The clock starts when CISA adds a CVE to the KEV catalogue or when the agency finds it on an asset, whichever comes first. Deadlines move as facts change: taking a system off the internet lengthens the clock, and a new KEV listing shortens it. Forensic triage means finishing remediation or mitigation within three days and also checking whether the asset was already compromised. CISA's implementation guidance sets out six triage steps, from scoping to an escalation decision.

What the KEV catalogue looks like under the new directive

Each KEV entry now carries a forensic triage flag, and required actions point to BOD 26-04 guidance for cloud services or say to stop using the product if no mitigation exists. CISA calculates each KEV due date from Table 1, using the evidence it has on whether the flaw sits in publicly exposed assets; each agency still makes the final exposure call asset by asset.

We counted CISA's JSON feed (catalogue version 2026.11.13, 1,781 entries, still current on 15 November). From 10 June to 13 November 2026, CISA added 164 KEVs: 128 with a 3-day due date and 36 with 14 days, and 105 of them flagged for forensic triage. From 1 October to 13 November it added 51: 38 with 3 days (33 of them flagged for triage) and 13 with 14 days. Recent examples:

• OpenSSH CVE-2026-123158, an authentication bypass in sshd on some Linux systems, added 9 November and due 12 November, triage required. See our OpenSSH fix guide.

• Check Point CVE-2026-123039, a permissions flaw in several Check Point gateway and management products, added 13 November and due 16 November, triage required. CISA rates it total control but not automatable, so Table 1 gives an agency asset that is not publicly exposed 14 days, to 27 November. Our Check Point CVE-2026-123039 guide covers the patch.

• Google Chromium CVE-2026-125350, a use-after-free flaw, added 10 November and due 24 November, no triage.

Three days is now the usual KEV window: 78% of additions since 10 June (128 of 164). A team that reviews KEVs in a weekly meeting will miss most due dates. Our exploited VPN flaws round-up shows Table 1 setting five edge-device due dates.

Does BOD 26-04 apply to my SaaS company?

Not directly. Unless a procurement contract says so, the directive does not apply to contractors, but agencies must review all their contracts with the contracting officer to see what changes compliance needs. For systems hosted by third parties, it splits the route:

• FedRAMP-certified offerings. Agencies work through the FedRAMP programme office, and FedRAMP's answer is VDR/VER.

• Cloud offerings without FedRAMP certification. Agencies work directly with the provider so its infrastructure meets the same requirements, with any deviation documented and shared with the customer agency.

CISA's implementation guidance adds that a commercial provider, certified or not, must report the status of outstanding vulnerabilities to the agency it serves, and strongly recommends writing remediation timelines into a service-level agreement or contract.

FedRAMP's VDR and VER rules: what a provider must do

FedRAMP says a provider that follows both rulesets will meet the timelines, prioritisation and approach of BOD 26-04, and that it confirmed this with CISA. Its migration site counts a service as fully migrated when every MUST and MUST NOT rule is fully implemented, and every SHOULD and SHOULD NOT rule is either implemented or otherwise addressed.

Vulnerability Detection and Response (VDR)

The VDR rules widen what counts as a vulnerability and how you find it.

• Detect broadly (MUST). Discovery covers scanning, assessment, threat intelligence, vulnerability disclosure, bug bounties, penetration testing, incident response, automated control testing and supply chain monitoring. An out-of-date control statement in the Security Decision Record is itself a vulnerability.

• Respond to everything (MUST). Track, evaluate, mitigate, remediate, assess exploitation of and report every detected vulnerability. Mitigation reduces risk; remediation removes the flaw.

• Failures are vulnerabilities (MUST). A broken detection or response process is itself a finding.

• Do not ship KEVs (SHOULD NOT). Do not activate new machine-based resources that contain known exploited vulnerabilities.

• Remediate KEVs by CISA's due dates (SHOULD), even if already fully mitigated. NTC-0014 describes this as required unless there are valid technical reasons not to, so treat it as mandatory and document any exception.

Detection frequencies depend on class; resources likely to drift are those whose configuration changes over time. Non-machine verification and the cells marked MUST are mandatory; the other rows are SHOULD rules.

The VDR rules also set the maximum time, from evaluation, to mitigate or remediate a vulnerability down to a lower impact rating (VDR-TFR-PVR), using the rating, likely exploitability (LEV) and internet reachability (IRV) from the VER evaluation below.

Class D is tighter: 12 hours for an N5 vulnerability that is likely exploitable and internet-reachable, and 1 day if it is not internet-reachable. These windows are SHOULD rules, and both FedRAMP and CISA describe their timeframes as maximums, not targets.

Vulnerability Evaluation and Reporting (VER)

The VER rules replace CVSS-only triage with an evaluation in context. For each detected vulnerability a provider MUST decide whether it is a likely exploitable vulnerability (LEV) and an internet-reachable vulnerability (IRV), and MUST assign a Potential Agency Impact N-rating (PAIN) from N0 (exploitation extremely unlikely to affect agencies) to N5 (a debilitating effect on more than one agency). FedRAMP added N0 on 5 October 2026. Providers MUST also assume exploitation can be automated unless they have evidence otherwise.

Internet-reachable is wider than internet-accessible. FedRAMP's notes use SQL injection and Log4Shell as examples: a database or logging library deep in the stack counts if a payload from the internet can trigger it. Filtering or rejecting the triggering payload before the vulnerable component processes it is the simplest way to remove the IRV status.

Reporting rules turn this into data agencies can use:

• Persistent reporting (MUST) of all detection and response activity since the last report, treated as certification data. FedRAMP publishes a JSON schema for the vulnerability detail report.

• Vulnerability details (MUST). Up to 11 items for each vulnerability that is not accepted, including detection time and source, evaluation time, IRV and LEV status, current and past PAIN, the next planned PAIN reduction, and whether it is or will become overdue.

• A human-readable activity report at least monthly (MUST).

• Accepted vulnerabilities (MUST). Anything not fully mitigated or remediated within 192 days of evaluation must be marked accepted and reported with an explanation.

• Evaluation speed (SHOULD). Evaluate every new finding within 14 days (Class A), 7 days (B), 5 days (C) or 2 days (D).

• Incident treatment. Class C and D providers SHOULD treat internet-reachable LEVs rated above N3 as FedRAMP reportable incidents until they are mitigated to N3 or below.

Legacy scanning versus VDR/VER

The legacy column uses FedRAMP's own descriptions and legacy templates.

How enforcement will work through March 2027

NTC-0017, published on 10 November 2026, covers the migration of more than 500 certified cloud services.

The December progress report. FedRAMP will use its quarterly Security Inbox Emergency Test to collect a VDR/VER Migration Progress Report. The message is likely to arrive between 1 and 10 December 2026, with 3 December the current target, and the likely deadline is 2 pm Eastern on 17 December. The report has three parts:

1. A Mini Security Decision Record (Mini-SDR), in CSV or JSON, giving the status of each applicable rule, with a rule-specific corrective action plan and timeline for any required rule not yet implemented.

1. A sample machine-readable activity report under VER-RPT-PER with at least five vulnerabilities of each type, using example data rather than live exploitable findings.

1. A sample human-readable monthly report under VER-TFR-MHR, also with at least five examples of each type.

The web form will likely also ask for the latest corrective action target date and a senior official who attests to accuracy. Providers must place the report in their package repository or trust centre for customers, kept high level with no detail that points to an exploitable flaw. Schemas, templates, validators and examples sit on the migration site; on 15 November its changelog listed only the 10 November launch.

Status and penalties. Failing to answer the Emergency Test puts the offering into the FedRAMP Certified (In Remediation) status for at least 30 days, with every agency customer notified, and a provider that then misses a 30-day deadline to supply the information loses its certification. Any service planning to finish after 3 February 2027 also shows as In Remediation until it reports completion. A service needing more time than 7 March 2027 can ask for an extended conditional grace period, but needs an approved plan and must accept a FedRAMP-coordinated red team assessment. Corrective action plans count as pre-approved until FedRAMP reviews them, mostly from February 2027.

Pipeline and exemptions. A service that receives an agency authority to operate after 7 December files a progress report with its Rev5 application; after 7 March 2027, FedRAMP will not start its review unless it has fully migrated. Agency-provided offerings are exempt because BOD 26-04 already binds them. 20x Class A, 20x Class B and C under the 2026 rules, Initial Implementation, Rev5 Legacy Ready and services still in agency authorisation get an acknowledgement-only Emergency Test.

Which path applies to you: a decision table

Worked example: one KEV and one internal library flaw at a Class B SaaS

Take a hypothetical document-workflow SaaS with a FedRAMP Rev5 Class B certification, 300 Alpine Linux container hosts behind a load balancer, and a Java service tier.

The KEV. CISA lists the OpenSSH flaw on Monday 9 November, due Thursday 12 November with forensic triage. Under VDR-TFR-KEV the provider works to that date even if it blocks the attack path sooner, for example by turning off password logins. The team patches bastion hosts on day 1, rebuilds and redeploys images by day 2, and on day 3 records a triage review of authentication logs. Under VDR-CSO-AKE no host built from the old image goes live, and the report records detection, evaluation, IRV, LEV, PAIN and disposition.

The internal library. A scanner flags a deserialisation flaw, not in the KEV catalogue, in a library used by an internal queue worker that is not internet-accessible. Evaluation, due within 7 days for Class B, finds that customer-uploaded files reach the worker (internet-reachable) and that a public exploit exists (likely exploitable). Exploitation could disrupt one agency, so PAIN is N3, and the Class B window is 32 days from evaluation. Input validation that rejects the triggering payload removes the IRV status, and the window for an N3 that is LEV but not IRV is 64 days. If it is not fully mitigated or remediated by day 192, it is reported as an accepted vulnerability.

The effort. With illustrative inputs, not benchmarks: two engineers for six weeks (240 hours each) at an assumed loaded $95 an hour cost 2 × 240 × $95 = $45,600 once. A quarter of an engineer for ongoing work, 0.25 × 2,080 = 520 hours, adds 520 × $95 = $49,400 a year. FedRAMP publishes no cost estimate, so use your own rates.

Implementation checklist before 7 December

1. Read NTC-0017 and the migration site. Subscribe to its changelog and route Security Inbox emergency messages to a senior security official, as NTC-0015 requires.

1. Tag assets by environment, exposure and type, including what an internet payload can reach.

1. Wire the KEV JSON feed into paging. Match it to your software bill of materials and running images, and open tickets with CISA's due date and triage flag.

1. Add evaluation fields to tickets: LEV, IRV, PAIN, evaluation time, next PAIN reduction and accepted status.

1. Generate both reports from those fields: persistent JSON to FedRAMP's schema and a monthly human-readable summary.

1. Fill in the Mini-SDR with each rule's status and a dated corrective action for every gap, plus the two example reports, and name the senior official who will attest.

1. Rehearse forensic triage so log review, containment and evidence capture fit inside three days.

1. Update agency contracts and service-level agreements to show the same timelines. FedRAMP calls this the first of many migrations, with Certification Data Sharing designed to replace manual collection by the end of 2027.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our cybersecurity services team helps SaaS providers turn KEV feeds, asset tags and LEV, IRV and PAIN fields into the JSON and monthly reports FedRAMP now expects, while certification decisions stay with FedRAMP and your agency customers. Talk to us at /contact-us/.

Last updated: 15 November 2026.

References

1. NTC-0014, FedRAMP Response to CISA BOD 26-04 (Prioritizing Security Updates Based on Risk), 16 June 2026 — FedRAMP

1. BOD 26-04: Prioritizing Security Updates Based on Risk, 10 June 2026 — Cybersecurity and Infrastructure Security Agency

1. Known Exploited Vulnerabilities Catalog JSON feed, version 2026.11.13 — Cybersecurity and Infrastructure Security Agency

1. NTC-0017, VDR/VER Migration Progress Reporting and Upcoming FY27 Q1 FedRAMP Security Inbox Test, 10 November 2026 — FedRAMP

1. Vulnerability Detection and Response, Consolidated Rules for 2026 — FedRAMP

1. NTC-0015, Emergency Test: FY26 Q4 FedRAMP Security Inbox Test, 7 July 2026 — FedRAMP

1. Overview of the FedRAMP VDR/VER Migration — FedRAMP

1. Data Collection via Emergency Test, updated 10 November 2026 — FedRAMP

1. BOD 26-04 Table 1: Remediation Timelines — Cybersecurity and Infrastructure Security Agency

1. BOD 26-04: Implementation Guidance for Prioritizing Security Updates Based on Risk — Cybersecurity and Infrastructure Security Agency

1. Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security Agency

1. CVE-2026-123039 record, CISA ADP Vulnrichment data — CVE Program

1. Vulnerability Evaluation and Reporting, Consolidated Rules for 2026 — FedRAMP

1. FedRAMP Vulnerability Detail Report (VER-RPT-VDT) JSON schema, 24 June 2026 — FedRAMP

1. Legacy Documentation — FedRAMP

1. VDR/VER Migration Resources Changelog — FedRAMP