A CISA directive that requires federal agencies and certain contractors to identify, evaluate, mitigate, remediate, and report on known exploited vulnerabilities. It is designed to reduce exposure to weaknesses already being used in the wild, with clear expectations for tracking, internal enforcement, and timely response across covered systems.
What the directive covers
Binding Operational Directive 22-01 is a federal vulnerability management directive, not a general cyber policy. Its purpose is to force action on known exploited vulnerabilities, so the key idea is prioritisation of weaknesses that are already proven to be active exposure points rather than theoretical flaws.
That matters because the directive shifts attention from broad patch backlogs to a narrower, higher-signal list of issues that have clear exploitation evidence. In practice, this makes the directive a control for reducing the window between public knowledge, internal validation, and remediation across covered assets.
For practitioners, the important distinction is that “known exploited” is an operational status with response obligations attached. Once a vulnerability is on the covered list, the organisation is expected to treat it as actionable risk, not as a routine backlog item that can wait for the next maintenance cycle.
Why it exists
The directive exists to reduce exposure to vulnerabilities that attackers are already using in the wild. That is a different risk posture from purely preventive patching, because the harm is not hypothetical, the weakness has already moved into the exploitation phase.
Its security value is strongest where organisations struggle with visibility, asset ownership, and inconsistent remediation discipline. A directive like this creates a common enforcement point, helping agencies and contractors turn external vulnerability intelligence into internal accountability and time-bound response.
The practical benefit is not only faster remediation. It also improves prioritisation, because teams can distinguish between ordinary patch queues and vulnerabilities that have a demonstrated exploitation history and therefore a higher likelihood of operational impact.
How it changes security operations
BOD 22-01 changes the operating model for vulnerability management by requiring identification, evaluation, mitigation, remediation, and reporting in a defined workflow. That means the process is not just technical patching, but also tracking, exception handling, and evidence of completion across the environment.
Its expectations also push organisations toward better asset inventory and internal enforcement. If you cannot reliably find affected systems, assign ownership, or confirm remediation status, you cannot satisfy the directive in a meaningful way.
The directive is closely aligned with broader control families that emphasise vulnerability remediation, auditability, and continuous monitoring. The general pattern is simple: discover the exposure, validate where it exists, remediate it quickly, and retain enough evidence to prove the response occurred.
For a useful reference point on operational control design, the remediation workflow fits well with NIST Cybersecurity Framework 2.0 and the control discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls.
What to watch for in practice
The biggest operational failure mode is not the directive itself, but uneven execution. Common problems include incomplete asset coverage, delayed validation, inconsistent exception handling, and remediation that happens on paper before it happens on the affected system.
Another watchpoint is dependency risk. Some exploited vulnerabilities sit inside software, appliances, or managed services that are not patched by the consuming team in the usual way, which makes ownership and reporting more complex.
Because the directive is about active exploitation, prioritisation should be driven by real exposure, not by patch convenience. Publicly available exploitation intelligence, such as FIRST EPSS, can help teams think about likelihood, but the directive’s core requirement remains response to known exploited weaknesses rather than predictive scoring alone.
Risk and Threat Considerations
Known exploited vulnerabilities create concentrated exposure because attackers already have proof that the weakness can be used successfully. If remediation lags, the organisation is effectively leaving a validated attack path open after the risk has been confirmed.
Failure mechanism: Exposure persists when asset inventory is incomplete, remediation ownership is unclear, or patching is delayed by operational exceptions, allowing a publicly known exploit path to remain reachable.
Impact: The result can be initial compromise, lateral movement, service disruption, data exposure, or repeated exploitation across multiple covered systems before the vulnerability is closed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01 — Risk Identification | Known exploited vulnerabilities are a direct risk input for prioritisation and response. |
| PR.IP-12 — Vulnerability Management | The directive mandates identify, evaluate, mitigate, remediate, and report actions. | |
| RS.MI-03 — Mitigation | BOD 22-01 requires timely mitigation and remediation of active exposure. | |
| Recommendation — Use risk identification to prioritise exploited vulnerabilities by real exposure and impact. Operate a formal vulnerability management workflow to remediate known exploited weaknesses quickly. Apply mitigation processes to reduce exposure from known exploited vulnerabilities without delay. | ||
| CIS Controls v8 | 7.1 — Establish and Maintain Vulnerability Management Process | The directive is fundamentally a vulnerability management mandate for known exploited flaws. |
| 7.4 — Remediate Detected Vulnerabilities | BOD 22-01 centers on remediation of vulnerabilities already identified as exploited. | |
| Recommendation — Maintain a vulnerability management process that prioritises and closes exploited vulnerabilities. Remediate known exploited vulnerabilities according to defined time-bound prioritisation. | ||
Practitioner Guidance
What to watch for: Treat the directive as a governance trigger as much as a patching trigger. The main practitioner task is not simply to apply fixes, but to maintain a defensible record of which systems were in scope, how remediation was prioritised, and when closure was verified.
Governance implication: If internal reporting, ownership, or escalation is weak, the directive will fail at the point where it matters most, because the organisation will know about the vulnerability without having a reliable path to force remediation through to completion.
Practitioner takeaway: The most effective response is a repeatable workflow that ties exploited-vulnerability intelligence to asset ownership, time-bound remediation, and audit-ready proof of closure.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
