Cyber-Physical & Destructive Attacks on OT/Facility Systems

Most of Part 11 defends the information in the building: model weights, tenant data, credentials. This chapter defends the building itself. An AI factory is a cyber-physical system. Tens of megawatts of synchronized silicon sit on a control plane of programmable logic controllers, building-management and electrical-power-management systems, coolant-distribution-unit firmware, battery-management systems, and a power-capping layer that the GPUs themselves obey. Every one of those is a computer, and whether an attacker can reach it has to be established from actual wiring, networks and maintenance paths. Beyond information loss, an attack on the OT plane can physically destroy the asset: damage equipment, trip the grid interconnection, contribute to battery hazards, or disable accelerators through an update path if the credited protections fail. The reachable control scope and the remaining protection layers set the blast radius, and damaged equipment can put long-lead replacement on the recovery path.

The sections that follow cover the OT assets and their security levels, the destructive primitives the control plane exposes and what each costs, the segmentation boundary (the Purdue model and IEC 62443 zones and conduits), and how the project hazard and risk analysis allocates each protection function: process control, OEM protection, dedicated relays, mechanical relief, fire and life safety, and, where the safety lifecycle requires it, a safety instrumented function. The aim is that no single compromised control domain can defeat every credited layer. Ask of each Appendix-F failure mode whether an attacker can reach it, because the transient you engineer against as a random fault is also the attacker's payload, and the attacker picks the timing.

Start by enumerating the control planes, because each is a distinct attack surface with a distinct destructive payload. The BMS (building-management system) can command cooling setpoints, valves, pumps, air handlers and leak detection, and it interfaces with fire/EPO systems whose authority and independent protection you must verify. The EPMS (electrical-power-management system) monitors electrical state and may command breakers, transfer switches, generator start/stop and UPS modes where the design grants it that authority. SCADA/PLC layers sit under both and execute the actual I/O. CDU controllers regulate the technology-cooling loop (flow, inlet temperature, secondary-loop pressure) that keeps a GB300 NVL72-class rack (up to 142 kW in NVIDIA's reference architecture) from cooking itself. BESS management (battery-management systems and their EMS) governs charge/discharge, cell balancing and the thermal-runaway protections on grid-scale storage. DCIM and power-monitoring platforms, and the network cards in UPSs and PDUs, aggregate privileged access to electrical and cooling equipment. Schneider's Data Center Expert 9.1.2 and earlier, for example, carried privileged-account SSRF and argument-injection flaws (CVSS 4.0 8.6) fixed in 9.2 in September 2026. The patch restarts the service, so plan monitoring continuity during OT patching. Finally, the power-cap and firmware planes, the GPU/BMC layer that throttles and updates accelerators at fleet scale, need the same command-authorization and failure-containment analysis as the older controllers.

Published exposure studies justify testing these paths. In 2025 Claroty Team82 analyzed roughly 467,000 building-management devices across 529 organizations. It found 75% of organizations ran BMS affected by known-exploited vulnerabilities (KEVs), and 51% were exposed to KEVs that are both ransomware-linked and insecurely connected to the internet (Claroty Team82, State of CPS Security 2025: BMS Exposures). Those are cross-industry, organization-level results. The data-center cut followed on 2026-07-29, when Team82 analyzed more than 750,000 CPS assets across the world's largest data-center facilities. Nearly 1 in 5 infrastructure assets (18%, 32,000+ of 174,577) sat one hop from a system making risky outbound connections to the public internet. 88% of BMS communicated over insecure protocols and 40% ran outdated firmware. PDUs (41%) and HVAC/cooling (32%) were the most-exposed classes, and more than 80% of OT control, power-monitoring and IoT systems spoke BACnet/Modbus-class legacy protocols (Claroty Team82, State of CPS Security: Data Center Exposures). The population is the studied facilities, not this campus's measured exposure.

The same team found two CVSS 9.8 flaws in Vertiv Liebert IS-UNITY-DP and RDU101 UPS network cards (CVE-2025-46412, CVE-2025-41426). CISA published them in advisory ICSA-25-140-10 in May 2025, with fixes in RDU101 v1.9.1.2 and IS-UNITY v8.4.3.1, and Team82 released its attack write-up in June 2026. Any card still unpatched has missed a fix that has been available since May 2025. In June 2026 Team82 also disclosed a five-CVE chain in the Trane Tracer SC+ HVAC controller up to v5.20.1362, fixed in v6.3. Both are specific data-center products, not generic BMS.

This is the part of the threat model unique to AI factories, and it is where the destructive primitives concentrate. Four are worth naming, each with its downstream cost.

The forced synchronized load step → grid trip. A large training cluster already swings load by tens of megawatts when a job starts, stops or stalls (Meta measured this while training Llama 3 405B on up to 16,384 H100s), and the step grows with GPU count. That is the random-fault problem Chapter 4.5 engineers ride-through against. Now make it the payload. An attacker who controls the power-cap plane (or simply the scheduler) can command thousands of racks to drop or pick up load simultaneously, deliberately, at the moment of peak grid stress. NERC has already flagged the non-malicious version as a reliability crisis. In the July 2024 Northern Virginia incident, a permanent 230-kV transmission-line fault and staggered auto-reclosing produced six successive system faults over 82 seconds. Roughly 1,500 MW of data-center load reduced coincident with the disturbance, and about 1,260 MW dropped at the third voltage depression and stayed off for hours (NERC). It was not an isolated event. NERC has documented repeated 1,000+ MW computational-load losses since 2022, and on May 4 2026, about 22 months after the Virginia event, it issued a rare Level 3 "Essential Actions" alert over the pattern. The alert is addressed to transmission planners, owners and operators, planning coordinators, balancing authorities and reliability coordinators, and its Essential Actions are not mandatory. The largest event so far came on 22 July 2026 in Ashburn, where about 3.8 GW of load moved to backup on one normally cleared 230 kV fault, roughly 2.5 times the 2024 scale, and the bulk system held (PJM). Large-load ride-through rules are already in force in ERCOT (NOGRR282) and SPP. PJM proposed its own on 8 September 2026 and plans to file them at FERC in November 2026, and NERC's computational-load standards passed final ballot in October 2026 but set no ride-through curve (Chapter 4.10 tracks the status).

Weaponized, the same primitive is a way to trip the interconnection or destabilize the local grid, and the facility's own protection relays may disconnect it, putting the campus on backup generation. The bill is generator fuel and run-hours, possible lost jobs on any load without UPS, and a wait for the utility to approve reconnection. Relations with the utility that controls your interconnection suffer as well. A grid-wide black-start would be a tail outcome, and neither documented load-loss event produced one. The limiter itself is exposed. On GB300, NVIDIA's power smoothing (floor power, ramp-down rate) takes its settings from nvidia-smi or Redfish, the same interfaces an attacker would use to command a step. Put access control, change logs and alerts on those settings. They live on the plane the attacker holds, though, so the independent layer has to be a ramp-rate limit enforced outside it.

CDU disablement → hall-wide thermal trip. An attacker who stops the CDU pumps, closes a facility-water valve, or falsifies the inlet-temperature reading so the controller never opens the valve, drives the hall into hardware thermal slowdown and shutdown. How fast depends on the rack. Take the response of an NVL72-class liquid-cooled rack after CDU flow loss (throttle, controlled shutdown, emergency shutdown or trip) from your OEM's transient data, controls tests or a professional-engineering calculation. Do not borrow a seconds-to-tens-of-seconds figure from chilled-water inertia: a cold-plate loop holds little stored cooling. The GPUs' own temperature thresholds trip them independently of the BMS, so the likely result is a hall-wide outage. Damage to cold plates or silicon becomes likely only if the GPU and BMC thermal protections are also defeated through the firmware plane, or if pressure transients or leaks damage the loop.

BESS-induced runaway. Grid-scale and UPS-class battery storage protects against thermal runaway through the BMS: cell balancing, over-temperature trips and isolation. Compromise that management layer and an attacker can disable the protection that prevents a runaway, force an over-charge or over-discharge, or suppress the thermal alarm, turning the storage asset into an ignition source inside the building.

GPU-bricking via malicious firmware. The fleet firmware-update path (BMC, GPU VBIOS, NVLink-switch firmware) is a fleet-scale destructive primitive. A single malicious image pushed through the legitimate update channel can leave thousands of accelerators non-functional or subtly misbehaving. Firmware integrity (signed images, a hardware root of trust, measured boot) is therefore the gate on the most expensive single payload in the building. Chapter 11.4 is the canonical home for that integrity chain; here it is one of four ways the control plane bricks the asset.

The highest-leverage control against all of the above is the oldest one: keep the control plane off the corporate network and off the internet. The Purdue model stratifies the estate into levels: physical process (0), basic control / PLCs (1), supervisory / SCADA-HMI (2), operations / MES (3), then the DMZ (3.5) and enterprise IT (4–5). Traffic crosses level boundaries only through controlled, inspected conduits, never directly. Use IEC 62443-2-1:2024 for the asset-owner program and IEC 62443-3-2:2020 for system-design security risk assessment. The latter scopes zones and conduits and their target security levels; a network layout alone does not establish conformance. The standard's SL scale is defined by attacker capability: SL1 casual or coincidental, SL2 intentional with simple means, SL3 sophisticated with moderate resources, SL4 sophisticated with extended resources (usually the capability of state actors) (ISA/IEC 62443). Guarding against a capable, well-resourced attacker on the destructive primitives above usually pushes the zone risk assessment to a target of SL3–SL4. Those are 62443's levels, not the RAND Weights Security Levels of Chapter 11.1. An internet-reachable BMS shows that a zone's achieved protection has drifted from its assessed target; it does not by itself set a level.

Two architectures pull against each other here. Convergence, running OT on the same IP fabric as IT with shared identity and shared monitoring, is operationally attractive: one network team, one observability stack, and remote vendor access for the cooling and electrical contractors who maintain the gear. Isolation, an air-gapped or diode-separated OT network with its own identity, jump-hosts and one-way telemetry export, is far harder to operate and far harder to compromise. For an AI campus the practical middle is a hardened DMZ with brokered, recorded, time-boxed vendor access and unidirectional telemetry out, sized so that an IT compromise cannot reach a Level-1 controller and a controller cannot reach the internet. Put the access model in the integrator contract. Integrators should reach equipment only over routes the operator can monitor, says the FBI and CISA fact sheet on third-party ICS integrators (September 2026). Operators should also get an inventory of all supplied hardware and software, with how each piece connects and how it will be updated. The sheet also wants enough in-house engineering support to cut how often the integrator must intervene, offline copies of every program the equipment needs to run, and drilled manual operation and recovery. Chapter 11.7 covers the microsegmentation and zero-trust mechanics that enforce this. This chapter's contribution is the consequence of getting it wrong, which is the destructive-primitive table above.

Put protocol security in the same integrator and equipment contracts. Classic Modbus TCP and BACnet/IP carry no authentication, so anyone who reaches the port can read values and issue writes. Both now have secure versions. BACnet Secure Connect (BACnet/SC, ASHRAE 135-2020, from Addendum bj) carries BACnet over WebSockets and TLS with certificate-based device authentication, and the Modbus Organization's Modbus Security Protocol wraps Modbus in TLS with X.509v3 certificates on port 802. Require them in BMS, CDU and EPMS specifications wherever the vendor supports them, and put legacy-only devices behind protocol-aware gateways in their own zone. The cost is a certificate lifecycle: issuing, renewing and revoking device certificates becomes an OT operations task, and an expired certificate can cut a controller off from its supervisor. Secure transport stops an outsider's spoofed or replayed writes. It does not stop a compromised engineering workstation that holds valid credentials, so the independent protection layers below still carry the destructive cases.

Match each IEC 62443 document to the party and assertion it covers. 62443-3-3:2013 supplies system security requirements; 62443-2-4:2023 addresses integration and maintenance service-provider processes. 62443-4-1:2018 addresses the product development lifecycle; 62443-4-2:2019, including its 2022 corrigendum, addresses component technical capabilities. Keep the target security requirements (SL-T), the demonstrated system result and the component capability (SL-C) separate. A component certificate does not establish the target or achieved protection of the assembled cooling or power system. The owner keeps the system risk and the integration test results, even when suppliers provide certified components.

Start with the project hazard and risk analysis and the applicable process, electrical, fire/life-safety, equipment and cybersecurity requirements. Allocate each protective function to the architecture that meets its required integrity and consequence: basic or process control, an OEM protective function, a dedicated relay, mechanical relief, fire/life-safety control, or, where the safety lifecycle requires it, a safety instrumented function (SIF) implemented by an SIS. An SIS is not the default home for every equipment trip. For an allocated SIF, IEC 61511 / ISA-84 lifecycle principles require the necessary independence, integrity, diagnostics, proof testing, management of change and controlled bypasses. 'Independent' is a designed and verified claim, not a promise that software can never defeat the function.

The 2017 Triton/Trisis attack showed that a safety layer can itself be targeted and reprogrammed. Use the project cyber/process hazard analysis to identify common dependencies, communications and maintenance paths, privileged access, sensor and final-element diversity, power, bypasses and proof-test coverage. Separate or diversify protection where the required risk reduction demands it, secure and monitor authorized maintenance paths, and keep other independent or passive layers where one digital protection system cannot carry the consequence alone. The correct boundary is project-specific. Neither 'hardwire every trip' nor 'the SIS is impossible to defeat' is a defensible universal rule.

Run one reframing through your entire FMEA: each failure mode in the Appendix-F catalog has two possible causes, and the second needs a cyber-reachability assessment. One is randomness: a pump fails, a valve sticks, a relay chatters, a job crashes and the load steps. The other is an attacker who may induce a similar physical consequence through a different command or persistence path, with three advantages the random fault does not have. Timing: at peak grid stress, during a maintenance window, when redundancy is degraded. Correlation: across many units at once, defeating the N+1 that assumed independent failures. Persistence: re-triggering as fast as you recover.

This breaks a core assumption of classical reliability engineering. Simple independence calculations in Chapter 0.5 and Part 12 must be supplemented by common-cause models. A cyber-physical attacker deliberately violates independence: a single compromised controller can trip every CDU in a hall at once, and the 'redundant' second pump on the same compromised PLC is no redundancy at all. So fault domains must also be security domains. Identify whether the controller that can fail unit A also reaches unit B or their shared protection, and allocate the required independence and diversity from the project hazard and cyber-risk analysis.

Prevention is the priority, but the OT plane also needs detection that a converged SOC can act on. Map detections to MITRE ATT&CK for ICS so coverage can be counted (Chapter 11.12). The hard problem is that OT telemetry and IT telemetry live in different worlds. A falsified Modbus write looks like a legitimate engineering command, and the signal that separates attack from operation is often physical: a setpoint that contradicts the measured process state, a valve commanded closed while temperature climbs, a load step with no scheduling event behind it. So the detection that matters here is cyber-physical correlation: cross-checking commanded state against sensed state against expected workload, and treating divergence as an incident.

The organizational failure mode is facilities and security each assuming the other is watching the controllers, a gap attackers can use. Close it with a converged cyber-physical escalation trigger. One condition, an anomalous OT command plus an adverse physical trend, pages the SOC and facilities engineering at the same time and opens a joint playbook. Neither team alone can diagnose a CDU disablement that is driving a hall into thermal trip. The unified incident-command model this escalation feeds into is canonical in Chapter 14.11, and the OT/cyber-physical IR playbook itself is built out in Chapter 11.12. This chapter's job is to insist the trigger exists and is wired to the physics, not just to the logs.

The decisions in this chapter sort into two groups: those you cannot reverse after design, and those that stay operational. The irreversible ones are which protection functions belong to process/OEM, electrical/fire, mechanical or SIS layers and what independence each requires, how the OT network is segmented from IT, and whether fault domains are also security domains. Make them before you commission, because retrofitting an independent safety layer or re-segmenting a live OT network mid-life is brutal and sometimes impossible. The operational ones are vendor access brokering, firmware governance cadence, OT detection content and the converged escalation drill. They are ongoing and improvable. The recurring mistake is treating an irreversible decision as operational: assuming you can 'add a safety system later' to a hall whose trips already live inside the hackable BMS. Retrofitting may be possible, but its outage, redesign and safety-validation cost can dominate the original design choice. Assign the protection functions and verify common dependencies before commissioning, then keep their bypass records and recovery test results current in service.