Case Study

Breaking Into the Smart Building Management System

> root@bms-assess:~# bacnet-discover --network 10.10.60.0/24 | grep 'Object-Name\|Vendor' | head -20<span class="cursor-blink">_</span>_

Pentester X 3 February 2026 17 min read
penetration-testing building-management bms-security from-the-hacker-desk bacnet smart-building ot-security hvac-security

We turned the heating off. Then we unlocked the doors.

Every modern office building is a computer. Not metaphorically — literally. Behind the plasterboard, above the ceiling tiles, and inside the risers, thousands of sensors, actuators, and controllers form a networked system that manages every environmental and mechanical function: heating, ventilation, air conditioning, lighting, lifts, fire detection, energy metering, water treatment, and — increasingly — physical access control.

This system is the Building Management System — the BMS. It is the building's nervous system. It reads temperatures, adjusts dampers, modulates boilers, dims lights, monitors power consumption, and reports faults. In a modern smart building, the BMS may manage tens of thousands of data points across hundreds of controllers, communicating over protocols that were designed decades before cybersecurity was a consideration.

On this engagement, we assessed a newly constructed Grade A office tower in a major city centre. The building had been designed to BREEAM 'Excellent' sustainability standards, with a fully integrated smart building platform controlling HVAC, lighting, metering, and tenant access systems. The BMS was the most sophisticated operational technology environment we had assessed outside of industrial manufacturing — and it was the least secured.


The Engagement Brief

The client was the building's managing agent — a commercial property management company responsible for the operation and maintenance of the tower on behalf of the freeholder. The building comprised eighteen floors of multi-tenant office space, a ground-floor reception and retail area, and three basement levels of car parking and plant rooms. Occupancy was approximately two thousand people across fourteen tenants.

The BMS had been installed by a specialist building services contractor during construction and was maintained under a facilities management contract. The system comprised a head-end server running the BMS supervisor application, forty-two field controllers distributed across plant rooms and floor risers, and several thousand field devices — temperature sensors, valve actuators, variable speed drives, lighting controllers, energy meters, and access control panels.

The managing agent had recently engaged an IT security consultancy to assess the corporate office network. During that assessment, the consultancy had noted the presence of BMS traffic on the corporate network and recommended a specialist assessment. We were engaged to conduct a BMS security assessment — the first in the building's three-year operational history.


Finding the BMS Network

The building's network architecture was designed with a degree of separation between IT and OT. The BMS had its own VLAN — 10.10.60.0/24 — connected through a managed switch infrastructure that served both the tenant IT networks and the building services. However, the separation was logical rather than physical, and the firewall rules governing access between VLANs were the focus of our first assessment.

BMS Network Discovery — From Corporate VLAN
# From assessment position on building management office VLAN (10.10.10.0/24):

$ nmap -sS -p 47808,80,443,22,502,4911 10.10.60.0/24

10.10.60.1 — Gateway/switch
10.10.60.10 — BMS Head-End Server
Port 80/tcp (HTTP — BMS web interface)
Port 443/tcp (HTTPS — BMS web interface)
Port 47808/tcp (BACnet/IP)
Port 22/tcp (SSH)

10.10.60.20-61 — Field Controllers (42 devices)
Port 47808/tcp (BACnet/IP)
Port 80/tcp (HTTP — controller web interface)

10.10.60.100 — Access Control Head-End
Port 443/tcp (HTTPS — access control management)
Port 4911/tcp (proprietary access control protocol)

# BMS VLAN fully reachable from management office VLAN
# 45 devices responding — head-end, 42 controllers, access control, gateway

The BMS VLAN was fully reachable from the building management office VLAN. The management office — where the facilities team's workstations sat — had unrestricted access to the BMS network. This was intentional: the facilities engineers needed to access the BMS head-end for daily operations. However, the access was not restricted to specific management workstations or authenticated users — any device on the management office VLAN could reach every BMS device.

More concerning, we tested reachability from a tenant VLAN. Each tenant had their own VLAN for their corporate IT. Firewall rules should have prevented tenant VLANs from reaching the BMS network.

Cross-VLAN Reachability — Tenant to BMS
# From tenant VLAN (10.10.20.0/24) — a tenant's corporate network:

$ nmap -sS -p 47808,80 10.10.60.10

10.10.60.10 Port 47808/tcp OPEN
10.10.60.10 Port 80/tcp OPEN

# BMS head-end reachable from TENANT network
# Firewall rule permitting BACnet (47808) from tenant VLANs
# Rule comment: 'BACnet integration — tenant energy dashboards'

The BMS head-end was reachable from tenant VLANs on BACnet port 47808 and HTTP port 80. A firewall rule — with the comment 'BACnet integration — tenant energy dashboards' — permitted this access. The rule had been created to allow tenant energy monitoring displays to read BACnet data points for their floor's electricity and gas consumption. The rule permitted access to the entire BMS head-end, not just the metering data points.

Finding — Tenant Networks Can Reach BMS Infrastructure

A firewall rule intended to permit tenant energy dashboard access to BACnet metering data points permitted unrestricted BACnet and HTTP access from all tenant VLANs to the BMS head-end server. Any compromised tenant workstation could interact with the building's BMS.


BACnet — The Building's Language

BACnet (Building Automation and Control Networks) is the dominant protocol for building management systems. Standardised as ISO 16484-5, it is used by the majority of commercial BMS installations worldwide. BACnet defines how building controllers communicate — sharing temperature readings, setpoint values, schedules, alarm states, and control commands.

Like many OT protocols designed in the 1990s, BACnet was designed for functionality and interoperability, not security. In its standard configuration, BACnet has no authentication and no encryption. Any device that can send a BACnet packet to port 47808 can read any data point, write any setpoint, and issue any command that the controller supports. BACnet does include an optional security extension (BACnet/SC — Secure Connect), but adoption is minimal and it was not implemented in this installation.

BACnet Discovery — Enumerating the Building
$ bacnet-discover --address 10.10.60.0/24 --timeout 5

[*] BACnet devices discovered:

Device 1001 10.10.60.10 BMS-HEAD-END [VENDOR] Supervisor v5.2
Device 2001 10.10.60.20 AHU-B2-01 [VENDOR] DDC Controller
Device 2002 10.10.60.21 AHU-B2-02 [VENDOR] DDC Controller
Device 2003 10.10.60.22 FCU-GF-RECEPTION [VENDOR] DDC Controller
Device 2004 10.10.60.23 FCU-01-NORTH [VENDOR] DDC Controller
...
Device 2042 10.10.60.61 CHR-ROOF-01 [VENDOR] DDC Controller

[*] 43 BACnet devices discovered

# Device naming convention reveals:
# AHU = Air Handling Unit (central HVAC)
# FCU = Fan Coil Unit (floor/zone HVAC)
# CHR = Chiller (cooling plant)
# B2 = Basement Level 2 (plant room)
# GF = Ground Floor (reception)
# 01-NORTH = Floor 1, North zone

Forty-three BACnet devices discovered. The device names revealed the building's mechanical infrastructure in detail: air handling units in the basement plant rooms, fan coil units on every floor (identified by floor and zone), chillers on the roof, and the central supervisor. The naming convention mapped the building's mechanical layout — which plant serves which area, which controllers manage which floors.

We queried the BACnet objects on a representative floor controller to understand the data points available.

BACnet Object Enumeration — Floor Controller
$ bacnet-read --address 10.10.60.23 --device 2004 --object-list

Device 2004: FCU-01-NORTH (Floor 1, North Zone)

Analog Input (AI):
AI-1: Zone_Temp_01N 22.4 °C (current zone temperature)
AI-2: Zone_Humidity_01N 47.2 %RH (current zone humidity)
AI-3: CO2_Level_01N 612 ppm (current CO2 level)
AI-4: Supply_Air_Temp_01N 16.8 °C (supply air temperature)
AI-5: Return_Air_Temp_01N 23.1 °C (return air temperature)

Analog Output (AO):
AO-1: Heating_Valve_01N 0 % (heating valve position)
AO-2: Cooling_Valve_01N 35 % (cooling valve position)
AO-3: Fan_Speed_01N 67 % (fan speed)

Analog Value (AV):
AV-1: Zone_Setpoint_01N 22.0 °C (target temperature)
AV-2: Setpoint_Deadband_01N 1.0 °C (control deadband)
AV-3: Occupied_Setpoint_01N 22.0 °C (occupied hours target)
AV-4: Unoccupied_Setpoint_01N 16.0 °C (unoccupied hours target)

Binary Value (BV):
BV-1: Occupied_Mode_01N ACTIVE (occupied/unoccupied)
BV-2: Override_Active_01N INACTIVE (manual override flag)

Schedule Objects: 2 (weekday schedule, weekend schedule)

# Full read access to all objects — no authentication
# Including WRITABLE setpoints and control values

Complete visibility of the floor's environmental controls. Current temperatures, humidity, CO2 levels, valve positions, fan speeds, and setpoints — all readable without authentication. The setpoints and control values were writable — we could change the target temperature, override the occupied/unoccupied schedule, and modify fan speeds by writing new values to the BACnet objects.


Environmental Manipulation

With the client's explicit approval and the facilities manager present, we demonstrated the ability to modify environmental controls via BACnet.

BACnet Write — Environmental Control Demonstration
# Demonstration 1: Modify zone temperature setpoint
# Current setpoint: 22.0°C — Writing: 28.0°C

$ bacnet-write --address 10.10.60.23 --device 2004 \
--object AV-1 --property present-value --value 28.0

[*] Write confirmed: Zone_Setpoint_01N = 28.0 °C
[*] Controller responded: heating valve opening to 100%
[*] Facilities manager confirmed: radiators activating on Floor 1 North

# Reverted immediately after confirmation:
$ bacnet-write ... --value 22.0
[*] Setpoint restored to 22.0 °C

# Demonstration 2: Force zone to unoccupied mode
# (Reduces heating/cooling, dims lighting, reduces fresh air)

$ bacnet-write --address 10.10.60.23 --device 2004 \
--object BV-1 --property present-value --value INACTIVE

[*] Occupied_Mode_01N = INACTIVE (unoccupied mode forced)
[*] Controller responding: setpoint dropped to 16.0°C,
fresh air damper closing to minimum position,
lighting set to 10% (unoccupied level)

# Reverted immediately. Total demonstration time: 90 seconds.

Two demonstrations in ninety seconds. The first raised the temperature setpoint to 28°C — causing the heating system to activate at full capacity on a floor occupied by a tenant's workforce. The second forced the floor into unoccupied mode — dropping the temperature setpoint to 16°C, closing the fresh air dampers to minimum, and dimming the lighting to ten per cent. Both changes took effect within seconds.

In an occupied office, forcing unoccupied mode would make the space progressively uncomfortable over thirty to sixty minutes as temperature drifted and CO2 levels rose. The occupants would not know why. The facilities team would not receive an alarm — the controller was operating normally in its unoccupied programme. It simply believed the floor was empty.

The operational consequences extend beyond discomfort. Pharmaceutical tenants with temperature-controlled storage, financial services firms with server rooms dependent on building cooling, and medical practices with environmental compliance requirements would all be affected by uncontrolled temperature excursions.


The Head-End Server

The BMS head-end server at 10.10.60.10 ran the central supervisor application — the graphical interface used by the facilities team to monitor and control the entire building. The web interface was accessible on port 80.

BMS Head-End — Web Interface Access
# Web interface — http://10.10.60.10/

Login page: [VENDOR] Building Supervisor v5.2.1

Default credentials tested:
admin / admin — Access denied
admin / [VENDOR]admin — ACCESS GRANTED (full administrator)

# Vendor-specific default password — documented in installation manual
# Unchanged since commissioning (3 years ago)

Supervisor capabilities:
— Real-time monitoring of all 42 controllers and ~4,200 data points
— Setpoint modification for any zone in the building
— Schedule management (occupied/unoccupied times for all floors)
— Alarm management (acknowledge, silence, disable alarms)
— Trend data (12 months of temperature, energy, occupancy history)
— User management (create/modify/delete operator accounts)
— Controller firmware management (upload firmware to field controllers)
— Network configuration (BACnet device addresses, routing tables)

Full administrative access to the building supervisor with a vendor-default password. The interface provided complete control over the building's environmental systems — setpoints for every zone, schedules for every floor, alarm management, trend data, and the ability to upload firmware to field controllers.

The alarm management capability was particularly concerning. An attacker who could silence or disable alarms could manipulate environmental conditions without the facilities team receiving notification. Combined with the ability to modify setpoints, an attacker could create conditions that would not trigger any alarm — because the alarm thresholds themselves could be changed.

The trend data — twelve months of historical temperature, humidity, energy consumption, and occupancy patterns — constituted an intelligence asset. Occupancy trends reveal when floors are empty. Energy patterns reveal operating hours. Temperature histories reveal which zones have persistent issues that might indicate poorly monitored areas.


The Access Control System

The access control head-end at 10.10.60.100 managed the building's card access system — the readers at the main entrance, lift lobbies, tenant suite doors, plant rooms, and car park barriers. It was on the same BMS VLAN as the HVAC controllers.

Access Control System — Assessment
# Access control web interface — https://10.10.60.100/

Login page: [VENDOR] Access Manager Pro v3.8

Default credentials:
admin / admin — ACCESS GRANTED

System summary:
Doors managed: 87
Active cardholders: 2,341
Card readers: 112
Controller panels: 14

Capabilities with admin access:
— View all cardholders (name, company, card number, access zones)
— Grant/revoke access for any cardholder to any zone
— Add new cardholders (create access credentials)
— Unlock any door remotely (immediate pulse or timed hold-open)
— Modify door schedules (auto-unlock times, holiday schedules)
— View access event logs (who accessed where, when)
— Disable individual readers or zones

# admin/admin — default credentials on a system controlling 87 doors

The access control system — managing eighty-seven doors, one hundred and twelve card readers, and 2,341 cardholders — was accessible with admin / admin. From this interface, we could remotely unlock any door in the building, add new access credentials, revoke existing access, view the complete cardholder database (names, companies, card numbers, and access zones), and review the access event log showing who had accessed every door in the building.

The ability to remotely unlock doors transforms a cybersecurity compromise into a physical security compromise. An attacker with access to the access control system could unlock the main entrance at 3 AM, disable the car park barrier, open the server room door, or hold open a fire exit — all from a laptop. The convergence of building automation and physical access control on the same network, protected by the same default credentials, collapses the boundary between cyber and physical attack.

Critical Finding — Access Control System Accessible with Default Credentials

The building's access control system, managing 87 doors and 2,341 cardholders, was accessible with the manufacturer's default admin/admin credentials. Administrative access permits remote door unlocking, cardholder creation, access log review, and zone modification. The access control head-end was on the same VLAN as the BMS and was reachable from tenant networks.


From Tenant Network to Building Control

Step Action Weakness Exploited
01 Reached BMS VLAN from tenant network on BACnet and HTTP ports Firewall rule for energy dashboards permitted broad BMS access
02 Enumerated 43 BACnet devices and ~4,200 data points BACnet protocol — no authentication; all objects readable
03 Modified HVAC setpoints and occupancy modes on occupied floors BACnet write access — no authentication on writable objects
04 Accessed BMS head-end with vendor-default credentials Default password unchanged since commissioning (3 years)
05 Full building supervisor access — setpoints, schedules, alarms, firmware Single default admin account with unrestricted privileges
06 Accessed access control system — 87 doors, 2,341 cardholders admin/admin default credentials; same VLAN as BMS

Smart Buildings, Unexamined Assumptions

Buildings Are OT Environments
A modern office building is an operational technology environment. It has controllers, actuators, sensors, and protocols — BACnet, Modbus, LonWorks, KNX — that are functionally identical to those found in industrial settings. The same assumptions that made industrial OT vulnerable (protocols without authentication, default credentials, flat networks) apply to building OT.
Multi-Tenancy Multiplies Risk
A multi-tenant building shares BMS infrastructure across organisations with different security postures. A compromised tenant workstation can reach the BMS. The weakest tenant's security becomes the building's security. The managing agent controls the BMS, but the tenants control the networks that can reach it.
The Commissioning Gap
BMS installations are commissioned by building services contractors whose expertise is mechanical and electrical engineering, not cybersecurity. Default credentials are set during commissioning and never changed because the handover process does not include a security hardening step. The building is occupied. The BMS works. Nobody asks about the passwords.
Convergence Creates Compound Risk
When HVAC control and physical access control share a network, a single compromise yields both environmental manipulation and physical access bypass. The systems were historically separate — different vendors, different networks, different protocols. Modern smart building platforms converge them onto shared IP infrastructure, creating compound attack paths that neither the HVAC vendor nor the access control vendor anticipated.

Technique Mapping

T0812 — Default Credentials
Access to the BMS head-end and access control system using manufacturer-default credentials unchanged since building commissioning.
T0855 — Unauthorised Command Message
BACnet write commands modifying HVAC setpoints and occupancy modes on occupied floors without authentication.
T0846 — Remote System Discovery
BACnet device discovery enumerating 43 controllers and approximately 4,200 data points across the building.
T0830 — Manipulation of Control
Administrative access to access control system enabling remote door unlock, cardholder creation, and zone modification.
T0878 — Alarm Suppression
BMS supervisor access enabling alarm silencing, threshold modification, and alarm disablement to conceal environmental manipulation.

Recommendations and Hardening

Remediation Roadmap
Phase 1 — Immediate (0–14 days) Cost: Low
✓ Change BMS head-end admin password to strong, unique value
✓ Change access control admin password immediately
✓ Remove tenant VLAN access to BMS VLAN (delete energy dashboard rule)
✓ Implement BACnet API gateway for tenant energy data (read-only proxy)
✓ Restrict BMS head-end web access to management workstations only

Phase 2 — Short Term (14–90 days) Cost: Medium
○ Separate BMS VLAN from access control VLAN (distinct networks)
○ Implement firewall rules: field controllers ↔ head-end only
○ Change default passwords on all 42 field controller web interfaces
○ Implement role-based access on BMS supervisor (operator vs admin)
○ Enable BMS audit logging and forward to building SIEM/log server
○ Enable access control audit logging with alerting on admin actions
○ Implement MFA for BMS and access control administrative access

Phase 3 — Strategic (90 days — ongoing) Cost: High
○ Evaluate BACnet/SC (Secure Connect) for authenticated BACnet comms
○ Deploy OT network monitoring on BMS VLAN (detect anomalous BACnet)
○ Include BMS in annual penetration testing scope
○ Establish BMS security requirements in FM contract and tenant leases
○ Include BMS hardening in commissioning handover process for new builds

The most impactful immediate change is removing tenant VLAN access to the BMS network. The firewall rule that enabled tenant energy dashboards to query BACnet data should be replaced with a dedicated BACnet API gateway — a read-only proxy that exposes only the metering data points to the tenant dashboards, and nothing else. The proxy sits between the tenant VLANs and the BMS VLAN, translating tenant API requests into BACnet reads and returning the values. The tenants never communicate directly with the BMS.

Separating the access control system from the BMS VLAN is essential. HVAC and physical access are different security domains with different consequences of compromise. They should be on different VLANs with independent management interfaces and independent credentials. The convergence of both systems onto a single VLAN with identical default credentials created a compound risk that neither vendor's security model anticipated.

BACnet/SC (Secure Connect) is the long-term protocol-level solution. BACnet/SC adds TLS-based authentication and encryption to BACnet communications, preventing unauthenticated reads and writes. Adoption requires controller firmware that supports SC — a significant investment in a building with forty-two existing controllers — but should be specified as a requirement for any new controller replacements or new-build projects.

Including BMS security in the facilities management contract and tenant leases addresses the governance gap. The FM contract should specify password management, firmware update responsibilities, and security assessment obligations. Tenant leases should specify the network isolation controls that the managing agent will maintain between tenant VLANs and building services infrastructure.


The building worked perfectly. The security was an afterthought.

This building was a showcase. BREEAM Excellent. Smart building platform. Integrated energy monitoring. Automated environmental control. It performed its primary function — keeping two thousand people comfortable, productive, and safe — with precision and efficiency.

But the system that achieved this — the forty-two controllers, the four thousand data points, the access control panels, the head-end server — was protected by the manufacturer's default passwords, communicated over a protocol without authentication, and was reachable from tenant networks through a firewall rule that nobody had reviewed since the building opened.

Buildings are not traditionally considered attack surfaces. They are considered places — offices, not endpoints. But every smart building is an OT environment, running the same class of protocols, with the same class of vulnerabilities, that we assess in factories and utilities. The difference is that factories know they are OT environments. Buildings, frequently, do not.

Until next time — stay sharp, stay curious, and check the password on the BMS. If it was set during commissioning, it has not been changed since.

Legal Disclaimer

This article describes a BMS security assessment conducted under formal engagement with full written authorisation from the building's managing agent. Environmental modifications were demonstrated under controlled conditions with the facilities manager present and were reverted immediately. No tenant systems were accessed. No cardholder data was exfiltrated from the access control system. All identifying details — including the building, its location, tenants, and system vendors — have been altered or omitted to preserve client confidentiality. Unauthorised access to building management systems may constitute offences under the Computer Misuse Act 1990 and may carry health and safety implications. Do not attempt to replicate these techniques without proper authorisation.



If the BMS password has not changed since commissioning, your building is running on trust.

Hedgehog Security conducts BMS and smart building security assessments covering BACnet services, controller authentication, access control integration, network segmentation, and the IT/OT boundary. We understand building services protocols, operational constraints, and the multi-stakeholder governance that makes building security uniquely complex. Your building keeps people comfortable. We make sure it stays under your control.