Speaking in Tongues: A forewarning on the fragility of data center building management systems
Niagara solved interoperability between data center systems; but it exposed every hyperscaler to a ludicrous hidden risk. Here’s an overview of how operators could build their own proprietary versions
I’m going to start this one with a nod to scorched earth policy (or strategic paralysis). That’s the military strategy where in a war, the first targets are the infrastructure, and anything else your enemy needs to fight a war.
There’s a reason this is important in data centers, as there’s a huge amount of them running the same system which underpins the functioning of an entire portfolio. We call it BMS (Building Management System) and EPMS (Electrical Power Monitoring System) – think of it as the central brain that controls all of the electrical power and mechanical cooling systems in data centers. The company behind the dominant version of that idea is Tridium, and the product is called Niagara. It’s been sold for twenty years as the solution that solved vendor lock-in in building controls.
Open And Shut
Before Niagara, buying a building management system meant marrying a vendor. Honeywell, Siemens, Johnson Controls; whoever you picked, every device and every future upgrade had to come from them, because their system couldn’t talk to anyone else’s. Want to switch suppliers later? You couldn’t, not without ripping the install out. That’s the problem Niagara solved; it sits above the hardware and normalizes everything, BACnet, Modbus, LonWorks, whatever protocol a given chiller or VFD happens to speak, into one internal format it can read consistently. A facilities team could suddenly mix vendors freely and still run one dashboard.
It’s popularity and rate of adoption is a case in point of the industry’s continued desire for (and subsequent reliance on) it. It’s vast deployment has created a huge systemic risk though – funnily enough, their solution didn’t remove the vendor lock-in, it just moved it up a layer, from the hardware manufacturers onto themselves.
What this is to suggest, is that you’re no longer married to one hardware vendor, but you are now married to Tridium. Ironically, Tridium was bought by one of the hardware manufacturers (Honeywell) in 2005. I’ve always thought the marketing of it as a bit of smoke-and-mirrors -it’s marketing as being an open model, but if you sign up, you’re actually running their licensed, closed codebase that’s just very good at behaving like an open one. Ask a facilities engineer what “open protocol” means in Niagara and they’ll talk you through BACnet compliance. Ask what happens if Tridium ships a bad update to the framework itself, and the conversation usually stalls, because it’s doesn’t seem to be a topic that’s been particularly well interrogated.
It should be. Niagara isn’t just a niche product, it’s the default supervisory layer across a huge share of commercial buildings, data centers, hospitals and manufacturing plants worldwide.I understand the engineering mindset behind it, but in reality it’s a pure description of exposure – and comes back to our scorched earth argument from the beginning.
If someone wanted to take down the world, just take down Tridium or Niagara.There’s no data in specific on it, but it’s rumoured that nearly every hyperscaler uses it – which is effectively nearly the whole market share. And that’s not even considering the other infrastructure that also deploy it widely.
Falcon Down, Then What
We’ve already run this experiment once, just not in buildings. In July 2024, a single bad update pushed automatically to CrowdStrike Falcon, a security tool sitting on millions of Windows machines, that brought a huge slice of global IT to a standstill within hours. Airlines grounded flights. Hospitals cancelled procedures. Delta later sued CrowdStrike, whose defence was essentially that Delta’s own infrastructure was too brittle to recover fast, which is itself an admission of that brittleness absolutely exists in deployments at scale like this. Analysts have called this a digital monoculture problem ever since: when enough of the world standardises on the same software, a single flaw doesn’t stay contained, it cascades.
Now translate that into physical infrastructure rather than laptops. A CrowdStrike-style event on Windows locks people out of email. The same event inside a BMS framework running mechanical and electrical control across thousadns of buildings doesn’t lock anyone out of a dashboard, it potentially throws chillers, transfer switches and generators into an undefined state, all at once. We got a small, contained taste of the physical version in May 2026, when a cooling fault in a single AWS data center hall triggered automatic thermal shutdowns and took the better part of a day to fully recover, with knock-on effects hitting trading platforms and betting apps mid-event. That was one hall, and one mechanical fault; nothing to do with the control software itself. Multiply that by a bad Niagara update, or a cyberattack on it and you’re not looking at a bad afternoon. You’re looking at a physical, global outage with cooling and power as the failure mode instead of a login screen.
I’m not saying this is imminent, and I have no knowledge whatsoever on the security standards of Niagara – it’d be fairly safe to assume that it’s taken very seriously and monitored very closely. But I am saying the industry seem to have spent two decades optimising for interoperability, and comparatively little time asking what happens when the interoperability layer itself becomes the single point of failure.
Building Your Own Backbone
So if we continue with AWS what’s the alternative for an operator with their scale and AWS’s incentives? Build your own. Not because Niagara is badly engineered, but because creating something proprietary drops your risk exposure to a fraction of your competitors if done correctly.
This isn’t hypothetical for Amazon specifically. Every article briefly discussing AWS data center controls describes a similar architecture: a BMS controlling mechanical systems, an EPMS monitoring electrical ones, both talking to field devices over a mix of open and proprietary protocols, all fed back into two centralized operations centers in Virginia watching every AWS facility on earth around the clock. They’re already a company that treats control infrastructure the way it treats servers and networking: build it yourself rather than buy it off the shelf, because at this scale the economics and the risk profile both favour ownership.
But for the others, what would it take? Four things, roughly:
· A protocol abstraction layer that talks natively to BACnet, Modbus, proprietary chiller comms and whatever a given generator manufacturer decided to invent, without depending on a third party’s driver library.
· In-house controls engineering talent deep enough to build and patch that layer itself, which is the expensive, scarce part, not the licensing.
· Full ownership of the patch pipeline, so a firmware or framework change only ships once your own team has tested it against your own fleet, never on someone else’s schedule.
· And a commitment to carrying that cost indefinitely, because the entire appeal of a shared framework like Niagara is that someone else is continually absorbing the maintenance burden; give that up and you’re absorbing it forever.
I’ll caveat that none of that is going to be cheap to make. But cheap was never really the question; the question is whether concentrating control of your multi-billion DC portfolio to one external vendor is a risk worth trading for their licence fee (no public figures exist for the cost of Niagara licences – I’d assume millions, but could be more or less than that in practice).
Different Dialects, Same Room
We should be a little careful though, as the “just build it yourself” argument falls apart if you don’t think it through properly. Building a proprietary control layer doesn’t automatically make you safer. If you build one homogeneous system to replace Niagara, you’ve built a smaller monoculture with your own name on the licence, especially if it’s not comparable to Niagara – if it’s a weaker product, it could be more susceptible to cyberattacks.
The alternative is deliberate heterogeneity: different manufacturers, different protocol dialects, different underlying system architectures kept properly distinct across the fleet, so a vulnerability or bad patch hitting one hall’s chiller controls doesn’t have a clean path to every other hall on earth. Whether you build proprietary or stay on Niagara isn’t really the question worth arguing over; how much diversity survives underneath the surface is. An attacker or a bad update that compromises one control path shouldn’t result in them getting the keys to the whole estate.
The hard part is what that demands of the software sitting above it. It has to be completely indifferent to what it’s talking to underneath, normalising a dozen manufacturers’ quirks and comms standards into one identical operator experience, so whoever’s watching the dashboard in Herndon sees the same clean interface regardless of which vendor’s kit sits behind a given wall. That’s a harder problem than the one Niagara solves, because Niagara optimises for convenience; this version has to optimise for containment, preserving diversity at the control layer while erasing it entirely at the interface layer. Get that right and you keep the resilience of a fragmented fleet without asking your operations team to learn five different systems. Get it wrong and you’ve added complexity without adding safety, which is worse than doing nothing at all.
It can be done though; CANBUS has been used on a lot of industrial and agricultural machinery for many years. Each machinery manfufacturer produces their own products and solutions, but the CANBUS interface means they can all communicate flawlessly between each other. It’s not necessarily that straightforward, but it can be done – we standard cables and connectors to work between manufacturers, so there’s no reason the same rationale can’t be applied to the electrical and mechanical systems.
The Robot In The Room
There is a final argument that the risk that seems to be here may be very shortlived; as soon, the BMS and EPMS may just be rolled into a singular SCADA system.
Robotics is moving into data center operations fast: with testing and deployment of autonomous inspection robots doing thermal patrols, automated guided vehicles moving server racks, early deployment of robotic arms for hardware installation and cable management. The market forecasts for the continued rollout aren’t modest. If physical maintenance increasingly gets handled by robots rather than people, those robots need something to coordinate against: a control brain that’s fast, consistent and predictable across the whole estate. That points in exactly the opposite direction from everything I’ve argued. It points toward tighter integration, not more diversity. So is a diversified, deliberately fragmented control layer a properly resilient design, or a transitional idea autonomy is about to make obsolete? I don’t think that’s settled yet.
A few facts remain for now:
Niagara’s dominance is a real concentration risk, not a hypothetical one; the CrowdStrike outage is the proof of concept, just aimed at the wrong industry so far.
Building proprietary doesn’t solve anything on its own, it only helps if the replacement is deliberately heterogeneous rather than a second monoculture thats rebranded.
The uniform-interface problem is the actual engineering challenge: diversity underneath, with an identical front-end user experience on top.
Robotics could make this whole debate moot within a decade, and maybe much sooner than that
TH