Vulnerability Management Policy

Approval #

Revision History #

Review cycle: Every year, and when the Cybersecurity and Infrastructure Security Agency (CISA) changes Binding Operational Directive (BOD) 26-04.

Mandate. The Cybersecurity and Infrastructure Security Agency (CISA) issued Binding Operational Directive (BOD) 26-04, Prioritizing Security Updates Based on Risk, on June 10, 2026. It requires every federal civilian executive branch agency to act in three phases:

• Phase I, at issuance: update the agency’s vulnerability management policy.
• Phase II, by August 9, 2026: revise the agency’s procedures to the directive’s risk model.
• Phase III, by December 7, 2026: remediate on the directive’s Table 1 timelines, and tag every asset that can be reached from outside the agency’s network.

BOD 26-04 revoked BOD 22-01 and BOD 19-02, so procedures written to those directives no longer apply. This policy also covers:

• BOD 23-01, on asset discovery and vulnerability detection.
• BOD 23-02, on management interfaces that can be reached from the internet.
• BOD 25-01, on secure cloud configurations.
• BOD 26-02, on edge devices that no longer receive vendor support.
• National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 controls RA-5 and SI-2.

The table at the end of this policy lists each policy element that BOD 26-04 requires and where to find it here.

1. Policy Statement #

The Organization runs a continuous, risk-based vulnerability management program. The vulnerability management team finds vulnerabilities as they appear. Administrators fix each one by the earliest deadline that applies to it. That deadline comes from BOD 26-04 Table 1, the Organization’s own timeframe for the vulnerability’s severity, or a CISA directive. The team confirms each fix, and the CISO reports to CISA as the directives require. Vulnerabilities on exposed assets that are in CISA’s Known Exploited Vulnerabilities (KEV) catalog come first, because attackers are already using them. The CISO owns this policy. System Owners are accountable for their systems’ findings. The steps are in the Vulnerability Management Procedure (PROC-VM-001).

2. Scope #

This policy applies to:

• Every Internet Protocol (IP) addressable asset that is not ephemeral, on any network that the Organization operates or that a provider operates for it, on premises or in the cloud.
• Mobile devices.
• Container images.
• The Organization’s share of cloud services under the shared responsibility model.
• Weaknesses without a Common Vulnerabilities and Exposures (CVE) ID, such as misconfigurations and web application flaws.

It does not apply to physically air-gapped systems, guest networks that are physically separate from Organization networks, or national security systems.

3. Requirements #

3.1 Detecting vulnerabilities on every asset #

1. The vulnerability management team must detect vulnerabilities continuously. The team uses scanner agents on every managed endpoint and server, and authenticated scans for every asset that cannot run an agent.
2. The team must discover assets across the Organization’s entire address space at least every 7 days, as BOD 23-01 requires.
3. The team must start vulnerability enumeration across all assets at least every 14 days, as BOD 23-01 requires.
4. The team must send results to CISA’s Continuous Diagnostics and Mitigation (CDM) Agency Dashboard within 72 hours, as BOD 23-01 requires.
5. The team must run authenticated scans on the Organization’s cadence for each asset class: operating systems monthly, databases monthly, and web applications monthly.
6. The team must scan with privileged credentials wherever the technology allows. An unauthenticated result does not count as coverage.
7. The team must keep detection content no more than 24 hours behind the vendor’s latest release.
8. The team must reconcile detection coverage with the asset inventory at least weekly. The team treats an asset with no detection method as a finding.
9. The team may count another discovery or detection method for specialized equipment as coverage only after CISA approves it.
10. The team must be able to start discovery or enumeration within 72 hours of a CISA request, and send available results within 7 days.

3.2 Acting on CISA and other threat information #

1. The vulnerability management team must monitor the KEV catalog continuously and set due dates for affected assets within 2 hours of each addition.
2. Until CISA publishes the Automatable and Technical impact values for a CVE ID, the team must treat them as “no” and “total.”
3. The CISO must keep CISA Cyber Hygiene scanning in place. Administrators must not block its source addresses or give them special treatment, and must remove any block that occurs.
4. The team must treat each Cyber Hygiene finding against the BOD 18-01 settings as a vulnerability finding with a due date. For websites, the settings are Hypertext Transfer Protocol Secure (HTTPS) only, with Hypertext Transfer Protocol (HTTP) Strict Transport Security (HSTS), and weak protocols and ciphers turned off. For email, they are the Start Transport Layer Security (STARTTLS) command, a Sender Policy Framework (SPF) record, and a Domain-based Message Authentication, Reporting, and Conformance (DMARC) policy of “reject”.
5. When an Emergency Directive sets a deadline earlier than the due date under this policy, the directive’s deadline applies.
6. The team must handle reports received through the Vulnerability Disclosure Policy (POL-VDP-001), and CISA Ransomware Vulnerability Warning Pilot notices, through the same process.

3.3 Setting remediation deadlines #

Administrators must remediate each finding by its due date. The due date is the start date plus the shortest of these deadlines:

• The Table 1 timeline, for a finding with a CVE ID.
• The Organization’s timeframe for the finding’s severity.
• Any CISA directive deadline.

The start date is the earlier of first detection and the date CISA added the CVE ID to the KEV catalog.

BOD 26-04 Table 1. Days are calendar days.

Organization timeframes (RA-5).

These rules also apply:

• The vulnerability management team treats an asset of unknown exposure as publicly exposed.
• “Fix on system upgrade” never extends an Organization timeframe.
• The team changes a due date only when a decision point changes, such as a KEV addition or removal from the internet. The team records each change and its reason.

3.4 Triaging assets for compromise #

Two things must happen within 3 days for each “3 days and forensic triage” finding, and for any asset where the Security Operations Center (SOC) has seen exploitation:

• Administrators must remediate or mitigate the asset.
• The incident response team must complete an adequate forensic triage, following CISA’s Implementation Guidance and any steps in the KEV entry.

The System Owner of each High Value Asset (HVA) and mission-critical system must keep a plan for triaging and patching that system within 3 days. The Authorizing Official approves the plan.

3.5 Handling vulnerabilities that cannot be fixed in time #

1. For a vulnerability in the KEV catalog, the only accepted mitigation is the catalog’s required action. If administrators cannot complete it by the due date, they must remove the asset from the network.
2. Administrators must isolate any other vulnerability they cannot fix in time, by decommissioning, removing the vulnerable software, segmentation, or a software-defined perimeter or proxy. The Information System Security Officer (ISSO) records it as a plan of action and milestones (POA&M) item.
3. System Owners must decommission end-of-support edge devices on the BOD 26-02 dates in the End-of-Support Edge Device Plan (PLAN-EOS-001).
4. Within 14 days of discovery or CISA notice, System Owners must take each management interface off the internet or place it behind a zero trust policy enforcement point, as BOD 23-02 requires.
5. Administrators must meet every mandatory Secure Cloud Business Applications (SCuBA) policy for cloud tenants in BOD 25-01 scope.

3.6 Verifying fixes #

The vulnerability management team closes a finding only when the vulnerability scanner confirms that the vulnerability is gone. For a decommissioned asset, the team closes the finding once administrators remove the asset from the inventory. When the ISSO shows with documented evidence that a finding is a false positive, the team suppresses it. The ISSO re-validates each suppression at the system’s annual assessment.

3.7 Holding providers to the same deadlines #

The vulnerability management team must keep an inventory of the Organization’s systems that third parties host, and get vulnerability status from each provider. For services authorized under the Federal Risk and Authorization Management Program (FedRAMP), the team works through the FedRAMP Program Management Office. System Owners must require providers without FedRAMP authorization to meet the same deadlines. Contracting Officers must include the deadlines and status reporting in service agreements.

FedRAMP carries out BOD 26-04 for cloud services through two rule sets: Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER). Providers must follow both from December 7, 2026, with a grace period to March 7, 2027 (FedRAMP Consolidated Rules for 2026). Under them, the provider rates each vulnerability with a Potential Agency Impact N-rating (PAIN) from N0 to N5. The provider also says whether the vulnerability is internet-reachable and whether it is likely exploitable (FedRAMP Consolidated Rules for 2026, VER-EVA-EPA). Those three facts set the provider’s deadline to mitigate it (FedRAMP Consolidated Rules for 2026, VDR-TFR-PVR). A vulnerability the provider will not fix within 192 days of evaluation is an accepted vulnerability (FedRAMP Consolidated Rules for 2026, VER-TFR-MAV).

FedRAMP’s agency rules say agencies should review provider vulnerability reports and use them to keep POA&M items current (FedRAMP Consolidated Rules for 2026, VER-AGM-RVR, VER-AGM-MAP). The Organization requires both:

• The vulnerability management team must review each FedRAMP provider’s vulnerability reports at the interval the system’s authorization sets. It uses the provider’s machine-readable data where the provider offers it.
• The review must cover at least every overdue or accepted vulnerability the provider rates above N2. It must also cover any vulnerability the provider recommends that agencies mitigate.
• The System Owner must open a POA&M item when the Organization mitigates a provider’s vulnerability itself, or keeps using a service with an accepted vulnerability that puts its systems at risk.
• The Authorizing Official decides whether to keep using a service with such an accepted vulnerability, and reviews that decision when the Organization’s use of the service changes.

3.8 Tagging exposed assets #

System Owners must continuously identify every asset the Organization owns that anyone can reach from outside its network over a routable IP address. They tag each one with four values: organization and sub-organization; environment (production or development); exposure (public or internal); and asset type (server, application, or network device). The vulnerability management team must report every asset to CDM with all its IP addresses, including private ones.

3.9 Reporting to CISA #

• The vulnerability management team must report KEV status to CISA automatically through CDM. Until that reporting is automated, the team reports by hand every two weeks. From December 7, 2026, the team reports by hand every 7 days, in a machine-readable format CISA approves.
• Each quarter and on request, the CISO must attest the Organization’s public IP addresses and domain names to Cyber Hygiene, listing additions and removals.
• The CISO must submit Cyber Hygiene acceptance letters on request.
• The CISO must give CISA a copy of this policy and the procedure on request.

See the Vulnerability Management Procedure for every report, its timing, and its owner.

4. How Exceptions Are Approved #

The Organization treats an exception as a risk acceptance. Only the Chief Information Officer (CIO), as Authorizing Official, may accept the risk of an unremediated finding. The CIO records the acceptance in the governance, risk, and compliance (GRC) system, with compensating controls and an expiration date. The ISSO records it as a POA&M item. The CIO cannot use a risk acceptance to extend a directive deadline, because CISA grants no waivers for directive actions. If administrators cannot fix a KEV finding in time, they must apply the catalog’s required action or take the asset off the network. The CISO sends special cases to CISA at CyberDirectives@cisa.dhs.gov.

5. Roles and Responsibilities #

6. How the CISO Measures the Program #

Each month, the CISO reviews these measures:

• The share of findings fixed by their due date, by Table 1 timeline and by severity.
• Past-due findings.
• KEV mean time to remediate.
• Authenticated coverage.
• Detection content age.
• Exposure tagging.
• Forensic triage completed on time.
• HVAs with critical findings past due.
• End-of-support assets.
• Open risk acceptances.

The CISO reports these measures in the Federal Information Security Modernization Act (FISMA) CIO metrics and the BOD 26-04 reports. See the Vulnerability Management Procedure for how the team computes each one.

7. BOD 26-04 Policy Elements and Where to Find Them #

Each policy element that BOD 26-04 requires, and the part of this policy that covers it:

8. References #

These are the sources this document cites, with a link to each official text.

• CISA BOD 18-01: Enhance Email and Web Security, October 16, 2017.
• CISA BOD 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks, October 3, 2022.
• CISA BOD 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces, June 13, 2023.
• CISA BOD 25-01: Implementing Secure Practices for Cloud Services, December 17, 2024.
• CISA BOD 26-02: Mitigating Risk From End-of-Support Edge Devices, February 5, 2026.
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk, June 10, 2026.
• CISA Known Exploited Vulnerabilities Catalog, updated continuously.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators), June 24, 2026.