Estimated reading time: 13 minutes
Should Your BMS Be Connected to the Corporate IT Network?
Connecting a Building Management System to corporate IT infrastructure may provide administrative and reporting benefits, but without proper separation, governance and technical controls, it can also introduce new operational and cybersecurity risks.
Building Management Systems have changed considerably. What was once installed as a largely standalone control system may now include virtual servers, cloud platforms, remote access services, enterprise dashboards, energy reporting tools, analytics platforms and connections to corporate networks.
This increased connectivity can provide genuine benefits. It can improve access to building information, support remote technical assistance and allow building performance data to be shared with asset managers, property teams and other business systems. However, it also raises an important question:
Should the system controlling the operation of a commercial building be dependent upon the same IT environment used for emails, office applications, corporate servers and general business administration?
In our view, the answer is generally no.
A BMS may need to exchange selected information with corporate systems, but it should normally remain a separately managed operational technology environment with controlled, monitored and clearly documented connections. The objective should be to share information without surrendering operational control.
A BMS Is Not Just Another Computer System
WA Building Management System is sometimes treated as though it were simply another software application.
It is not.
A BMS monitors and controls physical equipment and processes throughout a building. Depending on the property, this may include:
- air conditioning and ventilation;
- chillers, boilers, pumps and cooling towers;
- variable-speed drives and motor control equipment;
- car park ventilation and carbon monoxide monitoring;
- electrical metering and energy management;
- generators and backup power systems;
- critical temperature and pressure alarms;
- hydraulic services;
- interfaces with fire and life-safety systems;
- access control, lighting and other building services.
The National Institute of Standards and Technology specifically includes building automation systems within the definition of operational technology. Unlike conventional IT, operational technology interacts with the physical environment and may directly change how equipment and processes operate.
This difference matters.
The consequences of an office application becoming unavailable may involve lost productivity or delayed administration.
The consequences of a BMS failure may include:
- loss of air conditioning;
- no visibility of critical alarms;
- uncontrolled temperatures in sensitive areas;
- plant failing to start or stop;
- simultaneous heating and cooling;
- loss of pressure or flow monitoring;
- tenant complaints and business disruption;
- excessive energy consumption;
- equipment damage;
- interference with essential or life-safety-related building functions.
A BMS must therefore be managed according to operational priorities, not merely corporate IT policies.
The Priorities of IT and Operational Technology Are Different
WCorporate IT departments are generally focused on protecting information, standardising systems and maintaining secure business applications.
Those are legitimate and important objectives.
However, the operational priorities of a BMS are different. They include:
- Safety
- Availability
- Continuity of operation
- Predictable system behaviour
- Protection of plant and equipment
- Integrity of control sequences
- Recovery following a failure
Cybersecurity guidance for operational technology recognises these differences. The Australian Signals Directorate’s Australian Cyber Security Centre states that safety is paramount in an operational environment and that cybersecurity measures must account for plant operation, reliability, uptime and the physical consequences of failure.
By fostering collaborations globally, we build a robust frA standard corporate process may be entirely appropriate for an office computer but dangerous when applied without consideration to a control system.
For example, an IT administrator may decide to:
- install an operating system update;
- restart a virtual server;
- change an IP address;
- apply a corporate security policy;
- modify firewall rules;
- renew or replace a security certificate;
- remove an old user account;
- update antivirus software;
- migrate a virtual machine;
- change network switches or routing;
- run an active vulnerability scan;
- restore an earlier server snapshot.
Each change may appear routine from an IT perspective.
However, it may also affect the BMS supervisor, licensing service, historical database, alarm delivery, BACnet communications, controller connections, graphics, remote access or system integration.
The person implementing the change may not know what has stopped working. The problem may remain unnoticed until the building loses control, an alarm is missed or occupants begin complaining.
Integration Can Create Benefits—and New Dependencies
A recent advisory note correctly identifies many of the risks that arise when a BMCS is placed on shared corporate infrastructure.
These risks include unclear ownership, system outages, incompatible updates, inadequate recovery processes, unsupported platforms and legacy credentials. The article recommends a BMCS management plan that clearly defines responsibilities between facility management, corporate IT and external service providers.
We agree that clear management and accountability are essential.
However, management documentation alone is not enough.
A well-written plan will not protect the building if the BMS:
- relies on a corporate network that has failed;
- cannot operate because Active Directory is unavailable;
- has been affected by a corporate ransomware incident;
- loses communications during an IT infrastructure upgrade;
- is restored from an unsuitable server backup;
- is exposed through poorly controlled remote access;
- becomes inaccessible after an undocumented firewall change;
- is patched without testing compatibility with the BMS software;
- shares credentials, administration tools or infrastructure with unrelated business systems.
The physical and network architecture must support the management plan.
The BMS should be designed so that a failure or cybersecurity incident affecting corporate IT does not unnecessarily disable the building’s core operational functions.
Cybersecurity Does Not Mean Putting Corporate IT in Control
There is a common assumption that moving a BMS onto corporate infrastructure will automatically make it more secure. That is not necessarily true. A mature IT department may provide valuable cybersecurity knowledge, including expertise in:
- network design;
- firewall configuration;
- secure remote access;
- identity management;
- vulnerability management;
- incident detection;
- backup protection;
- cybersecurity response.
However, stronger cybersecurity does not require the BMS to become part of the general corporate network.
Current Australian Government cyber principles state that operational technology should be logically and physically isolated from IT systems and external infrastructure, with only authorised, controlled and monitored communication paths permitted between them.
The ACSC’s operational technology principles also specifically recommend segmenting and segregating OT from other networks. They emphasise the need to understand the physical process, document system dependencies and ensure that the people protecting the system understand how the plant actually operates.
That is a very different model from simply placing the BMS on the corporate network and allowing normal IT policies to apply. The better approach is:
Use IT and cybersecurity expertise to protect the BMS boundary, but retain operational control with people who understand the building and its systems.
Separation Does Not Necessarily Mean Complete Isolation
Keeping the BMS separate does not always mean creating a completely air-gapped system with no external connectivity. Modern buildings may have legitimate reasons to connect the BMS to other systems, including:
- remote maintenance;
- energy and sustainability reporting;
- portfolio-level monitoring;
- fault detection and diagnostics;
- cloud-based analytics;
- tenant comfort platforms;
- work order management;
- enterprise dashboards;
- artificial intelligence tools;
- demand management and electricity market interfaces.
The important question is not simply whether the BMS is connected. It is:
How is it connected, what is allowed to communicate, who can access it and what happens if that connection is lost or compromised?
A secure design may allow selected data to leave the BMS network without allowing an external system to take control of the building. For example, the BMS may transmit energy data, alarm information or equipment status through a controlled gateway while blocking unnecessary inbound traffic.
Where remote access is required, it should normally be provided through a secure and monitored method such as a hardened gateway, properly configured virtual private network or dedicated jump host.
The ACSC recommends segmentation, trusted boundary controls, restricted connectivity, logging and monitoring where operational devices need to communicate with external systems or receive vendor support.
Remote access should also use controls such as encryption, unique credentials, limited privileges and multifactor authentication. The connection should serve a clearly defined operational purpose. It should not exist simply because connecting everything to the corporate network is administratively convenient.
What a Properly Separated BMS Environment May Include
The right arrangement will depend on the building, system age, level of criticality and operational requirements. However, a sound commercial building architecture may include:
A Dedicated BMS Network
The BMS should have its own documented network environment, including dedicated IP addressing, switches, controllers and network pathways where practical.
It should not be mixed indiscriminately with tenant, office, guest wireless, security, audio-visual or general-purpose building networks.
Controlled Network Boundaries
Connections between the BMS, corporate IT, cloud platforms and remote service providers should pass through managed boundary devices.
Only required ports, protocols, destinations and communication directions should be permitted.
Local Control at the Equipment Level
Air handling units, central plant, pumps, fans and other building systems should continue operating through local controllers if the BMS server, internet connection or corporate network becomes unavailable.
A loss of high-level supervision should not automatically mean a loss of basic control.
Secure Remote Access
The BMS should never be exposed directly to the public internet.
Remote connections should be encrypted, authenticated, logged and restricted to authorised users.
Vendor access should be enabled only where necessary and, for higher-risk buildings, may be time-limited or subject to approval by the building representative.
Independent Credentials and Administration
Access to the BMS should be based on the operational requirements of the building.
Unrestricted corporate domain accounts should not automatically provide administrative access to the BMS.
Each person should receive only the level of access required to perform their role.
Tested Backups
A BMS backup is more than a copy of the server.
Recovery information may need to include:
- BMS databases;
- control programs;
- graphics;
- trend and alarm configurations;
- controller backups;
- network settings;
- integration configurations;
- software licences;
- certificates;
- passwords and access procedures;
- virtual machine configurations;
- commissioning records;
- functional descriptions.
Backups should be protected, current and tested to confirm that the system can actually be restored.
Formal Change Control
No change should be made to the BMS infrastructure without understanding its operational impact.
Changes involving servers, software, networks, firewall rules, virtual machines, certificates, security tools or remote access should be documented, tested and accompanied by a rollback plan.
Most importantly, the BMS should be functionally checked after the change.
A server may appear healthy while field communications, trend collection, alarm delivery or control functions have stopped.
Who Should Own the BMS?
Responsibility should be shared, but ownership must be clear.
The Building Owner or Asset Manager
The owner ultimately carries the operational and financial risk.
The owner should ensure that there is a clear governance structure, appropriate funding and an up-to-date understanding of the BMS infrastructure.
Facility and Building Management
The facility or building management team should understand how the BMS supports daily building operation.
They should control operational priorities, approve access and coordinate changes that may affect occupants, equipment or services.
The BMS Contractor or Integrator
The BMS specialist should be responsible for the control system’s technical functionality, including databases, control logic, communications, graphics, alarms, trends and system recovery requirements.
The provider should also explain the operational consequences of proposed IT or cybersecurity changes.
The IT and Cybersecurity Team
IT should assist with secure infrastructure, network controls, access management, monitoring and incident response.
However, IT should not make unilateral changes to the BMS environment without consultation, testing and approval from the people responsible for building operation.
Other Building Services Contractorsy
Mechanical, electrical, fire, hydraulic, security and specialist contractors may all interact with systems connected to the BMS.
Their access and responsibilities should be clearly defined so that no contractor assumes another party is maintaining a critical component.
Questions Building Owners Should Be Asking
Many owners and facility managers do not know how their BMS is connected or who has administrative control over it. Useful questions include:
- Is the BMS connected to the corporate network?
- Is the BMS network documented?
- What systems can communicate with it?
- Is any part of the BMS directly exposed to the internet?
- Who controls the BMS firewall and network switches?
- Who can create or remove user accounts?
- Is remote access logged and protected by multifactor authentication?
- Does the system depend on corporate Active Directory, DNS, virtualisation or backup infrastructure?
- Can the building continue operating if corporate IT is unavailable?
- What happens if the BMS server fails?
- Are controller programs and system databases backed up?
- Have the backups ever been restored and tested?
- Who approves operating system patches and cybersecurity changes?
- Is functional testing completed after IT changes?
- Are old vendor accounts still active?
- Is there a current network diagram and asset register?
- Who is accountable during a cybersecurity incident?
- Can the BMS be isolated quickly without stopping essential building operation?
An inability to answer these questions is itself a warning sign.
Cybersecurity Must Protect the Building, Not Disrupt It
The objective of BMS cybersecurity is not simply to satisfy a corporate policy or install more software. The objective is to protect:
- people;
- building operation;
- physical equipment;
- critical environmental conditions;
- operational data;
- business continuity;
- the owner’s investment.
A cybersecurity measure that unexpectedly stops the BMS, interrupts critical plant or prevents the building team from recovering the system may introduce as much operational risk as it removes.
Cybersecurity decisions must therefore involve people who understand both the digital system and the physical building.
The WR8Tech Position
WR8Tech supports secure connectivity, improved governance and better management of aging BMS infrastructure. However, we do not believe that connecting a BMS directly to general corporate IT infrastructure should be treated as the default solution. Our preferred principle is:
Separate the control environment. Protect the connections. Share only the information that is genuinely required.
Corporate IT and cybersecurity personnel have an important role, but the BMS must remain governed as operational technology. It should be managed by people who understand what the system controls, what can go wrong and what the consequences will be for the building.
The safest arrangement is usually one in which the BMS can continue performing its essential local control functions even if:
- the internet fails;
- the corporate network is unavailable;
- a cloud platform becomes inaccessible;
- remote access is disabled;
- an IT cybersecurity incident occurs.
Connectivity should enhance the operation of the building. It should never become an unnecessary single point of failure.
Is Your BMS Network Properly Controlled?
Many commercial buildings have accumulated years of network changes, remote access arrangements, unsupported computers, undocumented connections and legacy user accounts.
The system may still appear to operate normally, while significant operational and cybersecurity risks remain hidden. WR8Tech can assist building owners, facility managers and property professionals with:
- BMS infrastructure and network reviews;
- BMS cybersecurity readiness assessments;
- remote access reviews;
- system architecture and dependency mapping;
- BMS asset and software audits;
- backup and recovery reviews;
- legacy system risk assessments;
- controller and server documentation;
- independent advice before network or server changes;
- development of practical BMS management plans.
Before connecting your BMS more closely to corporate IT, make sure you understand what is being connected, what dependencies are being introduced and who will remain in control when something goes wrong.
Protect the network without losing control of the building.