The Forgotten OT: Building Automation and the Attack Surface No One Owns
Ask an OT security team what runs on their facility’s network, and they can usually name the plant floor: the PLCs, the HMIs, the engineering workstations, the historian. Ask what talks to the building management system — the HVAC controllers, the lighting panels, the access-control readers, the fire-alarm gateways — and the answer is often a pause, then a shrug. That’s somebody else’s problem. Facilities owns the building. IT owns the network. Nobody owns the building’s OT.
On 13 August 2026, CISA published a batch of ICS advisories that made the cost of that shrug concrete. Two of them concerned building automation systems — the infrastructure that keeps a facility habitable and secure — and neither vulnerability would be caught by the tools most organisations point at their OT.
What is building automation, and why is it OT?
Building automation systems (BAS) are the networked controllers that manage HVAC, lighting, access control, and — increasingly — fire and life-safety functions. They read sensors (temperature, occupancy, CO₂, door position), execute control loops (heat, cool, lock, unlock), and report status up to a management workstation.
None of that sounds “industrial” until you look at how it actually works. A Siemens Desigo DXR2 room controller is a field device: it sits at Level 0/1 of the Purdue model, wired to sensors and actuators, and it speaks BACnet over IP to its siblings and to a supervisory controller. A Johnson Controls Metasys server is a supervisory control and data platform — it schedules setpoints, logs alarms, and pushes configuration down to the field controllers. In architectural terms, that is a SCADA system. It is OT by every definition that matters; it just happens to control a building instead of a production line.
Why do building automation systems go unmonitored?
Three reasons, and they compound.
First, ownership. BAS is typically procured, installed, and maintained by a facilities or real-estate team whose mandate is comfort and cost, not cybersecurity. The OT security team’s mandate is process safety and availability — and the building usually isn’t in that scope.
Second, position. BAS networks are frequently bridged to the corporate network so that facilities software, energy dashboards, and vendor remote support can reach them. That puts a Level 0/1 device one or two hops from the endpoints the IT team does watch — but IT doesn’t monitor BACnet traffic, because that’s “not our protocol.”
Third, visibility. BACnet is a control protocol, not a data-centre protocol. Most network monitoring sees a stream of UDP packets on port 47808 and labels it “noise.” The baseline of what is normal between a controller and its management server — who initiates, when, how often, what a malformed packet looks like — is never established.
The result is a structurally invisible attack surface: real control systems, reachable from the corporate network, monitored by no one.
What do the two new advisories actually say?
The two advisories are worth reading because each demonstrates a different failure mode of the same blind spot.
The first, affecting Siemens Desigo DXR and PXC controllers (CVE-2026-59693), is a denial-of-service condition triggered by a malformed BACnet packet. Send a crafted packet and the controller stops responding to BACnet queries until someone resets or reboots it. CISA rates it a modest 4.3 — but consider the effect in context. A building controller that stops answering is not a nuisance: HVAC stops, access control drops into fail-safe, and a facilities team physically walks the building resetting devices. The weakness class is literally “improper check for unusual or exceptional conditions” — the controller fails to handle a packet that falls outside what it expects. That is precisely the class of failure a signature-based tool cannot anticipate, because there is no known-bad artifact, only a packet that is slightly wrong.
The second, affecting Johnson Controls Metasys (CVE-2026-34491), is more serious and more instructive. It is a stored cross-site scripting flaw, rated 8.0 in CISA’s advisory. A low-privileged user can inject a malicious payload through a crafted URL; the payload persists across logins and then executes in the browser session of whoever logs in next — including an administrator. The consequence, as CISA puts it, is session hijacking and unauthorized access.
Read that attack path. No malware. No exploit of a PLC. Just a crafted URL that turns one low-privileged account into an administrator’s session — and from there, the ability to reconfigure building controllers from the same console the facilities team trusts.
What does this tell us about the nature of the risk?
Both advisories sit on the same uncomfortable line that defines modern OT risk: the boundary between “legitimate” and “malicious.”
A malformed BACnet packet is not a payload; it’s a packet that’s slightly wrong. A stored XSS is not a signature; it’s an input that was never neutralized. The low-privileged user who injects it is, to every log in the building, an authorized user doing authorized-looking things. There is no hash to blacklist, no domain to block, no indicator of compromise that predates the attack. In both cases, the threat is defined by behaviour that deviates from normal — not by an artifact that matches a known pattern.
What would these attacks look like to passive detection?
This is where the blind spot closes.
A network detection platform that passively learns what normal looks like — without touching the controllers, without injecting test traffic — can flag both of these attacks without knowing either CVE exists.
For the Desigo DoS, the normal BACnet baseline for a controller is narrow and predictable: a heartbeat, a small set of peer devices, occasional configuration writes. A burst of malformed packets from a host that has never spoken BACnet before is a deviation. And the controller’s sudden silence afterwards — a device that was answering and now is not — is another. Both are visible the moment they happen, not when a vendor ships a patch.
For the Metasys XSS, the baseline is about who does what. A low-privileged account whose session suddenly performs administrator-grade actions — reconfiguring controllers, changing schedules, exporting the configuration — is a behavioural anomaly regardless of how the privilege escalation happened. The payload itself may be invisible; the behaviour it enables is not.
Neither signal depends on signatures. Neither depends on the vendor having disclosed the flaw. Both depend on one thing only: that someone established what normal looked like before the anomaly arrived.
The takeaway
Building automation is the OT that most organisations forgot to treat as OT. It controls the physical environment, it sits at the edge of the corporate network, and — as the 13 August advisories show — it carries real, exploitable vulnerabilities. The fix is not to hand the BAS to yet another team, and it is not to wait for the next advisory. It is to treat it like the control system it is: establish a behavioural baseline, watch the traffic, and flag the deviation — whether that deviation is a malformed BACnet packet or a low-privileged user doing an administrator’s work.
A clear-eyed look at the ownership gap makes the same point from the other direction: nobody is watching the building today. The question is whether you’ll be the organisation that starts.
Maigadi — the OT/ICS network detection & response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.
Maigadi Networks provides passive, signature-less network detection & response for OT/ICS environments. We help operators see what their industrial networks are actually doing — on-premise, explainable, and sovereign by design.