A building management system can keep a property comfortable, efficient, and safe - until an unmanaged connection, shared service password, or unsupported controller turns it into an entry point. A BMS cybersecurity risk assessment is not a paperwork exercise for the IT department. It is a practical review of how building controls connect, who can change them, what could fail, and whether the organization can recover without losing control of the building.
For commercial properties, the consequences are operational. A compromised BMS can disrupt HVAC schedules, alarms, access to mechanical spaces, tenant comfort, energy management, and response during an incident. The issue is rarely one defective device. More often, the risk sits in the handoff between facilities, IT, contractors, integrators, and remote support providers. Everyone owns a piece. No one owns the outcome.
What a BMS Cybersecurity Risk Assessment Should Answer
A useful assessment answers a small set of direct questions. What building systems are connected to the BMS? Where do those systems connect to the enterprise network, the internet, or vendor remote-access tools? Which accounts can make changes? Which components are unsupported or cannot be patched? And if a controller, server, or network segment fails, who has the authority and the instructions to restore operations?
The work must account for the actual built environment, not only the system diagram produced at installation. Buildings change. A tenant improvement adds a controller. A controls contractor creates a remote account during commissioning. A facilities team installs a temporary cellular gateway to solve an urgent service issue. Years later, those decisions may be undocumented, still active, and difficult to trace.
The goal is to establish a defensible baseline: a current inventory, known data paths, approved access methods, risk-ranked findings, and assigned owners. A report that identifies vulnerabilities but leaves ownership unresolved does not reduce risk.
Start With the Operational Scope
Do not begin with a generic vulnerability scan. Many BMS components are sensitive, old, or designed for predictable control traffic rather than aggressive discovery activity. Poorly planned scanning can create instability, trigger alarms, or interrupt communications with field devices. The assessment method should be agreed on by IT, facilities, and the controls team before any testing begins.
First, define the systems in scope. This often includes central BMS servers and workstations, supervisory controllers, field controllers, gateways, engineering laptops, virtual machines, switches, wireless bridges, remote-access platforms, and cloud-connected monitoring tools. It may also include connected HVAC equipment, lighting controls, metering, generators, elevators, water systems, and physical-security integrations where they share networks or management platforms.
Then identify the business functions those systems support. A corporate office has different tolerances than a data environment, health-related facility, manufacturing site, or mixed-use property. The risk is not simply that a device is old. Risk depends on exposure, criticality, available compensating controls, and the operational effect if the device is unavailable or manipulated.
For example, an unsupported controller on an isolated network may be manageable while a newer controller exposed through broad remote access may be a higher immediate concern. Neither finding should be dismissed. They require different treatment plans.
Build the Inventory From the Ground Up
The most common assessment failure is trusting an incomplete inventory. Facilities may have a list of assets, IT may have a network-management view, and the controls provider may have commissioning records. Those sources seldom match. A meaningful inventory reconciles them.
For each asset, capture its function, location, owner, network address or connection type, operating system or firmware version, support status, and dependencies. Document whether the device is managed by IT, facilities, a contractor, or a third party. If the answer is “everyone,” the answer is effectively no one.
Physical verification matters. Walk telecom rooms, mechanical rooms, roof spaces, and control panels. Compare installed equipment against drawings and network records. Look for unmanaged switches, cellular routers, wireless links, abandoned workstations, and engineering ports left available after projects close. These are not minor documentation issues. They are often the paths around intended security controls.
The inventory should also identify systems that cannot be patched without downtime, revalidation, or a vendor visit. That does not excuse inaction. It tells the organization where segmentation, access restrictions, spare hardware, and recovery planning must carry more of the protection burden.
Trace Every Connection and Access Path
A BMS does not need broad access to the enterprise network to perform its job. Yet broad access is common because it was convenient during installation or because network rules were never revisited after turnover. The assessment should map traffic flows between BMS servers, controllers, operator workstations, remote users, vendors, cloud services, and enterprise systems.
Pay particular attention to remote access. Vendor support can be necessary, especially for specialized controls. It should not mean permanent, anonymous connectivity. Confirm whether remote access uses named accounts, strong authentication, time-limited approval, session logging, and an approved support path. Shared credentials, always-on remote tools, and undocumented modem connections should be treated as priority findings.
Network segmentation is equally important. Building controls should be separated from corporate user networks and from other operational systems based on function and risk. Segmentation is not a promise that nothing can happen. It limits how far an incident can travel and gives responders a clearer way to contain it.
A practical access review examines at least these four areas:
- Administrative accounts, including former employees, contractors, and generic shared logins.
- Remote support accounts, approval procedures, authentication controls, and session records.
- Firewall rules and network paths that allow unnecessary communication.
- Physical access to panels, switches, servers, and engineering ports.
Each finding needs an owner and a due date. “Vendor to review” is not an action plan unless a specific internal leader is accountable for acceptance and closure.
Test Recovery, Not Just Prevention
Prevention controls matter, but recovery separates a manageable incident from extended downtime. Many buildings have backups that have never been restored, drawings that do not match installed conditions, and no runbook for operating mechanical systems when the BMS is unavailable.
The assessment should verify that configuration backups exist for servers, controllers, and critical network devices. It should confirm where they are stored, whether they are protected from routine administrator access, and whether restoration has been tested. A backup that cannot be located, validated, or restored within the required operational window is not a recovery capability.
Document the manual fallback plan as well. Can facilities maintain safe temperatures, monitor critical alarms, or operate essential equipment if the central interface is unavailable? Who is called first? Who can approve emergency vendor access? What changes must be documented before normal service is restored? These answers should be available to the people on call, not buried in a project folder.
Recovery planning also exposes a hard truth: some legacy environments cannot be fully secured without modernization. That does not mean waiting for a capital project. It means documenting the exposure, restricting access now, planning replacement deliberately, and making risk acceptance an executive decision rather than an accidental one.
Turn Findings Into Operating Controls
An assessment is valuable only when it changes daily operations. The strongest outcome is a risk register tied to a control plan: the finding, affected asset or function, operational impact, risk rating, remediation approach, accountable owner, target date, and evidence of closure.
Some actions are straightforward. Remove dormant accounts, disable obsolete remote-access tools, update firewall rules, and secure exposed panels. Others require coordination: replacing unsupported controllers, redesigning network segments, or changing service contracts so vendor access follows a defined approval process.
The governance model should be equally clear. Facilities owns the operating requirements and knows the consequences of system disruption. IT owns core network and identity controls. Security sets policy, monitoring expectations, and incident response requirements. Contractors and service providers execute within those rules. One accountable leader must resolve conflicts and confirm that work is complete.
Review the BMS risk posture after major renovations, system integrations, ownership changes, vendor transitions, or security incidents. At a minimum, revisit access, inventory, and recovery evidence on a regular operating cadence. Building technology is not static after commissioning, and its security cannot be static either.
The practical test is simple: if a suspicious connection or failed BMS server appears at 2 a.m., the organization should know what is connected, who can isolate it, how critical functions will continue, and who is accountable for restoration. That level of clarity is the real product of a well-run assessment.