The short version
- Under every cloud estate is a control network: building management, CRAC rows, chillers, UPS strings, switchgear. It speaks BACnet and Modbus, it is vendor maintained, and it is almost never in the CMDB.
- It is missing from inventories because it is owned by facilities, procured as a building system, and scoped out of the penetration test by a sentence nobody argues with.
- The cloud estate frequently reaches it anyway, usually through a monitoring integration somebody built for good reasons, and the resulting path is short because that layer exists to be touched.
- The consequence is not measured in compromised hosts. It is measured in thermal margin and capacity, which is the unit your business already uses to plan.
If you run platform or cloud security, the pitch for operational technology has probably never landed. You do not have turbines. Nobody on your team owns a PLC. The closest thing to a plant in your estate is a rack elevation diagram, and the physical layer is somebody else's contract.
That belief is the reason this path stays open. A data center is a process facility. It converts electricity and chilled water into compute, it does so within a narrow thermal envelope, and it is regulated by controllers that behave exactly like the ones in a substation because in many cases they are the same product lines.
What your compute stands on
Three layers, one dependency chain, two owners who rarely sit in the same meeting.
The middle layer is the interesting one. Power and cooling plant is physical enough that everyone treats it with respect. Cloud and platform is visible enough that it gets budget. The building management layer between them is software, it is networked, it is addressed, and it is usually the responsibility of whoever signed the contract for the building.
Why it is in no inventory
Four reasons, and none of them is negligence.
- It was procured as a building. Chillers and their controls arrived as part of a fit-out, on a construction schedule, under a capital budget. Nothing about that process produces a CMDB entry.
- It is maintained by the vendor. The integrator has remote access because the service agreement requires it, which also means no internal team has ever had to learn the system well enough to document it.
- It is scoped out. Most penetration test statements of work exclude building systems, usually with a sentence about availability risk that is entirely reasonable and entirely load bearing.
- Discovery tooling avoids it. Your scanners are tuned not to touch it, for good reason, so it does not appear in the output that feeds your asset picture.
The result is a networked control system inside your blast radius that has never appeared in a review, and an asset inventory that is complete with respect to everything it was ever pointed at.
How the cloud estate reaches down
Almost always through something built for a sensible reason. Somebody wanted rack-level temperature on a dashboard, or wanted an alert when a UPS went to battery, or wanted to correlate a latency incident with an inlet temperature spike. So a collector was stood up, it was given network reach into the building network, and it was given an identity in the cloud tenant so it could publish metrics.
The last hop is the one worth sitting with. BACnet/IP, which most building networks speak on UDP 47808, has no meaningful authentication in the deployments you will actually meet. A write to a setpoint is not an exploit. It is the protocol working correctly, in exactly the way the unsigned Modbus write in our substation path study was the protocol working correctly.
Nobody needs a vulnerability to raise a setpoint. They need reachability and a protocol that was designed when the network was a locked room.
Consequence in the units the business uses
Security teams report incidents in hosts, accounts and records. Infrastructure is planned in megawatts, racks and thermal margin. When an incident lands on the physical layer, the second set of units is the one that matters, and a security programme that cannot speak them will lose the prioritisation argument to a patching backlog.
This is why the graph that matters carries a consequence edge from a controller to the physical function it drives. A finding that says a monitoring identity can reach a BMS server is a medium severity item that will sit in a queue. A finding that says the same identity can derate a row is a capacity risk, and capacity risk has an owner with a budget.
Why facilities and security disagree
It is worth understanding the other side of this before walking into the conversation. Facilities teams are measured on uptime and they have learned, correctly, that unplanned network changes are how uptime dies. They have watched a discovery scan knock over a controller. When they resist adding your agent, your scanner and your EDR to the building network, they are defending the thing you also want.
Which is why the first move into this layer should be passive. Observation, configuration analysis and reachability derived from the network and identity configuration answer most of the question without sending a single packet toward a controller. It is also the only opening position that a facilities engineer can say yes to.
What to map first
If you own cloud infrastructure and have never looked below the floor, this is a week of work, not a program.
- Find the collectors. Every integration that publishes environmental data to a cloud dashboard is a bridge. List them, and for each one find the credential it uses on the building side.
- Ask who can reach 47808. Not who should. Pull the firewall and routing configuration and derive the answer, which is a read-only exercise nobody can object to.
- Name an owner per control system. The BMS, the UPS management, the switchgear controls. If the answer is a vendor, that is your finding.
- Write the consequence down. For each controller, what physically happens if it is written to. Facilities already knows. Nobody has ever asked them to put it in a security artefact.
- Then decide about active testing, per the execution levels we described for plants. A twin of a cooling loop is cheaper than an outage, and the rules do not change because the process happens to be your own.
The argument for doing this now is not that an adversary is already in your building network. It is that the AI build-out has made power and cooling the binding constraint on your capacity plan, and a layer that constrains the business is a layer that belongs in your terrain graph rather than in somebody's facilities folder.