BMS cybersecurity requirements: a checklist for specifications and acceptance
A BMS cybersecurity checklist for a specification is a table with three columns: the requirement family, the requirement written as a testable statement, and the evidence the contractor produces at acceptance. Ten families cover a building management system: inventory, segregation, remote access, accounts, hardening, updates, logging and time, backup, protocols, documentation. The checklist draws on public guidance: the guide on building management systems published by ANSSI, the French national cybersecurity agency (ANSSI-PA-110, version 1.0, 27 April 2026), the NIST Guide to Operational Technology Security (SP 800-82 Rev. 3, September 2023) and the CISA Cross-Sector Cybersecurity Performance Goals (CPG 2.0, released 11 December 2025).
Why building systems are a target
A BMS is an industrial control system that commands heating, ventilation, lighting, sometimes access control and metering, and that an integrator may reach from outside the building. Its controllers were designed for availability rather than confidentiality, its protocols were born without authentication, and it stays in service longer than office IT, with fewer updates. NIST covers building automation among the operational technology of SP 800-82 Rev. 3; the ANSSI guide of April 2026 is dedicated to it. Exposure is widening: Directive (EU) 2024/1275 of 24 April 2024 asks Member States to require building automation and control systems, where technically and economically feasible, in non-residential buildings whose heating or air-conditioning systems have an effective rated output above 290 kW by 31 December 2024, and above 70 kW by 31 December 2029 (Article 13(9)), and more systems are connected to the corporate network or to a cloud service.
The ten requirement families
| Family | What the specification requires | Evidence at acceptance |
|---|---|---|
| 1. Inventory and network drawing | Every controller, server, gateway, switch and connected device listed with role, address and software version; an up-to-date network drawing. | Inventory and drawing in the as-built file, checked by sampling. |
| 2. Segregation and flow filtering | BMS network separated from the office network and the Internet; field, automation and supervisory levels segregated; flows allowed by explicit rules only. | Flow matrix, firewall configuration, access test from the office network (must fail). |
| 3. Administration and remote access | Remote maintenance only through a dedicated, encrypted channel terminated close to the controllers, activated on demand for a set duration and logged; no permanent access; named administrator accounts with strong authentication. | Demonstration of activation and deactivation, log extract, remote access register. |
| 4. Accounts and authentication | Default accounts and passwords removed or changed; named accounts; profiles (view, operate, administer); integrator accounts disabled at acceptance unless a maintenance contract says otherwise. | List of accounts and rights, login with default credentials (must fail), passwords handed over sealed. |
| 5. Hardening | Unused services, ports and web interfaces disabled; boot from removable media blocked; USB ports controlled; dedicated supervisory workstations. | Configuration record per device, port scan against the expected list. |
| 6. Updates and vulnerabilities | Versions current at delivery; tested update procedure; security patches during the warranty within a stated lead time; operator informed of published vulnerabilities. | Table of installed versions against vendor versions, procedure in the as-built file. |
| 7. Logging and time synchronisation | Connections, administration actions and programme changes logged; controllers and supervisory system synchronised, including over BACnet; retention period stated. | Timestamped log extracts, clock check across devices. |
| 8. Backup and restore | Controller programmes, supervisory configuration and databases backed up off the system; restore tested; manual fallback for vital plant. | Restore test witnessed by the owner, signed report. |
| 9. Protocols | Secure protocols where they exist (BACnet/SC, HTTPS, OPC UA with security enabled, SSH); unencrypted protocols confined to the field network; Modbus and BACnet flows filtered. | Network capture or configuration showing the active protocols. |
| 10. Documentation and reversibility | Source programmes, tools and licences handed over or identified; security file in the as-built documentation; incident procedure; conditions for takeover by a third party. | As-built file checked against a signed checklist. |
Writing requirements that can be tested
A requirement has four parts: identifier, level, statement, evidence. The level is a choice the owner makes once, in the preamble: an essential set for every BMS package and an enhanced set for sensitive sites or systems tied to security functions; without it, bidders price different things and the lowest bid wins by omission. The statement describes a behaviour or a deliverable, never an attitude: "the contractor shall apply security best practice" cannot be priced or accepted, whereas "remote maintenance access is established through an encrypted tunnel terminated on a dedicated device close to the controllers, activated by the operator for a defined duration and deactivated automatically at its end" can be both. Citing the public recommendation behind each statement, for example the R-number of the ANSSI guide, lets the reviewer check that nothing was skipped. The evidence column names, for each line, a document, a demonstration, a test or an extract, and who signs it.
Running the acceptance
The acceptance checklist repeats every requirement with a result (compliant, partial, non-compliant, not applicable), the evidence provided and a comment. A compliance rate is useful for tracking, but some non-conformities block acceptance whatever the rate: default credentials still active, a permanent remote access that is not logged, a device reachable from the Internet, no restorable backup. "Not applicable" is justified in writing. The same checklist, with a scoring column, serves as the cybersecurity part of the bid evaluation grid: bidders answer requirement by requirement, describe their remote access arrangement and their update commitments, and name the skills assigned. The structure of the whole tender is described in the article on the BMS specification template.
Remote maintenance: the weak point to close first
A remote access that nobody turned off leaves the building open to anyone holding its credentials; the ANSSI guide of April 2026 devotes its recommendation R6 to remote access to the BMS. The chain to require: a dedicated access device, an encrypted tunnel, activation by the operator for a stated duration, automatic deactivation, named accounts with strong authentication, a log of every session, and a register with who, when, why, authorised by whom and closed when. Integrators who maintain many sites may propose their own portal; the specification can accept it provided the owner keeps the switch, the log and the right to audit. Where the equipment supports it, the secure variant of the field protocol is required; the article on specifying BACnet/SC explains what to ask for and how to accept it.
Keeping it secure after handover
Security decays as soon as nobody tends it. Two registers are enough for a facility team: the remote access register and the equipment inventory with versions and the date of the last update. The maintenance contract states who supplies security patches, within what lead time, and how the integrator's accounts are handled between visits; an annual review compares the inventory with published vulnerabilities and repeats the restore test. The BMS commissioning and acceptance checklist shows where these sit in the handover sequence.
FAQ
Is the ANSSI guide binding?
No. ANSSI-PA-110 is a guide of recommendations, published under the French open licence (Licence Ouverte v2.0), which allows reuse with attribution. The guide states that its recommendations are not normative unless a regulation provides otherwise; in a tender, they bind the contractor once the owner writes them into the specification as requirements.
Which reference should a non-French project cite?
The families are the same everywhere; only the reference changes. NIST SP 800-82 Rev. 3 (September 2023) is the US federal guide to OT security, the CISA CPG 2.0 (11 December 2025) give a voluntary baseline that CISA aims in particular at small and medium-sized organisations, and IEC 62443 is the international series for industrial automation security.
What if the building already has a BMS with a permanent remote access?
Treat the next maintenance contract as the specification. Require the inventory and network drawing first, then the switch from permanent to on-demand access with logging, then the removal of default accounts and a restore test.