They need both lenses, but neither alone is sufficient. BAS behaves like OT because it controls physical processes, yet it is increasingly managed through IT networks and cloud-connected platforms. That means ownership, segmentation, identity controls and continuity planning must be aligned across both domains rather than delegated to one team.
Why building automation sits between OT and enterprise IT
Building automation systems sit on a boundary that security teams often oversimplify. The control logic, field devices and physical outcomes look like OT, but the management plane increasingly rides on IP networks, directory services, remote administration and cloud dashboards. Treating BAS as only one or the other misses the way a compromise can move from enterprise access into physical building operations, or from a weak plant network back into IT systems.
The right mental model is to classify BAS by function, not by org chart. If the system can change HVAC, access control, lighting, alarms or other physical services, the operational consequence is OT-like. If the same environment is reached through corporate identities, SaaS portals or shared admin paths, it also inherits IT risks such as credential theft, remote access abuse and poor account governance.
That is why segmentation, ownership and recovery planning have to be designed as a combined control problem. A building platform that is “IT-managed” but physically controls facilities still needs safety-aware change control, bounded remote access and tested fallback modes. A platform that is “OT-managed” still needs identity, logging and lifecycle discipline because the administration layer is no longer isolated from enterprise practice.
Where the security boundary actually sits
The practical boundary is usually the controller, gateway or management platform rather than the building itself. Field buses, BACnet, HVAC controllers, access-control panels and similar devices behave like OT assets, while the supervisory layer often depends on Windows hosts, virtual appliances, APIs and cloud integrations. That means the same environment can contain both deterministic process control and ordinary IT administration, sometimes on the same trust path.
Building Management System Security Guide is useful here because it shows why building automation security has to account for BACnet, segmentation, integrator access and the management plane together. Those are not separate problems once remote operators, vendor access and central consoles share the same path to physical outcomes.
The most useful question is not “OT or IT?” but “which parts of the stack are safety- or availability-sensitive, and which parts are enterprise-governed?” The answer usually splits the system into at least three layers: device and field network security, supervisory and integration security, and enterprise identity and remote-access controls. Each layer needs a different operating model, but they have to be coordinated.
What security teams should align before they hand ownership to one side
Building automation fails when ownership is split by convenience instead of control dependency. Facilities may own the process outcome, IT may own the network, and a vendor may hold the keys to maintenance access. If those responsibilities are not explicit, nobody fully owns segmentation, patch timing, emergency access, or recovery after a controller outage.
OT and ICS Identity and Access Guide maps well to BAS because shared accounts, vendor remote access and privilege boundaries are usually where the first serious exposure appears. OT Incident Response Guide also applies, because a building environment needs safety-first containment, logic backups and recovery decisions that cannot be improvised from an IT playbook alone.
If the platform is cloud-connected, treat the identity plane as part of the control system. If the platform can affect occupant safety, energy, physical access or business continuity, treat it as more than standard enterprise IT. The implementation mistake is to apply only one team’s governance model and assume the other side will “just handle” the consequences.
Risk and Threat Considerations
BAS creates risk when enterprise-style connectivity expands the attack surface faster than operational controls mature. Exposed remote access, shared administrator credentials, weak segmentation and unmanaged vendor pathways can let an attacker reach physical functions through what looks like ordinary IT access.
Failure mechanism: An intruder abuses trusted management paths, weak identity controls or a flat network to move from enterprise systems into building controllers, then alters physical services or disrupts availability.
Impact: The result can be loss of environmental control, occupant disruption, denial of physical services, unsafe building conditions, or a broader foothold for lateral movement into adjacent infrastructure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | BAS access paths must enforce role limits across IT and OT layers. |
| IA-5 — Authenticator Management | Shared and remote BAS access depends on credential lifecycle control. | |
| SC-7 — Boundary Protection | Segmentation is central when BAS spans enterprise networks and controllers. | |
| Recommendation — Enforce role-based boundaries for BAS administration, vendor access and operator actions. Rotate and manage BAS credentials, secrets and vendor access with strict lifecycle controls. Segment BAS management, field and enterprise networks with controlled conduits. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | BAS administration relies on disciplined authentication and access control across shared paths. |
| Recommendation — Apply least privilege and strong authentication to BAS operators and vendors. | ||
Practitioner Guidance
What to prioritise: Start by mapping every BAS component to its control impact, management path and recovery dependency. If a device or platform can influence physical conditions, it needs OT-style segmentation and change control even when it is administered through standard IT tooling.
What to verify: Confirm who owns remote access, who approves vendor sessions, where credentials live, and whether fallback operation works if the supervisory layer fails. Also verify that logging and restoration steps are usable during an outage, not only in steady state.
Practitioner takeaway: The safest operating model is dual governance, OT discipline for the physical layer and IT discipline for the management layer, with no ambiguity about who can change what and how it is recovered.
Related resources from NHI Mgmt Group
- Should security teams treat agentic workflows like privileged users or automation?
- How should security teams govern Cursor-like AI coding tools in the enterprise?
- How should security teams treat self-hosted SSO in enterprise environments?
- What breaks when OT security teams treat visibility as a checkbox?