Smart Building Cybersecurity: Implementing IT-OT Convergence Controls for BMS Systems

Three things changed that make BMS security an IT problem now instead of a facilities problem:

The protocols were never built for a shared network. BACnet and Modbus/TCP both carry commands in plaintext with no built-in authentication. Any device that can route to a BACnet/IP controller can issue a Write Property request to it: there is no credential check at the protocol layer. BACnet's own optional security clause (Clause 24 in the ASHRAE 135 standard) went effectively unimplemented by vendors for 16 years before ASHRAE removed it from the standard in 2019 in favor of the newer BACnet Secure Connect (BACnet/SC) addendum, which most fielded controllers still do not support.

The access path is now the same one IT already has to defend. When a BMS runs on its own wire, an attacker needs physical access to that wire. When it runs on the corporate IP network, an attacker who lands on a user workstation through phishing is on the same broadcast domain as the door controllers, unless something explicitly stops them. The 2013-2014 Target breach is the reference case here: attackers used credentials stolen from Fazio Mechanical, Target's HVAC and refrigeration vendor, to reach Target's vendor portal, then moved laterally from that building-systems access point into the payment card network. The vendor's legitimate reason to reach the BMS remotely became the initial foothold into an unrelated, higher-value network, because nothing segmented the two.

Regulatory scope has caught up. Under the EU's NIS2 directive, operators of essential services in sectors like healthcare, energy, and transport are increasingly finding that their building management systems, particularly access control and life-safety-adjacent HVAC, fall inside audit scope because a BMS outage or compromise can directly disrupt the regulated service. See our NIS2 compliance guide for the broader reporting and governance obligations that follow from that scope determination.

The practical result: a BMS that used to be out of reach by design is now one misconfigured VLAN away from being reachable from any compromised endpoint on the network, running protocols that will not stop the attacker once they get there.

Do not start segmenting until you have these in hand. Skipping this step is the most common cause of a mid-project outage on systems facilities cannot easily explain to end users (a dark lobby, a stuck elevator, a door that will not badge open).

A complete BMS asset inventory. List every controller, panel, gateway, and head-end server: HVAC controllers (make, model, firmware, IP), access-control panels and their door readers, elevator controller network interfaces, lighting and metering gateways, and any BMS supervisory workstation. Facilities teams typically have partial lists from vendor commissioning documents; IT rarely has a complete one. Reconcile both. Passive network discovery (a span port capturing traffic for a week) will surface devices that show up on neither list, which is common with elevator vendors who install their own remote-access modem or cellular gateway outside the change-control process.

Current network topology for the BMS segment(s). Pull switch configs and VLAN assignments for every port a BMS device touches. Confirm whether BMS traffic currently shares a VLAN with any IT-managed subnet, and whether it can already reach the internet unfiltered (common with cloud-managed access-control head ends and elevator remote-diagnostics modems).

A change window and a facilities point of contact who can validate physical function. Segmentation changes to a live BMS can silently break supervisory polling even when the underlying device keeps working, so someone needs to be able to confirm, in person, that doors still badge, HVAC still responds to setpoint changes, and elevators still dispatch, immediately after each change.

Vendor remote-access inventory. Identify every vendor (HVAC controls integrator, access-control installer, elevator maintenance company) with any standing remote-access path into the BMS, whether that is a VPN account, a cellular gateway they installed, or a cloud portal they administer on the customer's behalf. Each of these is a credential-based entry point that did not exist when the BMS was air-gapped, and each needs to be accounted for in the access-control step below.

Create a Layer 3 boundary between the BMS and everything else, following the same zone/conduit logic IEC 62443 uses for industrial control networks, adapted to building systems:

1. Assign the BMS a dedicated VLAN (or VLANs, if HVAC, access control, and elevators need separate blast-radius limits from each other) distinct from user, server, and guest VLANs. If the building has multiple BMS vendor stacks with no operational reason to talk to each other, do not put them on the same VLAN by default.
2. Route all inter-VLAN traffic through a firewall, not a Layer 3 switch with permissive ACLs. The firewall needs to log denied attempts, which a switch ACL typically does not do usefully.
3. Default-deny in both directions between the BMS VLAN and the corporate VLANs. Explicitly permit only the specific flows the BMS actually needs: the supervisory workstation to its controllers on the BACnet/IP UDP port (47808 by default), the access-control head end to its panels, and nothing else initiating inbound from the corporate side.
4. Block BMS-to-internet traffic by default, then add narrow exceptions per device for firmware update servers or vendor cloud endpoints, by IP or FQDN allow-list rather than a blanket outbound permit. Elevator remote-diagnostics modems and cloud-managed access-control panels are the most common source of an unrestricted outbound rule that facilities requested once and IT never revisited.
5. Isolate any vendor remote-access path (VPN, cellular gateway, remote-desktop tool) into its own conduit with its own firewall rule set, rather than letting it land directly on the BMS VLAN with full reach.

If the building lacks enterprise-grade switching to support this, the VLAN and firewall approach described in our guide to network segmentation without enterprise gear applies directly: a managed switch plus a pfSense or OPNsense appliance is sufficient to build a BMS zone in a single building or campus that does not have a dedicated OT network team.

BACnet and Modbus do not support authentication at the protocol level, so MFA cannot be applied to controller-to-controller traffic. It has to be applied at every point a human logs in to manage the system:

1. Supervisory and head-end workstations. Any workstation or server running the BMS supervisory software (the console facilities uses to adjust setpoints, unlock doors remotely, or dispatch elevators) needs MFA on its local login, not just on any web portal in front of it.
2. Vendor remote-access accounts. Every VPN or remote-desktop account a controls integrator, access-control installer, or elevator maintenance vendor uses must require MFA, be time-limited to the maintenance window rather than standing, and be tied to a named individual rather than a shared vendor account. A shared, standing, MFA-less vendor account is functionally the same exposure the Fazio Mechanical credentials represented at Target.
3. Cloud-hosted access-control and BMS management portals. Where the head end itself is SaaS (increasingly common for access control), enforce MFA at the identity provider in front of that SaaS login, and if the vendor supports SSO via SAML or OIDC, federate it to the same identity provider the rest of the organization uses so deprovisioning a terminated employee or contractor happens in one place. Where MFA cannot be applied natively (older on-premises access-control software with a local user database and no MFA support), put that login behind a reverse proxy or VPN concentrator that enforces MFA before the credential prompt is ever reached, as described in our zero trust network access implementation guide.
4. Physical badge credential provisioning itself. Treat the access-control system's own administrative console, the interface used to issue or revoke badge credentials, as a privileged identity system. Someone with unauthenticated or single-factor access to that console can badge themselves into any door in the building; this is a different and often overlooked risk from network-level compromise of the panels.

Run a quarterly access review specifically for the BMS: every standing account (internal and vendor) with access to supervisory software, remote-access VPNs, or cloud portals, cross-checked against current employment and active vendor contracts.

Active scanning of BMS devices carries real risk: some BACnet and Modbus controllers have been observed to crash, freeze, or drop into a fail-safe state (which for HVAC can mean shutting down, and for access control can mean fail-open or fail-locked doors) when hit with an unexpected packet or an aggressive port scan. Do not run a standard vulnerability scanner against the BMS VLAN without confirming with the vendor first that the specific controller model tolerates it.

Instead, deploy passive monitoring:

1. Mirror (SPAN) the BMS VLAN's uplink port to a monitoring interface rather than scanning devices directly.
2. Baseline normal traffic first: which devices talk to which, on what ports, at what times of day. A BACnet controller that only ever exchanges Read Property requests with the supervisory workstation is not expected to suddenly initiate an outbound connection to an unfamiliar external IP.
3. Alert on the deviations that matter for these protocols specifically: unexpected Write Property or Device Communication Control commands to BACnet controllers, unsolicited Modbus write function codes (05, 06, 0F, 10) from a source other than the known supervisory host, new devices appearing on the BMS VLAN that are not in the asset inventory, and any outbound connection attempt from a BMS device that is not on the explicit allow-list from Step 1.
4. Feed BMS VLAN firewall logs and the passive monitoring alerts into the same SIEM the rest of the security team already watches, rather than leaving them in a standalone facilities tool nobody on the security side ever opens.

Where the organization has committed to full OT-aware monitoring investment, a dedicated OT network monitoring platform with a BACnet/Modbus protocol dissector will do this analysis automatically; where budget does not support that yet, the SPAN-port-plus-baseline approach above is a workable interim step.

After segmentation and MFA changes are in place, confirm each control actually holds, in this order:

1. Segmentation validation. From a test workstation on a corporate VLAN, confirm you cannot reach the BMS VLAN's controller management ports (BACnet/IP UDP 47808, Modbus TCP 502, and any HTTPS management interface on the panels) except through the explicitly permitted path. From the BMS VLAN, confirm devices cannot reach the internet or corporate VLANs outside the specific allow-listed destinations. Check the firewall's deny log during this test: absence of a logged deny when traffic should have been blocked means the rule is not actually matching, not that the traffic was silently dropped correctly.
2. MFA validation. Attempt to log in to the supervisory workstation, the vendor VPN, and any cloud access-control portal without completing the second factor, and confirm each is rejected. Confirm a terminated or expired vendor account can no longer authenticate at all, not just that it lacks MFA.
3. Physical function validation with facilities present. Immediately after each change, have the facilities contact confirm HVAC setpoint changes still propagate, badge readers still grant and deny access correctly, and elevators still dispatch and respond to remote diagnostics as expected. Do this before declaring the change complete, not the next business day.
4. Monitoring validation. Generate a benign test event that should trigger an alert (for example, connect an unauthorized test device to the BMS VLAN briefly, with facilities' knowledge) and confirm it appears in the SIEM within the expected time window.

Over-restrictive firewall rules break life-safety systems. A default-deny rule set applied without adequately mapping fire alarm panel integrations, emergency door release wiring, or elevator recall-to-lobby functions during a fire alarm can create a life-safety failure, which is a materially worse outcome than the cybersecurity risk being mitigated. Fire and life-safety systems should generally sit on their own conduit, validated with the fire alarm vendor and, where applicable, the local authority having jurisdiction, before any segmentation project touches them.

MFA on emergency access paths can lock out responders. A facilities engineer troubleshooting a building emergency at 2 a.m. without their MFA device is a real operational scenario. Build a documented break-glass procedure (a separate emergency account with its own strict logging and mandatory post-use review) rather than leaving no fallback, which tends to result in the MFA requirement being quietly disabled instead.

Passive monitoring has blind spots active scanning would close, and vice versa. Passive monitoring will not catch a vulnerability that has never been triggered by observed legitimate traffic, but active scanning risks the outage described in Step 3. Most organizations should default to passive monitoring for production BMS networks and reserve active scanning for a maintenance window with the vendor's explicit sign-off and a rollback plan.

Legacy controllers may not support the recommended controls at all. Older BACnet MS/TP controllers bridged onto IP through a gateway, or first-generation IP access-control panels, frequently have no path to modern authentication and cannot be patched to add it. In these cases, the segmentation and monitoring controls in this guide are not optional hardening, they are the only mitigation available short of a capital replacement project, and that tradeoff should be stated plainly to leadership rather than presented as a temporary gap that will be closed by a future patch.

Vendor pushback on removing standing remote access. Controls integrators and elevator maintenance vendors often resist moving from a standing VPN connection to a time-limited, audited one, citing response-time concerns. This is a negotiation to have explicitly in the maintenance contract, not a control to quietly water down after the first complaint.