Hardening a BAS Supervisor and Its Controllers: A Field Checklist

The supervisor PC is a strange machine. It's usually the most connected computer in the building system — it talks to every controller, it's reachable from the office, and it's often the thing remote users log into. Yet it's frequently the least looked-after: installed at handover, left running, and not updated since.

Hardening just means removing the easy ways in and making sure you can recover if something goes wrong anyway. None of the items below is exotic. Worked through in order, they turn a supervisor from the soft spot into something IT won't wince at. Where a step involves the BAS software itself, coordinate with the vendor or the platform's documentation, because a well-meant change can stop the system running.

1. Know what you've got

You can't harden what you haven't listed. Before changing anything, record:

• The supervisor hardware, operating system and version, and BAS software and version.
• Every controller, router and gateway: model family, firmware version, IP address, and whether it has its own web or configuration interface.
• Which network services are enabled on each — web, secure web, file transfer, remote terminal, SNMP, and the BAS protocols.
• Who has accounts, which is covered in default passwords and shared logins.

This inventory becomes the baseline for everything else, and it's the first thing an owner's IT team will ask for.

2. Patch the supervisor, the OS and the BAS software

3. Turn off what you don't use

Every listening service is something that can be attacked. Controllers and supervisors often ship with more switched on than a site needs.

• Plain web (HTTP), FTP and Telnet. These send passwords in clear text. If the device supports HTTPS and SSH or has no need for remote terminal access, turn the plain versions off.
• Unused BAS protocols. A controller with Modbus TCP, BACnet/IP and a vendor protocol enabled, when only BACnet is used, has two doors nobody's watching.
• SNMP with default community strings. If IT doesn't monitor the device over SNMP, disable it. If they do, change the community strings or use SNMPv3.
• Discovery and file-sharing services on the supervisor PC that the BAS doesn't need.
• Unused user accounts and demo content, including sample stations, demo graphics and guest logins.

4. Secure the web interface

Operators reach most modern supervisors through a browser. That session should be encrypted:

• HTTPS only, with plain HTTP either disabled or redirected to HTTPS.
• A proper certificate, ideally issued by the owner's IT certificate authority, so browsers don't show warnings. Operators who get used to clicking through certificate warnings will click through a real one too.
• Current TLS versions only, if the platform lets you choose.
• Session time-outs so a workstation left logged in at the front desk doesn't stay logged in all weekend.

If the site is moving towards BACnet/SC, the certificate work overlaps; see BACnet/SC certificates.

5. Backups you've actually restored

A backup you've never restored is a hope, not a backup. I've seen more than one site discover during an outage that the backup job had been failing for a year, or that it saved the database but not the licence, the graphics or the drivers.

1. Back up everything needed to rebuild: supervisor database, graphics, programs, licence files, drivers, and each controller's program and configuration.
2. Keep more than one copy, including one that's offline or otherwise not writable from the supervisor. A backup on a network share the supervisor can write to can be encrypted by the same ransomware that encrypts the supervisor.
3. Test-restore on a schedule, to a spare PC or virtual machine, and confirm it runs. Write down the date and result.
4. Back up after every significant change, not just on a calendar.
5. Record where the backups are and who can get them, so the person on call at 2 a.m. can find them.

Practise the failure in "The backup that won't restore". It's the backup that matters most in the first hour of a suspected compromise.

6. Removable media and service laptops

USB drives and service laptops cross between sites and networks, which makes them a common way for malware to reach systems that aren't on the internet at all. Agree rules with the owner:

• No personal USB drives in the supervisor. Transfer files through an approved route, or use a dedicated, scanned drive.
• Service laptops are patched, protected and used for work only. The laptop you plug into forty customers' BAS networks is the most connected machine you own. See "The laptop that visits every site".
• Plug into the BAS zone, not across zones. A laptop with Wi-Fi on the office network and a cable into the BAS switch is a bridge between them.

7. Antivirus and application allow-listing

Endpoint protection on the supervisor is a good idea, and IT will usually require it. It's also a common cause of trouble: a scanner that locks the BAS database files mid-write, or quarantines a driver it doesn't recognise. Work it out with the vendor first. Most BAS vendors publish guidance on which folders and processes to exclude, and some have tested specific products.

Application allow-listing — only letting known programs run — suits a supervisor well, because the software on it rarely changes. It takes some effort to set up and needs updating when you upgrade the BAS software, so plan it with IT and the vendor rather than turning it on alone.

8. Time sync and logging

Two unglamorous settings that decide whether you can reconstruct what happened:

• Time. Point the supervisor at the site's NTP source, and have controllers take their time from the supervisor (BACnet time synchronisation) or from NTP if they support it. Wrong clocks make alarm histories confusing and logs impossible to line up. They also break certificate checks, which matters as soon as HTTPS or BACnet/SC is involved.
• Audit logging. Turn on the supervisor's audit log for logins, failed logins, user changes and point commands. Keep it long enough to be useful — months, not days — and if IT runs central log collection, ask whether the supervisor can send its logs there.

"No logs, wrong clocks" shows how much harder an investigation gets without either.

9. Physical access

Last, and easy to forget: the supervisor under the desk in an unlocked plant room, with the screen unlocked and a keyboard attached, has no security that matters. Lock the screen, lock the room or cabinet, and keep controller panels closed. The best password policy in the world doesn't help if someone can walk up to a logged-in session.

The checklist

None of this replaces segmentation or controlled remote access. It's the layer that keeps a mistake in one of those from becoming a building-wide problem.

Found a wrong number or a broken link? Tell me and I’ll fix it.