Default and Hardcoded Credentials
Default credentials are endemic across BMS environments. Controllers, management interfaces, and field devices routinely ship with factory-set usernames and passwords — often simple, publicly documented combinations that are rarely changed during installation.
In many BMS deployments, installation is carried out by facilities contractors whose primary objective is system commissioning, not security hardening. Default credentials are left in place, management interfaces are left internet-accessible, and no security review is conducted before the system goes live.
Hardcoded credentials — usernames and passwords embedded directly in firmware that cannot be changed — compound the problem. These credentials, once discovered and published, remain valid across every device running that firmware version indefinitely.
How attackers exploit it: Automated scanning tools identify internet-exposed BMS interfaces and attempt login using known default and hardcoded credential lists. The process is fast, scalable, and requires minimal technical skill.
Unpatched Firmware and Legacy Software
BMS devices are designed for longevity. Controllers and field devices are commonly deployed for 10 to 20 years — far outlasting the vendor support lifecycle for the firmware and software they run.
The result is a large installed base of BMS infrastructure running outdated, unsupported firmware with known, publicly disclosed vulnerabilities that will never be patched. Vendors may have ceased support entirely. In some cases, the original manufacturer no longer exists.
Even where patches are available, applying them requires taking building systems offline — disrupting HVAC, access control, or other operational functions — which makes patching operationally complex and infrequent.
How attackers exploit it: Attackers maintain knowledge of vulnerabilities in widely deployed BMS firmware versions. Organizations running unpatched systems are identified through internet scanning and targeted for exploitation of known CVEs.
Insecure Network Protocols
BMS environments rely on communication protocols developed long before network security was a design consideration. BACnet, Modbus, LonWorks, and KNX are the dominant protocols in building automation — and none were designed with authentication, encryption, or integrity verification as core requirements.
BACnet over IP, in particular, has a significant internet exposure problem. Devices using BACnet over IP are frequently internet-accessible — discoverable through tools used by security researchers and attackers alike — and the protocol itself provides no mechanism to authenticate commands or verify that communications have not been tampered with.
An attacker with network access to a BMS segment using these protocols can read sensor data, issue control commands, and manipulate device behavior without any authentication requirement.
How attackers exploit it: Direct exploitation of unauthenticated protocol interfaces, interception and replay of unencrypted command traffic, and manipulation of building system behavior through protocol-level attacks.
Learn more: The Most Common IoT Vulnerabilities and How Attackers Exploit Them
Internet-Exposed Management Interfaces
BMS management platforms — the web interfaces, dashboards, and remote access portals through which facilities teams monitor and control building systems — are frequently accessible directly from the internet.
This exposure may be intentional, to enable remote management by facilities staff or vendor support teams. It may also be unintentional — a consequence of network configuration decisions made without security review. Either way, an internet-exposed BMS management interface represents a direct attack pathway into building control systems.
Tools used by security researchers can identify thousands of exposed BMS interfaces globally — many running outdated software, many accessible with default credentials, and many with no additional authentication controls beyond a basic login page.
How attackers exploit it: Direct access to exposed management interfaces using default or brute-forced credentials, exploitation of web application vulnerabilities in BMS dashboard software, and abuse of vendor remote access portals.
Insecure Third-Party and Vendor Access
BMS vendors and systems integrators routinely require remote access to managed systems for monitoring, diagnostics, and maintenance. This access is often implemented through persistent remote access tools, VPN connections, or vendor-managed portals — and is frequently subject to minimal security controls.
Compromised vendor credentials, insecure remote access mechanisms, or poor access hygiene — such as shared credentials across multiple client sites — can provide attackers with direct access to BMS infrastructure through trusted third-party pathways.
How attackers exploit it: Credential theft targeting BMS vendors and systems integrators, exploitation of poorly secured remote access infrastructure, and abuse of persistent vendor access connections.
Physical Access to Controllers and Network Infrastructure
BMS field devices and controllers are frequently located in physically accessible areas — plant rooms, service corridors, roof spaces, and external enclosures — that may not be subject to the same physical security controls as data centres or server rooms.
An attacker with brief physical access to a BMS controller can connect to exposed debug interfaces, extract firmware or configuration data, connect to internal network segments, or install persistent malware — without any interaction with digital security controls.
Network switches and cabling infrastructure serving BMS environments are similarly often located in unlocked or poorly secured locations — providing physical network access to anyone who can reach them.
How attackers exploit it: Direct hardware access via exposed debug ports, connection to internal network segments via physical access to switches, and installation of persistent implants during brief physical access windows.
