OT & IoT Cybersecurity

Cybersecurity as most people know it is IT security - protecting laptops, email, servers and data, where the priority order is roughly confidentiality, integrity, availability. Building systems live in a different world called OT (operational technology): the controllers, sensors and actuators that physically run the plant. In OT the priority order flips - availability and safety come first. A chiller controller that reboots for a security patch at the wrong moment can cook a data centre; a door controller that fails shut can trap people. You cannot simply apply IT habits to OT.

The consequences are physical. An IT breach leaks data; an OT breach can open a barrier, disable smoke control, freeze a hospital ward or hold a building to ransom. OT devices also live for decades - a BACnet or Modbus controller installed in 2008 may still be running, unpatched, with a default password, speaking a protocol that has no built-in authentication or encryption. BACnet and Modbus were designed for trusted wires, not hostile networks. That combination - long-lived, rarely patched, weakly authenticated, and now connected - is exactly why building OT is a soft target. Understanding this difference is the first move: you are not securing a website, you are securing machinery that happens to have an IP address.

Every device you add is a door. Map the surface honestly: field devices (cameras, meters, PIR sensors) that may ship with hard-coded credentials; the field network speaking BACnet, Modbus or KNX with little native security; BMS controllers that run HVAC, access control and lifts; the cloud platform with its APIs and dashboards; and - often the weakest link - remote access, the VPN or vendor laptop that reaches straight into the OT zone for maintenance.

Attackers rarely kick down the front door. The classic path is lateral: a phishing email compromises an office PC, and because the office network was never truly separated from the building network, the intruder walks sideways into the BMS. Or an internet-facing camera with a factory password is found by an automated scanner in minutes - Shodan-style search engines catalogue exactly these exposed devices. The infamous 2013 retail breach that stole millions of card records began through an HVAC vendor's remote access. The lesson is not that HVAC is dangerous; it is that a building system connected to everything else, with weak credentials and no segmentation, becomes the softest way into the whole organisation. Naming every door is how you start to lock them.

There is no single product that makes a building secure. The governing idea is defence in depth: many independent layers, so that any one failure is contained rather than catastrophic. The most important layer for buildings is network segmentation - keeping the OT zone (BMS, controllers, field devices) on its own network, separated from the IT zone (email, office, internet) by a firewall and a DMZ where only specific, inspected data is allowed to cross. A compromised office laptop should have no route to a chiller controller.

Around that spine sit the other layers, roughly following the NIST Cybersecurity Framework functions - identify, protect, detect, respond, recover. Practical measures: an accurate asset inventory (you cannot protect what you do not know exists); changing default passwords and enforcing least-privilege access; patching where OT vendors permit, and compensating with isolation where they do not; monitoring OT traffic for anomalies; and a rehearsed incident-response plan so a breach is contained, not improvised. The Purdue model - a reference architecture that layers control networks into zones - is a common way to structure this. None of it is exotic; all of it is discipline. And crucially, it is designed in far more cheaply than bolted on.

Abstract risk becomes concrete when you trace an incident end to end. Consider the pattern behind the 2013 breach of a large US retailer, in which the payment-card data of tens of millions of customers was stolen. The intruders did not attack the tills directly. They first compromised an HVAC contractor through a phishing email, stole that contractor's remote-access credentials to the retailer's network, and - because the building/vendor network was not properly separated from the payment systems - moved laterally until they reached the point-of-sale devices. Every failure in that chain is a building-security failure the previous sections named: an over-trusted remote-access path, weak credential hygiene, and no segmentation to stop lateral movement.

Ransomware follows a similar script with a physical twist. Once inside an unsegmented network, attackers can encrypt the servers a BMS depends on, then demand payment to restore heating, cooling, access control or lifts - operations a hospital, data centre or campus cannot do without. The disruption is the leverage. Other incidents are cruder still: internet-connected controllers and cameras left on default passwords are catalogued by search engines like Shodan and compromised at scale by automated bots, with no targeting at all.

The common thread is not sophistication - it is neglect. In case after case the entry point was a soft, forgotten path: a vendor link, a default credential, a flat network. That is genuinely encouraging, because it means the highest-value defences are the unglamorous ones this module keeps returning to - inventory every device, segment the network, kill default passwords, govern remote access, monitor for anomalies, and rehearse a response. And it draws the professional boundary sharply: studying incidents to design a securable building is your job; forensic investigation, threat modelling and breach response are the work of qualified security professionals, who should be engaged before an incident, not summoned after one.

It is easy to slide into either denial (nobody would bother attacking our building) or panic (connect nothing, ever). Both are wrong. Attackers absolutely target buildings - for ransomware leverage, for a foothold into a bigger network, or occasionally to cause physical disruption - and the number of connected devices only grows. But the risk is manageable with ordinary rigour: segment, inventory, authenticate, monitor, and plan for incidents. A well-designed connected building can be safer than a fragmented one, because it is visible and governed rather than a sprawl of forgotten gadgets.

Where is the line for a designer or architect? You should understand the attack surface, insist that security is a requirement from day one, and make space in the design (segregated risers, network rooms, a security-capable integrator) for it to be done well. You should not sign off on the security architecture yourself. Penetration testing, threat modelling, firewall configuration and compliance are specialist work. Bring in a qualified OT security professional, name security in the brief and the contracts, and treat statutory and safety sign-off as theirs. Your contribution is to make the building securable - the deep technical assurance is theirs to give.

A useful mental model is the difference between designing a bank vault and certifying that it will withstand attack. An architect lays out the vault, its walls, its access routes and its place in the building - decisions that make a secure vault possible or impossible. A specialist then rates the door, tests the alarms and signs the guarantee. Connected buildings are the same: you shape whether security can be done well, through segregated networks, sensible topology and a security-literate integrator; the professional proves that it has been. Confuse the two roles - a designer certifying the security architecture, or a security firm dictating the building layout - and both jobs suffer. Keep them distinct, engage the specialist early rather than after a breach, and the connected building becomes not a liability but a well-governed asset.