A building controller can be small enough to fit in a panel and important enough to shut down a floor. When it is exposed, unsupported, or connected to the wrong network, the failure does not stay inside IT or facilities. It can affect tenant comfort, access, refrigeration, ventilation, life-safety coordination, and business continuity. Knowing how to secure building controllers means treating them as operational assets with named owners, controlled connections, and a recovery plan - not as forgotten devices installed during construction.
The common failure is not a lack of security products. It is fragmented responsibility. Facilities may own the equipment, IT may own the network, an integrator may hold administrator credentials, and a contractor may have left a remote connection in place. Each party can assume someone else is managing the risk. That assumption is the gap.
Start With Ownership and a Complete Inventory
You cannot secure a controller that nobody can identify, locate, or support. Begin by establishing a single system of record for every building controller, supervisory device, gateway, and associated engineering workstation. This includes controllers serving HVAC, lighting, energy management, access-related systems, water management, and other operational technology.
The record should identify the controller's physical location, function, network address, communications path, software and firmware version, support status, configuration backup location, and accountable owner. Record the vendor or service provider with access, but do not confuse access with ownership. One internal owner must be accountable for approving changes, reviewing access, and escalating failures.
A useful inventory also distinguishes between devices that merely report data and devices that can change the physical environment. A temperature sensor creates a different risk profile than a controller that starts equipment, unlocks a door interface, or changes air handling sequences. Prioritize the controllers that can interrupt critical operations or create unsafe conditions.
Establish the approved baseline
For each controller type, define what normal looks like. That baseline should include approved firmware, intended network ports and protocols, expected upstream connections, user roles, configuration settings, and alarm behavior. Without it, teams have no reliable way to recognize unauthorized change or configuration drift.
This work is not glamorous, but it prevents long troubleshooting calls when a controller behaves differently after a network change, service visit, or power event. Documentation is a control. If it is outdated, the control has failed.
Secure Building Controllers With Network Separation
Building controllers should not share unrestricted network access with user devices, guest wireless, tenant systems, or general business applications. A flat network turns a compromise in one area into a pathway toward equipment that controls the facility.
Create a defined operational technology network zone for building systems. Segment controllers by function and criticality where the environment warrants it. For example, core central plant controls, tenant comfort systems, and engineering workstations may require different rules because their consequences and support needs differ.
Firewalls between zones should permit only the communications that are documented and required. Allowing broad any-to-any traffic because it is convenient during commissioning is a familiar shortcut with a long tail. Temporary rules often become permanent rules, especially after project turnover.
Remote access deserves the same discipline. Controllers should not be directly reachable from the public internet. A service provider who needs remote access should use an approved, authenticated pathway through the organization's controlled remote-access environment. Access should be limited to the specific systems required, logged, and removed when the work is complete.
Segmentation does create operational trade-offs. Overly restrictive rules can interrupt monitoring, trend collection, or alarm delivery. The answer is not to open everything. Validate the required traffic during commissioning, document it, and test it after changes. One standard for design, implementation, and acceptance reduces the friction later.
Control Who Can Change the Environment
Many controller environments still rely on shared administrator accounts, default passwords, and credentials held only by outside service personnel. That arrangement may feel efficient until an urgent repair, audit, personnel change, or security incident exposes the lack of control.
Use named accounts whenever the platform supports them. Apply least privilege so a user who needs to view alarms does not automatically receive authority to alter schedules, programs, or setpoints. Require multi-factor authentication for remote and administrative access where technically feasible. If a legacy controller cannot support modern authentication, compensate with stronger controls around the jump host, network segment, and physical access path.
Default credentials must be changed before final acceptance. So must temporary accounts used during installation. This is a turnover requirement, not a cleanup task for a later date.
Access should also expire. Contractor access, commissioning accounts, and emergency vendor accounts need an approval period and a review date. A credential that remains active because nobody remembered to disable it is not an exception. It is unmanaged access.
Treat Firmware and Configuration as Lifecycle Assets
Unsupported firmware is a building risk, not just a technical nuisance. Controllers can remain in service for years, sometimes long after their software has stopped receiving security fixes. That does not always mean immediate replacement is required. It does mean leadership needs a documented decision: update, isolate, replace, or accept the risk with compensating controls.
Patch management for operational technology cannot follow a generic desktop schedule. A rushed update can disrupt sequences, communications, or integrations that keep the building functioning. Before changes, confirm compatibility, back up the current configuration, define a maintenance window, and identify a rollback path. After changes, test the functions that matter - not merely whether the device responds to a network ping.
Configuration backups require equal attention. Store current, recoverable copies in a controlled location separate from the controller itself. Include programs, graphics where relevant, setpoints, schedules, database exports, licenses, and network settings. A replacement controller is of limited value if the operating logic cannot be restored.
For high-impact systems, maintain a tested replacement process. Know which hardware is compatible, where it can be obtained, who can load the configuration, and how long restoration should take. Recovery objectives should be based on operational impact, not on guesswork during an outage.
Govern Third-Party Service Access
Outside specialists are often necessary. The problem is not the presence of contractors or service providers. The problem is unmanaged access without a defined scope, record, or exit condition.
Every third party with controller access should have a documented purpose, authorized systems, approved connection method, individual identity, and accountable internal sponsor. Their work should be logged through a change process that captures what was changed, why it was changed, and how the result was validated.
This matters after construction as much as during it. Project closeout frequently leaves behind undocumented accounts, remote tools, unmanaged cellular connections, and incomplete as-built records. Final acceptance should include security turnover, not just confirmation that equipment powers on and alarms appear.
A practical acceptance package should contain, at minimum:
- An accurate controller and network inventory
- Current administrator and service-access records
- Approved network diagrams and firewall rules
- Firmware and support-status records
- Configuration backups and restoration instructions
- A tested remote-access and incident-escalation procedure
If these items are missing, the system is not fully turned over. It is still dependent on institutional memory and vendor availability.
Test Recovery Before an Incident Forces It
Security controls are only credible when they work under pressure. Schedule tests that simulate conditions your teams can realistically face: a failed controller, lost network connectivity, an unavailable cloud service, a compromised engineering workstation, or an accidental configuration change.
The goal is not to create unnecessary disruption. The goal is to verify that operations, facilities, IT, and service partners know their roles. Can the team identify the affected controller quickly? Can they isolate it without taking down unrelated systems? Can they restore the approved configuration? Can they prove that alarms and critical sequences return to normal?
Document the result of each test, including delays, missing information, and unclear ownership. Those findings should feed the next maintenance plan, network change, or capital refresh decision. A runbook that has never been tested is a document, not an operational capability.
Make Security Measurable
Building controller security becomes sustainable when it is reviewed as an operating discipline. Track a small set of meaningful measures: the percentage of controllers inventoried, supported, backed up, segmented, and reviewed for access; the number of unauthorized or expired accounts removed; and recovery-test results against the expected restoration time.
Avoid reporting metrics that look clean but hide the real condition. A high patch percentage means little if the unpatched devices control the most critical equipment. Focus attention on consequence, exposure, and ownership.
The standard should be simple: no controller operates without a known owner, known network path, known support condition, and known recovery method. That discipline turns building control security from a collection of handoffs into one accountable operating model - and gives your team a better chance to keep the building running when something goes wrong.