EN
PL
Building automation is often a cybersecurity gap
During a conversation with a large customer's cybersecurity team, someone asked a question that should be asked far more often: why does building automation run on protocols with no encryption?
The moment the security officer was right
It was a stressful moment — because the last thing you want is the handover certificate held up by objections from IT and cybersecurity. It was also an instructive one, because he was right.
We live in strange times. You no longer need Ethan Hunt's flair to imagine that clipping onto a cable next to a fan coil unit and probing the network for holes might actually be worth someone's while.
Modbus/TCP is thirty years old and knows nothing about encryption
In this respect, building automation has fallen a long way behind the IT world. Modbus/TCP — one of the most widely used protocols — is around thirty years old and by design provides neither authentication nor encryption. It was built for a closed, trusted industrial network, not for a world in which every network segment has to be treated as potentially hostile.
For as long as a protocol like that stays in use, it has to be treated as a security gap — no matter how well it performs on the control side.
Segregation is standard, but it is not enough on its own
Galvanically separating the automation network from the customer's network is standard practice by now — hardly anyone would think of routing that traffic across the corporate LAN. That does not close the subject, though. Inside the automation segment itself, an unencrypted protocol remains the weak point.
That is why the right approach is to convert Modbus into something safer as close to the device as possible — so that sensitive, unencrypted traffic covers the shortest possible stretch.
A quantifiable cost against an unquantifiable risk
This approach adds something to the cost of the investment. But it is a cost you can calculate — and it is incomparably lower than the cost of an incident that ends up on the front page of the news sites.
Cybersecurity in building automation is not an add-on bolted on after go-live. It is either designed in from the start, or it has to be made up for expensively later — usually at the moment the customer's auditor asks about it.
Building automation often rests on unencrypted, thirty-year-old protocols such as Modbus/TCP — a real security gap that has to be closed by segregating the network and converting to a safer protocol as close to the device as possible.
Percee was designed as a segregated, hardened system all the way down to the level at which it talks to the automation — which is why it passes the cybersecurity audits of demanding customers, including banking and industrial clients. OT security is part of the architecture here, not an add-on bolted on after go-live.
See how Percee works →