How do you secure a smart building against cyberattacks?

The starting point is to stop thinking of a building's control systems as IT. They are operational technology: equipment whose failure has physical consequences, not just data consequences. Securing them means knowing exactly what is connected, giving each system an accountable owner, controlling who can reach it remotely, keeping its software supported, and being able to run the building safely when something has been compromised. None of that is achieved by buying a product or commissioning a one-off penetration test. It works best as a programme led by the owner, with contractual obligations on every supplier.

Physical consequences

NIST's guide to operational technology (OT) security, SP 800-82 Revision 3 (the current final version; NIST has published a draft Revision 4 for public comment), lists building automation systems and physical access control systems alongside industrial control systems as OT. It describes a building automation system as controlling heating, ventilation and air conditioning, lighting, electrical, fire, access control and other utility systems. For an owner, the implication is that a cyber incident in these systems can affect comfort, safety, security and the ability to open the doors, not only the confidentiality of records.

NIST also notes that OT has become less isolated as it has adopted standard computers, IP networks and remote access. A single building may now combine controllers installed a decade ago, cloud dashboards added last year and several contractors, each with their own way in. Security has to cover that whole mixture.

Five decisions no tool can make

Some questions determine whether any security tool will be used properly, and they belong to the owner:

• Who is accountable? One person needs to be responsible for OT cyber risk across the building, even if delivery is shared between the IT team, the facilities manager and contractors; without that, every gap becomes someone else's problem.
• What actually exists? That calls for an inventory of controllers, servers, gateways, network equipment, software versions, user accounts and every external connection, including equipment the controls contractor regards as "theirs".
• Which functions matter most? Rank systems by the consequence of losing or misusing them, with life-safety interfaces, access control and critical plant above meeting-room displays.
• Who can get in from outside? List every remote-access route, who uses it and how it is approved.
• What happens when something goes wrong? Decide how the building will operate if a system has to be disconnected, and who makes that call.

These decisions map naturally onto the six functions of the NIST Cybersecurity Framework 2.0: Govern, Identify, Protect, Detect, Respond and Recover. The framework describes outcomes and does not prescribe products, which makes it a useful structure for a board or asset manager tracking progress.

The technical controls that matter most

Segmentation is the foundation. Building systems should be separated from corporate and guest networks, and from each other, according to risk and management responsibility, with only the communications the operation needs permitted between them. NIST recommends mapping the required data flows first and then configuring firewalls or gateways to allow only those flows. How to divide a building into zones is a design subject in its own right.

Remote access is a common weak point. NIST's guidance is that remote access to OT should be justified, limited to the business need and granted through an approved request process, that multi-factor authentication should be considered, and that sessions should be monitored and access removed when no longer required. CISA and the FBI add a practical preference for on-demand access that the operator enables, through routes the operator can monitor. Always-on contractor VPNs are among the first things we would review.

Accounts and credentials need the same discipline: default passwords removed, named accounts for individuals, with no shared engineer login, and accounts disabled when people or contractors leave. The support status of every product should be recorded. NIST notes that OT updates often cannot be applied as quickly as IT patches and need testing and planned outages, which makes a documented update process all the more important. Where equipment can no longer be updated, the owner has to choose compensating controls or a replacement date.

Monitoring only helps if someone looks at it, so decide which events will actually be reviewed: new devices, configuration changes, failed logins and remote sessions. Recovery, finally, depends on current configuration backups and software installers kept offline, restoration that has been tested, and manual or local operation that has been practised.

Security has to be written into contracts

Third parties design, install and maintain much of a building's technology, so many controls happen only if contracts require them. Remote-access arrangements, change and patch management, named personnel and an inventory of everything each supplier installs belong in every service agreement.

For new products, CISA's Secure by Demand guide for OT owners and operators, written with partner agencies including the European Commission's DG CONNECT and the UK's National Cyber Security Centre, sets out the security properties to ask manufacturers about during selection, among them secure-by-default settings, strong authentication, logging, open standards and transparent handling of vulnerabilities. In the EU, the Cyber Resilience Act (Regulation (EU) 2024/2847) will apply its main manufacturer obligations to products with digital elements from 11 December 2027. Manufacturers will have to handle vulnerabilities for a defined support period, normally at least five years, and make its end date, to at least the month and year, clear at the time of purchase. That will help owners compare products, but it does not secure an installed building by itself.

The ISA/IEC 62443 series rests on shared responsibility between asset owners, product suppliers, integrators and service providers. It is reasonable to ask suppliers how their products and services align with the relevant parts, but a claim of alignment should be accepted only when it is backed by evidence specific to the product and service.

Where to begin in an occupied building

For a building already in use, we would usually work in this order:

1. Appoint the accountable owner and agree a short list of priority systems.
2. Build the inventory and connection map, including all remote access.
3. Close the most obvious exposures: internet-reachable interfaces, default credentials, unmanaged remote access.
4. Agree segmentation and permitted flows, then implement them in planned stages with the controls contractor present.
5. Write recovery and local-operation procedures, and test them.
6. Update maintenance and supply contracts so the improvements survive the next change of contractor.

Each step needs the operational team involved, because a security change that stops a chiller, locks a fire exit or blocks a lift is not an improvement. NIST is explicit that any security measure that impairs safety is unacceptable.

Four questions for your team this month

• Can we produce a current list of every external connection to our building systems?
• Which suppliers have remote access today, and how do we know when they use it?
• Which controllers or servers run software that is no longer supported?
• If we had to disconnect the building management system from the network tomorrow, what would stop working, and who would operate the plant?