BMS Cybersecurity for Connected Buildings

Ask a facilities director who owns cybersecurity for the chillers and you will usually get a pause. IT owns the corporate network. The BMS contractor owns the controls. In between sits a supervisory workstation running an operating system that stopped receiving security updates years ago, reachable through a remote-access tool opened for a commissioning visit and never closed. I have walked into estates where the BMS front end was the most exposed device in the organisation and nobody considered it their responsibility. This guide is about closing that gap.

The message up front: building operational technology is exposed not because of exotic vulnerabilities but because of ordinary neglect. Flat networks, unpatched supervisory servers, shared credentials, no asset inventory, and remote access left standing. The fix is unglamorous and it is sequenced by exposure: remove internet-facing interfaces first, then segment, then control access, then patch, then monitor. Doing those five things in that order beats any product purchase.

1. Why building OT is exposed in the first place

None of this is the result of incompetence. Building controls are exposed because of design choices that were reasonable when they were made, and because of an ownership vacuum nobody created deliberately. The usual contributing factors:

• Controllers are engineered for availability, not confidentiality. A field controller's job is to keep plant running for fifteen or twenty years with minimal intervention. Determinism, uptime and simplicity were the design goals; cryptography and audit logging add complexity and failure modes, so historically they were left out.
• The protocols were designed for trusted networks. BACnet and Modbus, in their long-established forms, assume anything able to reach the network is authorised to be there. Little or no built-in authentication was a sensible simplification for a dedicated cable run in a plant room, and becomes a serious problem once that network is bridged to anything else. Newer secure variants exist and vendor support varies considerably, so check what your devices implement rather than assuming.
• Installation is a project, not a lifecycle. The contractor commissions, hands over and leaves. There is rarely a standing obligation to patch and usually no budget line for it, so five years later the supervisory server is several major versions behind.
• Remote access gets opened and never closed. A specialist needed to fix a graphics issue, so access was set up for the afternoon. The route is still live. This is the most common serious finding in a controls assessment, and the easiest to fix.
• Default and shared credentials are the norm. Engineering tools ship with well-known defaults, site passwords get shared across every contractor who has ever attended, and one operator login serves four shifts. There is no attribution of who did what.
• The network is flat. At some point the BMS needed a reporting tool or a weather feed, and the simplest route was the same network as everything else. Once that happens, anything that compromises a laptop in the office can reach a controller in the basement.

If these systems are new to you, the building automation systems explainer and the complete BMS guide set out the architecture this article assumes.

2. The realistic threat model for a building

Conference presentations lead with the sophisticated targeted attack: a capable adversary studying your plant, manipulating setpoints to damage equipment or endanger occupants. That is real and deserves attention in high-consequence facilities, but it is not what most estates should plan around first. The realistic threat model for an ordinary commercial or institutional building is more mundane.

• Commodity ransomware reaching a flat network. Someone opens an attachment on a corporate laptop and the malware spreads across everything reachable, which on a flat network includes the BMS supervisory server and the historian. Your building was not targeted, it was in the blast radius. Operators lose graphics and scheduling, and recovery is slow because there is no clean BMS backup.
• Opportunistic discovery of an exposed interface. Internet-wide scanning is continuous and indiscriminate, and an exposed supervisory or remote-access service gets found and catalogued within days. The finder is not interested in your air handling units, but access is access, and it gets used or sold.
• Contractor-route compromise. A provider with remote access into dozens of client buildings is a high-value target because of that reach. Their credentials become the route in, and your controls inherit their posture whether you assessed it or not.
• Insider and ex-insider access. Shared credentials never rotated after a technician left, or a disgruntled operator with legitimate access and no audit trail. Hard to investigate when logging does not exist.
• Targeted manipulation of plant. Genuine and serious, more plausible in data centres, healthcare, utilities and critical national infrastructure than in a typical office tower. If you operate in those sectors, the critical-facilities BMS pillar is where this threat class belongs in your planning.

The distinction matters because it changes where the money goes. Plan around the sophisticated adversary and you buy detection technology. Plan around the realistic threat and you spend the first year removing exposure, segmenting networks and fixing credentials, which is cheaper, more effective, and raises the cost for the sophisticated adversary anyway.

3. Segmentation and the zone-and-conduit model applied to a building

First, consequence, because it sets priority. Compromise of a BMS lands in one of four bands: loss of visibility, where plant runs on local logic but nobody can see or schedule it; loss of control, where setpoints cannot be changed centrally and performance degrades over days; manipulation of plant, where equipment is driven outside its intended envelope; and impact on life-safety interfaces. That last band is where I insist on precision. Fire detection and suppression, and in many jurisdictions smoke control and emergency lighting, must retain independent certified operation regardless of what the BMS is doing. The correct architecture is that the BMS monitors and reports from these systems and does not command them, with the interface direction documented in the fire strategy. How that separation is required, certified and inspected varies by jurisdiction and by authority having jurisdiction, so the local requirement governs. The BMS integration with fire, access control and CCTV pillar covers that boundary in detail.

The most valuable idea to import from industrial security is the zone-and-conduit model formalised in the IEC 62443 series. It translates to buildings well: group assets with similar security requirements and consequence into a zone, allow traffic between zones only through a defined conduit that is controlled, documented and inspectable, and deny everything else. For the standard text and its current parts, the International Society of Automation is the authoritative source; the structure of the series changes over time, so work from the current parts rather than a summary. Expressed as a zone model you could put in front of a designer:

Two notes. The Z2 operations DMZ is the part people skip, and skipping it is what forces the flat-network compromises later: every request for BMS data in a dashboard is pressure to punch a hole from Z3 into Z1, and if Z2 holds a read-only replica you have somewhere to say yes. And a documented zone with no firewall rule behind it is a diagram, not a control.

4. Secure remote access, done properly

Remote access is both the most common serious weakness and the most operationally necessary capability, so the question is never whether to allow it but what shape it takes. The pattern I would recommend:

• One controlled entry point, not many. All remote access arrives through a single brokered service that authenticates the person, not the device or the site. Multiple ad hoc routes, one per vendor, is how estates end up unable to answer "who can reach our controls today".
• Multi-factor authentication and named accounts, no exceptions for contractors. No shared "contractor" login: four attending engineers means four accounts. If a vendor says their tooling cannot support multi-factor, that is a procurement conversation, not a constraint to accept.
• Access lands on a jump host in the operations DMZ, never on a controller. The remote user reaches an intermediate system in Z2 and works from there into Z1. Nothing from outside touches the automation zone directly.
• Time-bounded and requested, not standing. Access is enabled for a defined window tied to a work order and closes automatically. Standing access for an annual service visit is what leaves doors open for years.
• Session recording and logging. You want to answer, months later, who connected, when and what they changed. This is the log most often missing.
• Least privilege inside the session. A vendor supporting the chiller sequence does not need engineering rights across the platform.

The anti-pattern, still common, is a port forward from the public internet to the supervisory server or a controller, protected by a password. It is found by automated scanning, gives a stranger a login prompt on a system that controls physical plant, and produces no useful log. Replacing it is the cheapest risk reduction available in most estates. For guidance on remote access to operational systems, the UK National Cyber Security Centre publishes accessible material, and the US National Institute of Standards and Technology the more detailed operational technology security guidance most vendor documents ultimately reference.

5. Asset inventory: you cannot protect controllers nobody has listed

Every controls assessment I have been involved in produces the same first finding: the estate does not know what it has. The original schedule is out of date, later minor works were never recorded, and the count of network-connected devices in the plant rooms is unknown. You cannot patch, segment or monitor an asset you have not listed, so inventory is the programme's first deliverable, not a preliminary to it. A usable record holds:

• Identity and location: asset tag, device type, make and model, location to room level, and the plant it serves.
• Network position: IP or fieldbus address, VLAN or subnet, upstream switch and port, and the zone it sits in.
• Software state: firmware or application version, when it was last updated, and by whom.
• Support status: whether the vendor still supports this version, and any declared end-of-support date.
• Criticality: the consequence band above, which drives remediation priority.
• Access: which accounts and which external parties can reach it, and through what route.

Discovery must be done carefully: some older controllers respond badly to aggressive scanning, and a scan that disrupts plant will end your programme's credibility. Passive traffic monitoring plus physical survey is the safer start, and active scanning should be agreed with the vendor and scheduled into a maintenance window. Keep the inventory in the system of record you already maintain, not a spreadsheet: controls devices belong in the CAFM or asset system with their own lifecycle records, as argued in the BMS maintenance and lifecycle pillar and in data governance for asset-heavy organisations. A security inventory outside the asset register will be stale within a year.

6. Patching controllers, where the constraint is not willingness

There is a persistent assumption in IT circles that building systems go unpatched because facilities teams are unwilling or unaware. In my experience the real constraints are vendor support and downtime windows, and both are genuine.

• The vendor may not release patches at all. Many field controllers receive firmware updates only as part of a functional release, and some product lines receive nothing after end-of-sale. Where there is no patch, patching is not the control; compensating segmentation is.
• Updating may invalidate a support arrangement. An operating system update on a supervisory server can put it outside the configuration the controls vendor supports. Write patch permissions into the maintenance agreement rather than discovering the restriction mid-incident.
• Downtime is negotiated, not scheduled unilaterally. Restarting a supervisory server during occupied hours in a hospital or data centre is not a small request. Patching windows in building services are scarce and compete with all the other work that needs them.
• Firmware updates carry rollback risk. A failed controller update can leave a device unrecoverable without a site visit, which on a rooftop unit in summer is a different proposition from a server reboot.

Instead of a blanket mandate, use a tiered policy. Supervisory servers and workstations are conventional computers and should follow a near-conventional patch cycle with a negotiated window, because they carry most of the risk and most of the available fixes. Gateways and network equipment sit in the middle, on a defined periodic cycle. Field controllers are updated on functional need, at refurbishment, or on a specific vendor security correction, and are otherwise protected by their position in the zone model. Write it down, get the asset owner to accept it, and you have a defensible position rather than an open finding.

7. Credentials, accounts and licence management

Access control in building systems is weak in a predictable way: very few accounts, shared widely, with more privilege than anyone needs, and no record of who used them. The remedies are conventional; the difficulty is organisational.

• Eliminate defaults everywhere, and verify. Defaults on controllers, gateways, network equipment and engineering tools are the most reliably exploited weakness in any operational estate. Changing them is a task, not a project, evidenced device by device against the inventory.
• Named accounts, roles, and least privilege. Separate operator, engineer and administrator roles with genuinely different capabilities: an operator adjusting a setpoint does not need to modify control logic. The role design thinking in the RBAC design pillar transfers directly to supervisory platforms.
• Joiners, movers and leavers must include OT. Most organisations have a leavers process for corporate accounts and no equivalent for the BMS. Controls access should be revoked the same day, which requires BMS accounts to be in scope rather than managed informally by the controls team.
• Federate where the platform supports it. Authenticating the supervisory platform against the corporate directory is usually a net gain in control and auditability. Support varies widely by platform and version, so confirm before designing around it, and keep a documented local break-glass account for when the directory is unavailable.
• Treat licences as a security asset. Licence files, dongles, activation keys and vendor portal access should be held by the client, not solely by the incumbent contractor. An estate that cannot rebuild its own supervisory server without asking a third party for a licence has an availability problem that surfaces at the worst moment.

8. Supply chain and contractor access

Building controls are almost entirely delivered and maintained by third parties, so your posture is substantially inherited. Treating that as a procurement problem rather than a technical one makes it tractable. These clauses are easiest at tender and hardest to retrofit mid-contract:

• Named individuals, not firms, hold access. The contract should require the provider to notify you of personnel changes.
• No vendor-installed remote access outside your controlled route. State it explicitly, because installing a convenient support tool is otherwise a normal thing for an engineer to do. Include a right to inspect.
• Handover includes a security baseline. Device inventory, credentials transferred and changed, zoned network diagram, firmware versions, remote-access arrangements, licences in the client's name. Make it a condition of acceptance, because after handover you have very little leverage.
• Incident notification runs both ways. If your provider is compromised you need to know quickly, since their access is a route into your estate.
• Cloud and managed services get the same scrutiny. A hosted analytics or managed-BMS offer moves data and sometimes control outside your perimeter, which can be an improvement or a new exposure depending on the architecture. The trade-offs are in the cloud BMS pillar, and the evaluation criteria in the platform evaluation pillar.

The same applies to devices arriving outside the controls contract entirely: metering, environmental sensors, occupancy counters. Each is a network-connected computer with its own update story and cloud connection, installed with no security review. The IoT and BMS integration pillar covers bringing them into the architecture deliberately rather than accidentally.

9. Monitoring and logging on an OT network

Monitoring is most often attempted before the foundations are in place, because it is the part with a product attached. Deployed after segmentation and access control it is valuable; deployed instead of them, it tells you in detail about incidents you could have prevented. What is realistic:

• Passive network visibility on the automation zone. An appliance on a mirror port sees which devices talk to which, and to what outside the zone. Building control traffic is repetitive, so the baseline is stable and deviations are informative. Passive means no risk to the plant.
• New device detection. On a zoned automation network an unexpected device is a high-quality signal, whether it is an intruder or a contractor who plugged a laptop into a plant-room switch.
• Supervisory server and workstation logs. Ordinary computers, so ordinary endpoint logging applies, forwarded off the machine so logs survive its compromise.
• Change and command logging in the BMS application. Who changed which setpoint, when, from where. Many platforms ship with this disabled or retained for days. Extending retention is often a configuration change with a storage cost, and it is the log you will want during an investigation.
• Process anomalies as security signals. Give operators a route to report "this schedule changed and nobody knows why" as a possible security event, not just a controls fault. It costs nothing and catches what technology misses.

On who watches it: a facilities team cannot run a security operations function, and a corporate one usually has no context for building control traffic. What works is OT monitoring output going to the existing security function, with a jointly agreed alert set and a named engineering contact who can say whether a behaviour is normal for that plant. Without that context, OT alerts get closed as noise within a quarter.

10. Incident response when the system controls physical plant

Standard incident response instinct is to isolate the affected system immediately. In building OT that can be wrong: powering down a supervisory system may remove the operator's only visibility of running plant, and in some configurations affect the sequences keeping critical spaces conditioned. The plan has to be written with engineering in the room. What it needs that a corporate IT plan does not:

• A documented manual fallback per critical plant item. Can the chiller, the air handling unit, the pump set run locally without the supervisory layer, by whom, and is that written where a night-shift engineer can find it? The most valuable preparation, and useful for ordinary failures too.
• A decision authority for isolation. Someone must be empowered to weigh "contain the intrusion" against "maintain conditions in the operating theatre", and not for the first time at two in the morning.
• Life-safety interfaces addressed explicitly. If the BMS interfaces to fire, smoke control or access control, the plan must state what happens to those interfaces during isolation, signed off by the fire strategy owner. Many jurisdictions also impose notification obligations to the authority having jurisdiction when confidence in a life-safety interface is affected; these vary, so establish the local position in advance.
• Verified, offline BMS backups. Controller configurations, graphics, logic, database, licence files. The failure I see most often is a backup that exists but has never been restored. Test it and record the restore duration, because that number is your recovery time whether you like it or not.
• Contact routes that do not depend on the contractor's convenience. Named, tested out-of-hours escalation into the controls vendor, and clarity on what they can do if remote access is deliberately disabled.
• An exercise, at least once. A tabletop walkthrough of "the supervisory server is encrypted and we have lost graphics across the estate", with facilities, IT, security and the controls provider in the room, surfaces more gaps in two hours than a year of document review.

11. The honest part: you cannot secure an existing estate in one project

Here is the part generic guidance omits. Assess a mature, occupied, multi-building estate against a full industrial security standard and the finding list will not be deliverable in one programme at any realistic budget without downtime nobody will authorise. Attempting it produces a stalled project and an exhausted team. Sequence by exposure instead, so the largest risk reductions land first and cheapest:

Notice the shape of that list. The first five items are configuration, discipline and documentation, achievable in a few months with existing staff and small budget, and together they remove most of the realistic risk. The expensive structural items sit at the bottom, deferred to the capital cycles where they belong. Order the work by exposure removed per unit of cost, not by the structure of whichever standard you are assessing against.

The idea to walk away with

Building management systems are exposed through ordinary, explicable neglect rather than exotic weakness: protocols that trusted their network, controllers built for availability, contractors who handed over and left, remote access never closed, and an ownership gap nobody was asked to close. The zone-and-conduit model gives you a defensible architecture, secure remote access the largest single risk reduction, inventory the basis for everything else. None of it is achievable in one programme on an occupied estate. Sequence by exposure, start by taking the building off the public internet, and accept a documented list of residual risks with named owners rather than pretending they were resolved.

Final thoughts

The most useful thing a facilities or estates leader can do this week is find out whether any part of the building control system can be reached from the public internet, and who holds remote access to it. Not through a framework assessment, just as a question to the controls provider and the network team with a written answer. That question alone has surfaced more real risk, in the estates I have looked at, than any document review.

After that the work is patient and organisational rather than technical. Get the devices into the asset register. Get named accounts and a leavers process. Get a backup you have actually restored. Get the life-safety boundary reviewed by the person accountable for the fire strategy. Write security requirements into the next controls contract. It is not a compelling story for a board, but it is what reduces the chance that a routine ransomware incident in the office takes the plant blind for a fortnight.

Related reading: Building management systems: a complete guide, Building automation systems explained, BMS integration with fire, access control and CCTV, BMS for data centres and critical facilities, IoT and BMS integration, RBAC design for CAFM systems.