The checklist problem behind critical infrastructure cyber safety
An asset owner can meet major federal cyber compliance standards and still run equipment that lacks the engineering to withstand an attack or a failure. New research from George Mason University examines how United States cyber policy defines reasonable care for systems that control physical processes, and it finds that compliance has become a stand-in for safety.
The work covers operational technology in critical infrastructure: industrial controls, medical devices, transportation systems, and building automation, where a software failure can produce physical harm. Its argument centers on a gap between data-centric IT security and the physics of the systems that policy now governs the same way.
Security controls that introduced physical hazards
A 2025 survey conducted by Merrill Research found that 69% of defense contractors claimed compliance with NIST SP 800-171. Only 30% passed a verified assessment. Compliance records and engineering quality have moved apart, and the documentation continues to stand in for the safety it was meant to certify.
The paper documents cases where a control meant to protect a system produced a physical hazard.
Account lockout policies guard against brute-force attacks. In 2023, restrictive lockouts on KNX building devices denied operators access during emergency conditions. Fail-secure electronic locks guard against theft. Electronic door latches failed during fires, trapped occupants, and contributed to deaths linked to egress failures. Automated patching remediates vulnerabilities. Flawed patches on Advantech WebAccess introduced authentication bypasses and forced unplanned SCADA downtime. Encryption protects data confidentiality. TLS handshakes added latency above the sub-100-millisecond budgets that real-time safety loops depend on.
IT security often enforces fail-secure behavior, locking a system down to protect data. Physical systems often require fail-safe behavior, such as venting pressure or keeping manual overrides available. These objectives can conflict, and in the documented cases the compliant control created the hazard.
Where policy obligations concentrate
George Mason researchers coded a corpus of 292 critical-infrastructure policy documents issued between 2000 and 2025 against the four phases of the NIST SP 800-160 Vol. 2 resilience lifecycle: anticipate, withstand, recover, and adapt.
Obligations concentrate in the anticipate phase and center on administrative compliance: plans, workforce codes, and documentation. The withstand phase relies on delegation. Of the withstand obligations, 87% point to external technical standards for their requirements. Most of those pointers, 61%, reference generic IT control catalogs such as NIST SP 800-53. Those catalogs enforce confidentiality measures such as logging and password rules. They omit the hazard analysis that physical systems require.
Recovery requirements center on notification
For cyber-physical systems, the corpus holds eight recovery obligations, and seven of them ask for the same thing: pick up the phone and tell the government a failure happened. That is the whole duty. Report the incident, follow your continuity plan, and you have satisfied your recovery requirements.
The harder question, whether the system can settle into a safe state on its own once its digital layer goes dark, sits outside what policy asks for. An operator can check every recovery box and still own equipment that has no engineered way back to safety.
Resilience depends on the governing regulator
Whether a system has to be resilient comes down to which agency oversees it. Run a dam, and the Federal Energy Regulatory Commission holds you to hard engineering requirements. Run a railroad, and an earlier TSA security directive told you to segment your network. Operate under general cyber policy, and the requirement amounts to keeping a plan on file.
The 2024 TSA Surface Cyber Risk Management proposal swapped the rail segmentation mandate for a performance-based program built on corrective action plans, which softens the engineering obligation into a documented remediation process.
A proposed engineering standard
The paper proposes redefining reasonable care around engineering evidence and calls for three measures.
The first is hazard-specific traceability that shows a given control was selected to mitigate an identified physical consequence. The second is structured assurance cases, such as those in ISO/IEC/IEEE 15026-2, that connect recovery obligations to engineering work. The third is cyber-resiliency engineering that mandates non-digital fallbacks such as mechanical interlocks and analog governors, which hold a safe state through a compromise.
Resilient architectures cost more to build and operate than converged IT networks. The authors propose a federal incentive program to subsidize segmentation, out-of-band recovery, and hardware-enforced isolation.
Liability and the standard of care
This lands squarely on liability. When something goes wrong, courts and regulators ask whether you exercised reasonable care, and that standard decides who ends up on the hook. For systems that can hurt people, meeting it will mean showing engineering evidence that the system fails safe, well beyond a binder proving the controls were installed. The question shifts from “is the firewall installed?” to “will the plant fail safe when the firewall is breached?”
The study has limits. It codes the frequency of requirements in regulatory text, and measurement of operator implementation stays outside its scope. The corpus skews toward defense and national-security issuances.
Apply now: Simplify security management with CIS SecureSuite Platform