A question I keep asking: who can open a door or change a building's air-handling settings from outside the building? In a hospital, clinic, or distribution center, the answer may be a facilities manager, an integrator, or an account nobody has reviewed since installation.

That system belongs in the security conversation.

NIST's operational technology guidance explicitly includes building automation and physical access control systems. These systems interact with the physical environment, and they have performance, reliability, and safety requirements that change how security controls should be planned.

I have spent two decades in rooms where technical ownership and operational ownership do not line up neatly. IT manages the network. Facilities owns the controller. Security writes the standard. An integrator holds the admin credentials. A night-shift nurse taps a badge and expects the door to open. If the system fails, that nurse does not care which team owned the firewall rule. She needs someone who can restore the service safely.

Imagine a controller stops reporting at 2:10 a.m. The facilities lead calls the integrator. Nobody can say which remote account the technician plans to use, who approved the connection, or if the session will be recorded. That is a governance gap, not a help-desk inconvenience.

A building system is a computer with physical authority.

Put the building on the asset map

An inventory should tell me more than the vendor name and purchase date. I want the system's location, purpose, owner, support status, network paths, user accounts, and what happens if it stops working. I want the facilities team to validate the records because a spreadsheet cannot tell me what a controller does in the building.

CISA's OT inventory guidance calls for owners to define scope, assign inventory roles, inspect systems, record asset attributes, and keep information current through the asset lifecycle. That is a practical starting point for building systems too.

Start with sites where an outage affects people or essential operations. Map the controllers, badge systems, and network connections. Name one accountable operating owner for each system. If the vendor is the only party who can explain how to recover it, that dependency belongs in the risk register.

Make remote support visible

Remote access should be a deliberate, observable event. Use named accounts. Require local approval before a vendor session when feasible. Keep the path monitored. Log who connected, when, and what changed. Remove access when a contract ends or a technician leaves.

CISA's guidance for working with third-party control-system integrators recommends monitored routes and on-demand remote access. It also points to contract terms for authorized personnel, change and patch processes, local engineering support, and the ability to recover without the integrator.

The contract is part of the control. If it does not say how access is approved, recorded, updated, and removed, the security team will be negotiating during an incident.

Plan for safe change and recovery

I do not want teams applying a standard IT patch calendar to controllers without facilities input. A rushed change can disrupt building operations. The opposite response, leaving systems untouched because they are sensitive, is not a plan either.

Set maintenance windows with the operating owner. Test changes where possible. Keep a rollback path. Document safe manual operation and make sure the people on shift know how to use it. CISA recommends considering maintenance windows, offline software backups, and the ability to operate independently if an integrator is compromised. Those details should be tested, not assumed.

Here are three questions I want leaders to answer:

  • Can we identify every connected building controller and the person accountable for operating it?
  • Can we see and approve each vendor session into a building system?
  • If the supplier is unavailable during an incident, can staff keep the essential service running safely?

This does not require a building-wide rebuild. Start with the systems tied to people and operations. Map the access. Agree on who owns the next change. Test one recovery path before the next renewal.

Technology leaders often leave buildings off the digital map because the systems have always been called “facilities.” That label does not make their network connections disappear. The CISO and facilities leader should share the decision, and procurement should make the supplier's responsibilities explicit.

Fellow CISOs and facilities leaders, how are you finding and governing the vendor accounts already inside your buildings? Here's what I'm watching this quarter.

Lekshmy Sankar, PhD