CISA Binding Operational Directives Compliance

Binding Operational Directives (BODs) issued by the Cybersecurity and Infrastructure Security Agency compel specific, mandatory cybersecurity actions across all federal civilian executive branch agencies. This page covers the scope of BOD authority, the compliance mechanism each directive activates, the most consequential directive categories, and the boundaries that determine which organizations and systems fall under BOD jurisdiction. For federal IT and security teams, compliance officers, and policy professionals, BODs represent enforceable federal requirements — not voluntary guidance.

Definition and scope

A Binding Operational Directive is a compulsory direction issued by the Secretary of Homeland Security under authority granted by 44 U.S.C. § 3553(b) (Federal Information Security Modernization Act, FISMA 2014). CISA administers BODs on behalf of the Secretary and directs their enforcement. The statutory scope covers federal civilian executive branch agencies — specifically those defined as "agencies" under 44 U.S.C. § 3502. This scope explicitly excludes the Department of Defense, the intelligence community, and federally funded research and development centers operating under separate statutory frameworks.

BODs differ categorically from Emergency Directives (EDs), which CISA issues in response to an active, known cyber threat or vulnerability requiring immediate action. BODs address systemic, persistent risk areas — patching cadence, authentication standards, network visibility — rather than single-event threats. Supplemental Directions (SDs) may be appended to existing BODs to expand or clarify scope without issuing a new directive. A complete catalog of active BODs, EDs, and SDs is maintained publicly at cisa.gov/directives.

For agencies navigating the broader federal compliance ecosystem, CISA BODs intersect significantly with FISMA compliance obligations and NIST SP 800-53 control families, though BODs impose response timelines and technical specificity that FISMA alone does not.

How it works

Each BOD activates a structured compliance lifecycle with distinct phases and deadlines:

  1. Issuance — CISA publishes the directive at cisa.gov/directives, specifying the covered entities, required actions, and reporting obligations. The directive includes a technical rationale grounded in observed threat data or risk analysis.
  2. Agency inventory and scope determination — Covered agencies identify affected systems, assets, or configurations within a defined discovery window (timeframes vary by directive but are stated explicitly in each BOD's text).
  3. Remediation execution — Agencies implement the required technical controls or configuration changes by the stated deadline. BOD 19-02, for example, set a 15-day remediation window for critical vulnerabilities and a 30-day window for high-severity vulnerabilities on internet-facing systems (CISA BOD 19-02).
  4. Reporting and attestation — Agencies submit status reports to CISA through the Continuous Diagnostics and Mitigation (CDM) program dashboard or through direct reporting mechanisms specified in the directive. BOD 23-01 required agencies to report asset visibility data to CISA on an ongoing basis rather than at a single point in time (CISA BOD 23-01).
  5. Verification and follow-up — CISA conducts independent validation through scanning, audit, or coordination with agency Inspectors General. Non-compliance findings feed into annual FISMA reporting.

The CISA Known Exploited Vulnerabilities (KEV) catalog, established under BOD 22-01, introduced a standing remediation obligation: agencies must remediate every vulnerability added to the KEV catalog within 2 weeks for actively exploited vulnerabilities or within 6 months for lower-urgency entries. BOD 22-01 transformed KEV from a reference list into a compliance driver.

Continuous monitoring compliance programs at the agency level are directly shaped by BOD reporting cadences, making CDM infrastructure central to sustained BOD compliance.

Common scenarios

Vulnerability and patch management — BOD 19-02 and BOD 22-01 collectively govern how agencies triage and remediate known vulnerabilities. Agencies operating legacy systems frequently encounter scenarios where KEV-listed vulnerabilities exist in software no longer receiving vendor patches, requiring either compensating controls or system decommission decisions.

Secure email and web standards — BOD 18-01 required all federal agencies to implement DMARC at the "reject" policy level, enforce HTTPS across all publicly accessible federal websites, and disable obsolete protocols including SSLv2, SSLv3, and TLS 1.0 (CISA BOD 18-01). Agencies with large web portfolios — particularly those operating hundreds of subdomains — faced significant remediation backlogs under this directive.

Asset visibility and enumeration — BOD 23-01 mandated that agencies perform automated asset discovery every 7 days and initiate vulnerability enumeration every 14 days, with results reported to CISA. This created new operational requirements for agencies without mature asset management infrastructure.

Multi-factor authentication and zero trust — BOD 22-01's companion directive landscape aligns with the zero trust compliance requirements mandate issued through OMB Memorandum M-22-09, reinforcing phishing-resistant MFA as a compliance floor rather than a recommended practice.

Decision boundaries

Several classification questions govern whether and how BODs apply in practice:

In-scope vs. out-of-scope entities — Defense Department components and intelligence agencies follow separate frameworks (DoD 8500-series, IC directives). State, local, tribal, and territorial governments are not bound by BODs but may voluntarily adopt BOD requirements, particularly under CISA's State and Local Cybersecurity Grant Program conditions.

BOD vs. Emergency Directive — BODs address structural, recurring risk. EDs address active, time-critical threats. An agency that has met all BOD obligations can still receive an Emergency Directive requiring immediate additional action if a novel exploit emerges.

Contractor and cloud system applicability — BODs apply to federal information systems as defined under FISMA, including contractor-operated systems that process federal data. FedRAMP authorization requirements impose parallel controls on cloud service providers hosting federal workloads, and BOD compliance obligations flow through agency Authority to Operate (ATO) documentation.

Interaction with sector-specific frameworks — Agencies operating in healthcare, financial, or critical infrastructure contexts must reconcile BOD requirements with sector overlays. The cybersecurity compliance frameworks landscape creates layered obligations where BODs set a federal floor.

References

📜 4 regulatory citations referenced  ·  🔍 Monitored by ANA Regulatory Watch  ·  View update log

Explore This Site