Critical Infrastructure Fleet Health Under CISA

Regulatory Framework

CISA's authority over critical infrastructure cybersecurity flows from the Homeland Security Act of 2002 as amended by the Cybersecurity and Infrastructure Security Agency Act of 2018 (6 U.S.C. § 651 et seq.), which designated CISA as the national coordinator for critical infrastructure security and resilience. Presidential Policy Directive 21 (PPD-21, 2013) identifies sixteen critical infrastructure sectors, each with a designated Sector Risk Management Agency (SRMA) that works with CISA to develop sector-specific guidance. The Cross-Sector Cybersecurity Performance Goals (CPGs) provide a voluntary baseline mapped to NIST CSF functions, and sector-specific CPGs have been issued or are in development for Water and Wastewater (January 2024), Healthcare and Public Health, and the Chemical sector.

Underlying technical standards include NIST SP 800-53 Rev. 5 (security and privacy controls for information systems), NIST SP 800-82 Rev. 3 (operational technology security), and the IEC 62443 series for industrial automation and control systems. The IEC 62443-4-2 component requirements and 62443-3-3 system requirements explicitly contemplate continuous monitoring of device identity, configuration integrity, and firmware provenance. Executive Order 14028 further mandated software bill of materials (SBOM) production and the deployment of zero-trust architectures across federal systems, requirements that have flowed downstream into CISA guidance for critical infrastructure operators through Binding Operational Directives such as BOD 23-01 (asset visibility) and BOD 23-02 (internet-exposed management interfaces).

CIRCIA's reporting timelines, finalized through CISA's Notice of Proposed Rulemaking process, presume that operators can identify, characterize, and attribute cyber incidents at machine speed. The statutory framework consequently demands not policy artifacts but live, queryable evidence that each device in a critical-infrastructure fleet is in a known-good state.

Architectural Requirement

The architectural requirement implied by CISA guidance is not a single tool but a continuous, cryptographically-grounded substrate that produces verifiable assertions about every operational device. Each substation relay, water-treatment programmable logic controller, rail signaling node, or hospital infusion pump must be capable of attesting to its own identity, firmware measurement, configuration baseline, and runtime integrity in a manner that downstream auditors, sector ISACs, and CISA itself can independently verify. The CPGs explicitly call for asset inventory (CPG 1.A), hardware and software approval processes (CPG 2.Q), and detection of relevant threats and tactics, techniques, and procedures (CPG 3.A) — none of which can be satisfied by spreadsheet-driven inventories at the fleet scale typical of an investor-owned utility or a Class I freight railroad.

Sector-specific guidance amplifies this requirement. The TSA Security Directives 1580/82-2022 series for surface transportation owners and operators requires implementation of a Cybersecurity Implementation Plan with continuous monitoring of critical cyber systems. EPA's water sector guidance, reinforced after the Oldsmar incident, similarly presumes continuous device-state visibility. The Department of Energy's Cyber-Informed Engineering initiative and the C2M2 (Cybersecurity Capability Maturity Model) version 2.1 explicitly score continuous monitoring maturity against the ability to detect anomalous device behavior in operational technology environments.

In every sector the architectural primitive is the same: a fleet-wide health-monitoring layer that emits attestations bound to hardware roots of trust, propagates revocations within minutes rather than days, and composes into governance-chain evidence that survives regulatory scrutiny. The substrate must be tamper-evident, must accommodate heterogeneous vendors, and must operate under the assumption that any individual device may have already been compromised.

Why Procedural and Bolt-On Compliance Fails

Procedural compliance — annual third-party assessments, quarterly vulnerability scans, signed policy documents — produces evidence at a cadence orders of magnitude slower than the threats CISA is responding to. The Volt Typhoon and Salt Typhoon campaigns disclosed in 2023 and 2024 demonstrated that nation-state actors had pre-positioned in U.S. critical infrastructure for years without detection by procedural controls. Periodic audits cannot detect a living-off-the-land adversary who modifies device firmware between assessments and reverts before the next scan.

Bolt-on compliance — endpoint detection agents bolted onto industrial control systems, network sensors retrofitted into legacy SCADA networks, SIEM ingestion of vendor-specific logs — produces evidence that is not cryptographically bound to the device under observation. An attacker with privileged access can suppress, replay, or fabricate the very telemetry that bolt-on tools rely on. The 2021 Colonial Pipeline incident illustrated the failure mode: the bolt-on monitoring stack could not provide evidence of the OT network state because it was never architected as a primary source of truth.

CIRCIA's 72-hour reporting clock makes the failure economically acute. Operators who cannot produce machine-verifiable evidence of incident scope within hours face simultaneous regulatory exposure, civil liability, and operational paralysis. Bolt-on stacks also fail the sector-coordination test: each ISAC receives a different log schema from each operator, preventing the sector-wide composite assessment that CISA's coordination model requires.

What The AQ Primitive Provides

The Adaptive Query health-monitoring primitive is engineered as an architectural substrate, not a compliance tool. Each device in the fleet is bound to a hardware-rooted identity through a Physical Unclonable Function (PUF) challenge-response protocol, producing an unforgeable per-device cryptographic identity that survives firmware updates and cannot be cloned by an attacker who exfiltrates software state. Tamper-evident seals, implemented as Merkle-chained measurement logs anchored in the device's secure element, produce continuous attestations of firmware version, configuration hash, and runtime integrity that downstream verifiers can independently check.

Device-integrity attestation is composed with SBOM attestation: each firmware image is published with its software bill of materials in CycloneDX or SPDX format, signed by the manufacturer, and bound to the measurement that the device emits at boot. A verifier presented with a device attestation can therefore reconstruct the complete software supply chain back to upstream open-source components, satisfying EO 14028 §4 obligations and the SBOM expectations now embedded in NDAA Section 1505 and the FDA's premarket cybersecurity guidance for medical devices in adjacent sectors.

Zero-trust device management replaces the perimeter model with continuous authorization: every operational request — a setpoint change, a firmware push, a configuration read — is evaluated against the device's current attestation state and the requesting principal's credentials, with no implicit trust granted by network location. Revocation propagation operates through a gossip-and-anchor protocol that ensures a compromised device's credentials are repudiated across the fleet within seconds of detection, eliminating the multi-day revocation lag typical of certificate-revocation-list deployments in OT environments.

The primitive composes with the AQ governance-chain five-property chain (provenance, integrity, non-repudiation, completeness, and temporal ordering), so that every health-monitoring attestation becomes a first-class evidentiary record admissible in regulatory proceedings, civil litigation, and sector-coordinated incident response. The composition is what distinguishes architectural fleet-health from yet another monitoring product.

Compliance Mapping

The AQ health-monitoring primitive maps directly onto the Cross-Sector CPGs: CPG 1.A (Asset Inventory) is satisfied by the PUF-bound device identity registry; CPG 2.A (Changing Default Passwords) and 2.B (Minimum Password Strength) are subsumed by the zero-trust authorization model that makes static credentials irrelevant; CPG 2.Q (Hardware and Software Approval Process) is satisfied by SBOM attestation gates; CPG 3.A (Detecting Relevant Threats and TTPs) and 4.C (Deploy Security.txt Files) are addressed through continuous attestation.

Against NIST SP 800-53 Rev. 5, the primitive maps to control families CM (Configuration Management — particularly CM-2, CM-3, CM-8), SI (System and Information Integrity — SI-7 software/firmware integrity), SC (System and Communications Protection — SC-12, SC-13, SC-17), and IA (Identification and Authentication — IA-3 device identification and authentication). IEC 62443-4-2 component requirements CR 1.2 (Software process and device identification), CR 3.4 (Software and information integrity), and CR 7.6 (Network and security configuration settings) map one-to-one to attestation outputs.

For CIRCIA reporting, the primitive produces the chain-of-custody evidence required to substantiate incident scope, attribution, and remediation status within the statutory windows. The same evidence stream feeds the sector ISAC under E-ISAC, WaterISAC, ST-ISAC, or H-ISAC schemas, enabling the sector-wide composite assessment that the CISA coordination model assumes but that bolt-on stacks cannot deliver.

Adoption Pathway

Adoption proceeds in three phases aligned with sector procurement cycles. Phase one establishes the PUF-bound identity registry across the highest-criticality assets — bulk electric system Cyber Assets under NERC CIP-002, public water systems serving more than 100,000 people, Class I rail signaling, and Tier 1 hospital networks — producing a defensible asset inventory that satisfies CPG 1.A and BOD 23-01 within a single procurement cycle.

Phase two enables continuous attestation and SBOM gating on all new firmware deployments, leveraging the existing manufacturer relationships and the SBOM obligations now flowing through procurement language derived from EO 14028 and NDAA Section 1505. Operators who participate in CISA's Joint Cyber Defense Collaborative (JCDC) gain early access to threat indicators that can be evaluated against attestation streams in near-real-time.

Phase three extends governance-chain composition across the sector, federating attestation streams with the relevant ISAC and CISA itself under credentialed-observer roles. At full deployment, an operator can answer any CIRCIA, NERC CIP, or sector-specific audit question with a queryable, cryptographically-grounded evidence stream rather than a Bates-stamped PDF binder.