Building management systems were designed for reliability, not resistance to attack — and for most of their history that trade-off was invisible because BMS networks sat physically isolated from the internet. That isolation is gone. This article sets out a practical OT security baseline for Australian building networks, written for design teams rather than security specialists.
Why Building Networks Became a Target
Three trends converged to expose Australian BMS networks that were previously safe by obscurity: remote monitoring and vendor support now require internet-facing connectivity to the BMS head-end; IP cameras, access controllers and IoT sensors have turned the ELV network into a dense population of embedded devices running firmware that is rarely patched; and building portfolios have converged BMS, security and metering onto shared network infrastructure to cut cabling cost, which means a single compromised device can now reach systems it was never meant to touch.
The Security of Critical Infrastructure Act 2018 (SOCI Act) reframed some Australian building types — particularly those supporting hospitals, data centres, electricity and water assets, and certain higher-education and defence-adjacent facilities — as critical infrastructure with statutory cyber-security obligations. Even where a specific building falls outside SOCI's asset classes, the Act has shifted market expectations: institutional owners, government tenants and Tier 1 contractors increasingly ask for OT security evidence on any Australian building project regardless of formal SOCI coverage.
A Practical OT Security Baseline for Australian Buildings
1. Asset Inventory Before Anything Else
Most Australian building portfolios cannot answer a simple question: how many IP-connected devices exist on the BMS/ELV network, and what firmware are they running? An accurate asset register — device type, IP, firmware version, vendor support status — is the precondition for every other control on this list, and it is routinely the first deliverable we produce when engaged to review an existing Australian building's OT posture.
2. Network Segmentation by System, Not by Floor
The default Australian building network design still segments by floor or tenancy. OT security segmentation should instead separate by system criticality: fire and life-safety systems on their own VLAN with no route to the internet-facing segment; BMS control on a separate VLAN from BMS reporting/analytics; CCTV and access control isolated from the general IT network with a controlled one-way or broker-mediated data path for video/event export. This is a design decision that belongs in the network schematic at concept stage, not a retrofit.
3. Secure Remote Access for Service Contractors
Vendor remote-support access is the single most common OT breach vector because it is granted broadly and rarely revoked. A defensible Australian design specifies a jump-host or vendor-specific VPN with time-boxed, logged, MFA-protected access — never a persistent open port or shared credential set handed to multiple service contractors.
4. A Patching Regime That Matches OT Reality
BMS and security controllers cannot be patched like IT servers — many require a maintenance window, vendor sign-off, and sometimes physical access. The realistic control is a documented patching cadence (e.g. quarterly for controllers, as-available for critical CVEs) combined with compensating network controls — segmentation and monitoring — for devices that cannot be patched promptly.
5. Logging and Anomaly Detection at the OT Boundary
Most Australian building networks have no visibility of what crosses the boundary between IT and OT segments. A firewall or OT-aware monitoring appliance at that boundary, logging to a SIEM the facilities team can actually review, is now a reasonable minimum for any building carrying SOCI obligations — and good practice regardless.
What the Essential Eight does and doesn't cover: The ACSC's Essential Eight was written for corporate IT, not OT. Application control and patching translate reasonably well to BMS controllers; multi-factor authentication and restricting admin privileges translate directly to vendor remote access; but daily backups and macro settings have little OT relevance. Treat the Essential Eight as a partial starting point, not a complete OT framework.
Where This Fits in the Design Programme
OT security architecture is cheapest to get right at the ELV/ICT design stage — segmentation is a switch and VLAN configuration decision, not a bolt-on product purchase, when it's specified in the initial network design rather than retrofitted after a portfolio-wide security review flags gaps. For Australian projects with SOCI exposure, we recommend engaging a security-aware ELV/ICT designer during concept design, not after the network has already been procured.
Frequently Asked Questions
Does the SOCI Act apply to our building?
The SOCI Act applies to specific critical infrastructure asset classes — including certain hospitals, data centres, electricity, gas, water and some higher-education and research facilities. Many commercial buildings fall outside its scope, but government and institutional tenants increasingly expect similar controls voluntarily. We recommend a specific legal assessment for buildings with ambiguous exposure.
Can you retrofit OT segmentation into an existing Australian building network?
Yes — retrofitting is more disruptive than designing it in from the start (it typically requires a staged VLAN re-architecture and possibly new switching), but it is a common and achievable engagement, usually delivered floor-by-floor or system-by-system to avoid downtime on live building operations.
How does OT cybersecurity design interact with our BMS vendor?
We design the network architecture, segmentation and remote-access model independently of the BMS vendor, then work with the vendor to confirm their controllers and software support the segmentation approach — this avoids the network design being dictated by whichever vendor happens to hold the BMS contract.