BMS cyber security: the basics every site should have
Default passwords, open remote access, flat networks and unpatched supervisors are the usual weak spots. The practical basics that close most of the risk on a BMS.
A BMS used to be a closed system in a plant room. Now it’s usually on the building’s IP network, often reachable from outside, and running software that needs updating like any other. That makes it a target. Not necessarily because someone wants to change your office temperature, but because a poorly secured BMS can be a way into the rest of the network.
You don’t need a big security programme to fix most of the risk. A handful of basics cover the majority of real-world problems.
The usual weak spots
On a lot of sites, the same issues come up again and again:
- default or shared passwords that have never been changed
- the supervisor or controllers directly reachable from the internet through a forwarded port
- the BMS on the same flat network as office PCs and guest Wi-Fi
- old supervisor software and firmware that hasn’t been updated in years
- former contractors and staff who still have working logins
- no backups, or backups stored only on the system itself
The basics
1. Change default passwords and stop sharing logins
Every controller, supervisor, router and switch should have a unique, strong password. Give each person their own account, so you know who did what and can remove access when someone leaves. Review the user list at least once a year.
2. Don’t expose the BMS directly to the internet
Port-forwarding a supervisor’s web page to the outside world is one of the riskiest things you can do. Remote access should come through a secure route the client’s IT team controls, such as a VPN or a properly managed remote access gateway, with individual logins and, ideally, multi-factor authentication.
3. Put the BMS on its own network
Separate the BMS from office systems with its own VLAN and a firewall between them. Only allow the traffic that’s genuinely needed. That way a compromised laptop can’t wander straight onto the plant network, and the reverse is true as well. There’s more on this in IP networking for BMS engineers.
4. Keep software and firmware up to date
Supervisor platforms and controllers get security fixes like any other software. Agree who is responsible for updates, test them on a backup or a quiet period first, and record what’s been applied. Systems that are years out of support are a risk in themselves, and that’s worth putting on the client’s budget plan.
5. Use the security features you already have
Modern platforms, Niagara included, come with hardening options: encrypted connections, certificate management, role-based permissions and audit logs. Many sites have them switched off or left on default settings. Work through the manufacturer’s hardening guidance as part of commissioning, not as an afterthought.
6. Back up, and keep a copy somewhere else
Regular backups of the supervisor and controller programs, stored off the system, mean that a failure, a mistake or a ransomware incident becomes a restore rather than a rebuild. Test a restore every so often. An untested backup is just a hope.
7. Remove access when people leave
When a contractor’s contract ends or an engineer moves on, remove their accounts, change any shared credentials they knew, and revoke their remote access. It’s simple, and it’s very often missed.
Who owns BMS security?
This often falls between the cracks. The BMS contractor assumes IT handles it, IT assumes the BMS is the contractor’s problem, and the FM assumes someone’s looking after it. Agree it in writing:
- who manages user accounts
- who controls remote access
- who applies updates, and how often
- who keeps the backups and tests them
- who to call if something looks wrong
Quick questions for FM teams
If you’re responsible for a building, ask your BMS contractor and IT team:
- Can anyone reach our BMS from the internet without a VPN?
- When were the passwords last changed, and who has accounts?
- Is the BMS on a separate network from our office systems?
- When was the software last updated, and is it still supported?
- Where are the backups, and when was a restore last tested?
If the answers are vague, that’s your starting point. None of these fixes is expensive compared with recovering from an incident.