How should smart building networks be segmented?

A smart building network is segmented by grouping devices that share a level of risk, a function and a management owner into zones, and then allowing only the specific communications each zone needs with the others. Done well, the design begins with a map of the data flows the building actually depends on; VLAN numbers come much later. The zones and permitted flows should be agreed between the controls, IT and security teams during design, recorded in a flow register, and tested before handover as carefully as any other building service.

What segmentation protects against

Segmentation limits how far a fault or an attacker can travel. If a guest laptop, a compromised camera or a misconfigured tenant device can reach every controller in the building, a single weakness becomes a building-wide problem. NIST's guide to OT security (SP 800-82) describes segmentation as a central part of a defence-in-depth architecture for operational technology, and notes that devices can be grouped by management authority, level of trust, functional criticality, data flow or location.

It also protects operations from ordinary mistakes. A broadcast storm on an office network, or a well-meant change made for IT reasons, is less likely to reach the plant if the plant sits behind a controlled boundary.

Map the conversations first

The first task is to list every communication the building needs in order to function, recording for each its source, destination, protocol, direction, purpose and owner. In a typical building the list includes supervisory software polling field controllers; the building management system sending alarms to an operator workstation or maintenance platform; meters reporting to an energy platform; an analytics service reading trend data; an access control server talking to door controllers; perhaps a hotel property management system sending room status to guest-room controls; and remote support sessions from contractors.

NIST recommends using mapped data flows to identify the communications that are required, then configuring network devices to permit only those. In an existing building where nobody is quite sure what talks to what, it suggests temporarily allowing and recording traffic between segments to build an evidence base. That exercise often turns up undocumented connections, each of which needs a decision.

Drawing the zones

There is no single correct list of zones. The structure below is a useful starting point for discussion, and real projects merge or split zones according to size, risk and ownership.

NIST notes that VLANs can be a cost-effective way to segment OT, but recommends considering physically separate switches for high-criticality devices such as those supporting safety systems. For any interface to fire or life-safety systems, the network decision should follow the fire strategy and the appointed fire engineer's requirements, not convenience.

Enforcing the boundaries

Every permitted flow crosses a boundary that enforces it. In practice that means firewalls or routers with explicit rules between zones, and an intermediate integration zone, often called a demilitarised zone or DMZ, between building systems and the enterprise or cloud. NIST describes the DMZ as an enforcement boundary that avoids direct traffic between corporate and OT networks.

A few design habits make those boundaries much stronger. Building systems should push data outwards to an integration zone; enterprise and cloud systems should never reach directly into controllers. Reading should be kept apart from writing, so that a dashboard needing only trend data has no path that would let it send commands. Remote access should come through one controlled point, with multi-factor authentication and session logging, not through devices scattered across zones. And the management interfaces of switches and firewalls should not be reachable from the zones they protect.

Building protocols have their own habits

Building systems do not always behave like office IT. Some BACnet/IP installations rely on broadcast messages for device discovery. Ordinary IP routers do not forward these between subnets, so BACnet uses broadcast management devices (BBMDs) to distribute them deliberately. That is useful, but a poorly planned broadcast distribution configuration can undo the separation you intended, unnoticed, so discovery and routing across each boundary need agreeing with the controls designer.

Newer options can help. BACnet Secure Connect (BACnet/SC), introduced through an addendum to the BACnet standard approved in 2019 and carried into the current edition, ANSI/ASHRAE 135-2024, runs BACnet over TLS-secured WebSocket connections with certificate-based authentication, and is designed to sit more comfortably in IT-managed infrastructure. Support varies by product and version, and certificates need managing, so treat it as a design option to confirm with suppliers, never as a given.

A diagram is only a claim until it is tested

Before acceptance, the contractor should demonstrate that permitted flows work and that representative unpermitted flows are blocked, including from guest and tenant networks. The handover should include a current zone diagram, the flow register, firewall rule documentation linked to each flow's purpose and owner, and a change process. From then on, every new integration should begin with an entry in the flow register.