The cheapest moment to secure a building management system is before it is bought. Once the tender is awarded and the design is frozen, every security improvement becomes a change order. Good BMS cybersecurity requirements are specific, testable and tied to deliverables the owner can check.

The problem in real projects

BMS specifications are usually written by mechanical and electrical consultants who are experts in plant, controls and energy, not in cybersecurity. The cybersecurity section, if it exists, is often a single paragraph copied from a previous project: "The system shall comply with IEC 62443 and industry best practice." Integrators price what they can verify, so a vague clause is priced at zero and delivered at zero.

The result is familiar. At handover the owner receives a flat network, shared administrator accounts, a cellular router for vendor support, default passwords on controllers and no documentation that would let the IT or OT security team take ownership. Fixing this after occupancy means downtime, disputes over scope and, often, accepting the risk because the budget is spent.

Why common approaches fail

  • Referencing a standard without scoping it. IEC 62443 is a family of documents covering asset owners, service providers, systems and components. "Comply with IEC 62443" does not say which part, which security level or which requirements.
  • Requirements without acceptance criteria. "The system shall be secure" or "remote access shall be secure" cannot be tested, so it cannot be rejected at commissioning.
  • No deliverables. If the tender does not require a network diagram, an account register or a hardening report, they are not produced.
  • Security added after design freeze. If the IT or security team first sees the design at submittal review, architecture decisions are already made.
  • No flow-down to subcontractors. Lighting, metering, lifts, access control and specialist plant vendors connect to the BMS but are contracted separately, often with no security requirements at all.

A recommended approach

Structure the cybersecurity section as a set of numbered, testable requirements grouped by topic, each with a verification method (document review, inspection, test at FAT, test at SAT) and an owner-side reviewer. Use IEC 62443-3-3 system requirements and IEC 62443-2-4 service provider requirements as the reference frame, and state a target security level (SL-T) per zone where a risk assessment per IEC 62443-3-2 has been done. Where it has not, specify the controls directly rather than citing a security level nobody has derived.

The sections below cover what each topic should contain.

1. Network architecture

  • Separate zones for field, automation, supervisory and a BMS DMZ, with the corporate network and the internet outside the BMS boundary.
  • All inter-zone traffic through owner-approved firewalls with default-deny rules (IEC 62443-3-3 SR 5.1 and SR 5.2).
  • A conduit matrix listing every permitted flow: source, destination, protocol, port, direction and purpose.
  • No direct connection from controllers to the internet or cloud services. Cloud analytics only through a broker in the DMZ.
  • Controls on BACnet/IP broadcast distribution: minimal BBMDs, foreign device registration disabled unless approved. BACnet/SC preferred for new IP segments where supported.

2. Accounts and authentication

  • Individual named accounts for all human users of supervisory software, engineering tools and network devices (SR 1.1). No shared "admin" or integrator login.
  • Role-based access with at least operator, engineer and administrator roles, documented in a role matrix.
  • Integration with the owner's directory where the product supports it, or a documented local account process where it does not.
  • All default passwords changed on every device before SAT, including controllers, routers, gateways, switches and BACnet service passwords.
  • Service and integration accounts listed with their purpose, privileges and credential storage location.

3. Remote access

  • Remote access only through the owner's remote access service (VPN or ZTNA) terminating in the BMS DMZ, with MFA (SR 1.13 addresses access via untrusted networks).
  • Prohibition of cellular routers, port forwards, and vendor remote-control or cloud tunnelling tools unless explicitly approved in writing.
  • Sessions individually attributable, time-limited, and logged. Session recording where the owner's platform provides it.
  • The owner can disable all integrator access without the integrator's involvement.

4. Logging and time

  • Supervisory servers, workstations, firewalls and switches forward security events by syslog or an agreed format to the owner's log platform (SR 2.8).
  • A list of the security events each component can log, and confirmation of which are enabled: logons, failed logons, account changes, configuration changes, setpoint overrides, and alarms acknowledged.
  • All components synchronized to an owner-designated time source.
  • Read-only network access (SPAN or TAP points) on the supervisory-to-automation conduit for passive monitoring.

5. Hardening

  • Servers and workstations hardened to a named baseline, such as the relevant CIS Benchmark, with deviations documented and justified.
  • Unused services, ports, protocols and accounts disabled on all components (SR 7.7). Controller web servers, Telnet and FTP disabled unless required.
  • Endpoint protection or application allowlisting on Windows hosts, with the vendor's compatibility confirmation.
  • Removable media controls on operator and engineering workstations.
  • Secure configuration of network equipment: management on a dedicated interface or VLAN, no cleartext management protocols.

6. Patching and vulnerability management

  • A statement of supported operating system and software versions at handover, with vendor end-of-support dates.
  • The vendor's process and timescale for testing and approving operating system and application patches.
  • Commitment to notify the owner of relevant published vulnerabilities in delivered products for the warranty and support period.
  • A software bill of materials or, at minimum, a component and version list for supervisory software and controller firmware.

7. Documentation deliverables

Deliverables are where requirements become enforceable. Make each one a named item in the submittal schedule:

  1. As-built network architecture and zone and conduit diagram.
  2. Firewall rule set and conduit matrix.
  3. Asset inventory: hostname, IP, MAC, model, firmware, location, zone.
  4. Account and role register (credentials themselves handed over through an agreed secure method, never in the document).
  5. Hardening report with baseline, deviations and justification.
  6. Backup and restore procedure, plus backups of every server and controller configuration.
  7. Remote access procedure and integrator access list.
  8. Security test reports from FAT and SAT.

8. FAT and SAT security testing

Add security test cases to the factory acceptance test (FAT) and site acceptance test (SAT) plans, witnessed by the owner or the owner's security adviser. Examples of test cases:

  • Attempt to log on to each component with known default credentials. Expected: rejected.
  • From the corporate zone, attempt to reach controller IP addresses and ports. Expected: blocked and logged.
  • Perform an action as an operator-role user that requires engineer rights. Expected: denied.
  • Generate a failed logon and a configuration change. Expected: events received at the owner's log platform with correct time.
  • Run an authenticated vulnerability scan of servers and workstations, agreed in scope with the vendor to avoid controller disruption. Expected: no unresolved critical findings, others documented.
  • Restore a server and a controller from backup. Expected: system returns to operation within the agreed time.
  • Confirm remote access works only through the owner's path and can be disabled by the owner.

Security functionality verification is itself a requirement in IEC 62443-3-3 (SR 3.3), which gives a useful reference for why these tests belong in the acceptance plan.

9. Handover

  • Transfer of all administrative credentials, certificates and keys to the owner, followed by rotation of integrator passwords.
  • Removal or disabling of commissioning accounts, temporary firewall rules and test equipment.
  • Ownership of any certificate authority used for BACnet/SC or TLS, with signing keys held by the owner.
  • Briefing for the owner's operations and security teams on the architecture, monitoring points and incident contacts.

Making requirements verifiable

Each requirement should answer three questions: what exactly must be true, how will it be checked, and at which stage. The table shows the difference.

Weak requirementVerifiable requirement
Remote access shall be secure.Remote access shall be possible only via the owner's ZTNA service with MFA. No other inbound path shall exist. Verified at SAT by inspection and connection test.
The system shall use strong passwords.All default credentials shall be changed before SAT. Verified at SAT by attempted logon with vendor defaults on every component.
The network shall be segmented.Controllers shall reside in automation zones reachable only from the supervisory zone on the ports in the approved conduit matrix. Verified at SAT by test from each adjacent zone.
The system shall support logging.Security events listed in Appendix X shall be forwarded to the owner's log platform. Verified at SAT by generating each event.

Include a compliance matrix in the tender returns so bidders state, per requirement, whether they comply, partially comply with a stated deviation, or do not comply. This surfaces gaps at bid evaluation, when they can still influence the award.

Common gaps

  • Interfacing systems left out. Lighting control, energy meters, lifts, generators, fire alarm interfaces and access control gateways often bypass the BMS security requirements because they are procured under separate packages.
  • Cloud and analytics connectors. Energy optimization and remote monitoring services are added late with outbound tunnels that nobody reviewed.
  • Warranty period ownership. Who patches, who monitors and who manages accounts between practical completion and the end of the defects period is often undefined.
  • No owner-side reviewer. Requirements are written but nobody with security competence reviews submittals or witnesses tests.
  • Credentials in documentation. Passwords handed over in O&M manuals or spreadsheets.
  • Unrealistic requirements. Demanding features controllers cannot support, which bidders accept and then deviate from at commissioning. Validate requirements against what the market can deliver.

Where to start

Write a reusable BMS cybersecurity specification section once, with numbered requirements, verification methods and a deliverables list, and include it in every tender. Pair it with a compliance matrix for bidders and security test cases in the FAT and SAT plans. Most importantly, assign an owner-side reviewer with the authority to reject submittals and fail acceptance tests. Requirements that are never checked will not be delivered.