Show Notes
Why HVAC and OT Segmentation Matters
Heating, ventilation, building management, access control, and other operational technology systems are often expected to work quietly in the background. But when they share network infrastructure with tenant services or corporate IT, a routine change can create a much larger outage.
This episode explores a realistic cascade: a firmware update on a rooftop air handler repeatedly reboots a building management controller, climate controls fluctuate on two floors, a shared switch reaches high CPU utilization, tenant internet fails, and lobby doors stop working because access control depends on the same network. What begins as an HVAC issue becomes a tenant-facing operations, safety, and revenue problem.
The central question for every project is simple: what breaks if this system goes down? Answering it early helps owners, operators, IT teams, and vendors make better decisions about network design, procurement, access, and handover.
How OT Ends Up on Shared Networks
Most shared-network problems do not start with bad intentions. They start with practical pressure:
- A contractor needs connectivity quickly and uses an existing IT or tenant switch.
- A building owner needs systems online before a move-in deadline.
- An integrator uses corporate internet connectivity for convenient remote access.
- A vendor scope ends at “make it work,” without documenting who owns the network after handover.
Those choices can reduce initial cost and schedule friction. The problem is the coupling they introduce. When a shared component fails or is overwhelmed, systems that should be independent can affect each other. The result is often tenant complaints, emergency repair costs, slower troubleshooting, and vendor disputes over responsibility.
The Trade-Off: Isolation Versus Managed Connectivity
There is no single architecture that fits every building. The decision generally comes down to uptime, manageability, and vendor access.
Physical isolation uses separate networks, dedicated switches, and sometimes separate pathways. It maximizes isolation, limits the blast radius of failures, and makes root-cause analysis simpler. It also increases capital expense and operational overhead.
Managed connectivity uses logical segmentation, such as VLANs, firewall rules, access-control lists, controlled cross-connections, and separate management paths. This approach can preserve flexibility and reduce infrastructure cost, but it only works when teams maintain disciplined change control, effective monitoring, and a clear service demarcation.
The appropriate choice depends on the criticality of the systems, the occupants they serve, the organization’s risk tolerance, and the clarity of contractual responsibilities.
Operational Controls That Make Segmentation Real
Logical segmentation is not enough on its own. If systems share infrastructure, the operational controls around that design determine whether it will actually protect uptime.
- Role-based access controls for vendor accounts.
- Centralized logging and monitoring across OT and IT systems.
- Alerts for anomalies that could affect either environment.
- A documented change-control process that ties vendor work to maintenance windows.
- Defined escalation paths when something goes wrong.
- Tested failover and recovery procedures.
Monitoring is especially important because it verifies that segmentation works in practice, not merely in a diagram or policy document. Without those controls, segmentation can become theater: a design concept that looks secure but does not provide dependable operational resilience.
Three Practical Architecture Patterns
The episode outlines three patterns that reduce risk without creating unnecessary complexity.
- Logical segmentation with enforced boundaries: Use VLANs, firewall rules, and ACLs to explicitly control east-west traffic. At multi-tenant sites, pair this with tenant isolation so one environment does not unnecessarily affect another.
- Physical separation for critical systems: Use separate conduits, vertical risers, or dedicated switches for life-safety systems, critical-care HVAC, and other high-consequence operational systems.
- Clear service demarcation and handover documentation: Define who owns cabling, switches, access controls, and ongoing support. Put that responsibility matrix in the operations and maintenance manual, and require accepted test procedures before closeout.
Each pattern limits the potential blast radius of a failure and makes troubleshooting more deterministic. Teams can identify which systems are affected, which party owns the relevant component, and what recovery process applies.
Making Vendor Remote Access Accountable
Vendor remote access is a frequent source of operational friction. Static VPN connections and shared credentials may be convenient, but they make accountability difficult. A better model is brokered remote access through jump boxes or vendor portals that provide time-limited, logged sessions.
Remote access should require multifactor authentication and documented approval for each session. It should also be defined during contracting and handover: who configures access, who pays for it, who can authorize it, and who audits the logs. These details reduce finger-pointing when a change is suspected of causing an outage.
Lessons From Two Facility Examples
In one multi-tenant office, the building management system sat on the landlord network. A software update overwhelmed a shared switch and disrupted tenant internet on two floors during a lease-renewal week. The remediation created a dedicated BMS VLAN with enforced ACLs, moved management ports to a separate management plane, and updated the vendor scope. Recovery time dropped dramatically, and disputes ended.
In a regional healthcare campus, renovations included separate conduits and a second OT riser. The investment cost more upfront, but it allowed operations teams to work in parallel with IT and clinical teams during a later network refresh without risking clinical HVAC or critical-environment stability.
Three Decisions to Make Now
- Define service demarcation upfront in contracts and the operations and maintenance manual.
- Require monitored segmentation, whether the design uses VLANs or physical separation.
- Make vendor remote access accountable with brokered access, MFA, session logging, and periodic audits tied to vendor scope and payments.
Pragmatic segmentation, clear contracts, and reliable operational controls reduce downtime, clarify ownership, and help keep occupants productive. Small architectural changes and disciplined handover are often far less expensive than recurring emergency fixes.
HVAC and OT Network Segmentation Is an Operational Resilience Decision
Building systems increasingly depend on network connectivity. HVAC controls, building management systems, access control, and other operational technology may need to communicate with management platforms, vendors, and internal teams. That connectivity can create real operational value, but it can also introduce avoidable dependencies when operational technology shares infrastructure with tenant services or corporate IT.
The risk is not limited to a cybersecurity discussion. It is an uptime, safety, tenant experience, and revenue discussion.
Consider a mid-rise office building on a busy Monday. A firmware update on a rooftop air handler triggers repeated reboots on the building management controller. Climate controls fluctuate across two floors. A shared switch reaches high CPU utilization, and several tenant spaces lose internet. Lobby doors become stuck because access control depends on the same network. Tenants call the front desk while maintenance vendors arrive and begin trying to determine who owns the problem.
This is the kind of cascading failure that practical segmentation is designed to prevent or contain. The issue may begin with one device or one vendor change, but shared infrastructure expands the blast radius. Instead of isolating the failure to the affected operational system, the outage reaches tenant connectivity, physical access, support staff, and building operations.
Start With the Impact of Failure
The most useful question on an HVAC or OT project is: what breaks if this goes down?
That question shifts the conversation away from generic design preferences and toward business impact. If an HVAC controller fails, will occupants lose climate control? If a shared switch becomes overloaded, will tenant networks be affected? If access control relies on the same infrastructure, can a networking issue create a building-entry problem? If an integrator needs remote access, can that access be managed, logged, and revoked without disrupting operations?
Answering these questions before construction, renovation, procurement, or handover gives stakeholders a clearer basis for design decisions. It also exposes where a project may be relying on convenience rather than resilience.
Why Shared OT Networks Happen
Operational technology commonly ends up on shared networks for understandable reasons. A contractor may need connectivity quickly and connect a building management system to an existing IT or tenant switch. An owner may prioritize getting systems online before a move-in deadline. An integrator may use remote access through the corporate internet because it is the easiest way to support a system. A vendor’s scope may end at making the system function, without establishing responsibility for the infrastructure after closeout.
None of these decisions necessarily appears unreasonable in isolation. They can lower upfront cost or reduce schedule friction. The problem is that they create coupling between systems with different users, risks, support models, and consequences of failure.
When that coupling fails, the effect is visible. Tenants lose productivity. Building staff field complaints. Vendors debate scope. Emergency repairs replace planned maintenance. And the organization pays for both the outage and the uncertainty surrounding it.
Choosing Between Physical Isolation and Managed Connectivity
Strict physical isolation can sound like the obvious answer, but every project has real cost and operational constraints. The right approach depends on three practical axes: uptime, manageability, and vendor access.
Physical separation can include dedicated switches, separate conduits, separate vertical risers, and fully independent network paths. For life-safety systems, critical-care HVAC, or other high-consequence systems, this approach can provide strong uptime isolation and simplify root-cause analysis. If one environment experiences a problem, the other is less likely to be affected.
The trade-off is capital and operational overhead. More dedicated infrastructure means more equipment, pathways, documentation, and support responsibilities.
Managed connectivity offers another path. VLANs, firewall rules, access-control lists, controlled cross-connections, and separate management planes can allow systems to share some infrastructure while maintaining enforceable boundaries. This can reduce cost and increase flexibility, but only when the organization has the discipline to operate it properly.
Managed connectivity is not a shortcut around operational rigor. It requires clear service demarcation, controlled change management, reliable monitoring, and accountability for vendor access.
Segmentation Must Be Monitored, Not Assumed
A network diagram can show separate VLANs and firewalls, but the architecture only delivers value when teams can verify that it works in daily operations. That means segmentation needs operational controls.
Vendor accounts should use role-based access controls. Logging and monitoring should provide visibility across both OT and IT, with alerts for anomalies that may affect either environment. Vendor changes should follow a documented process and occur during defined maintenance windows. Escalation paths should be clear before an incident occurs. Failover and recovery procedures should be tested rather than assumed.
These requirements are not administrative extras. They are what make logical segmentation dependable. Without them, a building may have a technically segmented design but no reliable way to detect misconfiguration, investigate a change, or coordinate recovery.
Use Architecture Patterns That Match the Risk
Three practical patterns can reduce risk while keeping projects manageable.
First, use logical segmentation with enforced boundaries. VLANs should be paired with firewall rules and ACLs that explicitly restrict east-west traffic. In multi-tenant environments, tenant isolation should be part of the design so a problem in one environment does not unnecessarily affect another.
Second, use physical separation for critical systems. Separate conduits, risers, and dedicated switches can be appropriate for life-safety, critical-care HVAC, and other systems where downtime has a particularly high consequence. This approach increases upfront investment but can protect operations during future maintenance and network refreshes.
Third, make service demarcation part of the architecture. A responsibility matrix should identify who owns cabling, switches, access controls, remote access, monitoring, and support. That matrix should be included in the operations and maintenance manual, along with accepted test procedures before closeout.
These patterns serve the same business goal: limit the blast radius, shorten recovery time, and remove ambiguity during an incident.
Vendor Remote Access Needs Defined Accountability
Remote access is often where practical network design breaks down. Static VPNs and shared credentials are convenient, but they make it difficult to identify who connected, what they changed, and whether access is still appropriate.
A better approach uses brokered remote access, jump boxes, or vendor portals that provide time-limited and logged sessions. Multifactor authentication should be required, and each session should receive documented approval.
Just as importantly, remote access needs to be addressed in the contract and handover process. Stakeholders should define who configures it, who pays for it, who approves access, and who reviews the logs. Those decisions prevent a suspected vendor change from becoming an unproductive dispute after an outage.
What Real-World Examples Show
In one multi-tenant office, a building management system operated on the landlord network. A software update overwhelmed a shared switch and interrupted tenant internet on two floors during lease-renewal week. The response created a dedicated BMS VLAN with enforced ACLs, moved BMS management ports onto a separate management plane, and updated the vendor scope. Recovery time dropped substantially, and responsibility disputes stopped.
At a regional healthcare campus, renovation work included separate conduits and a second riser for OT. The decision cost more initially, but during a later network refresh, operations could work in parallel with IT and clinical teams without placing clinical HVAC or critical-environment stability at risk. The upfront clarity avoided downtime and scheduling conflicts later.
Three Decisions for Owners and Operators
First, define the service demarcation upfront. Contracts and operations-and-maintenance documentation should state who owns cabling, switching, access controls, and support responsibilities.
Second, require monitored segmentation. Whether the design uses VLANs, firewalls, ACLs, or physical separation, logging and alerting should confirm that the intended isolation is functioning in practice.
Third, make remote access accountable. Use brokered access, multifactor authentication, session logging, and periodic audits connected to vendor scope and payments.
Segmentation does not need to be an all-or-nothing decision. Pragmatic architecture, clear contracts, and disciplined operational controls can reduce outages, clarify ownership, and protect tenant productivity. For decision-makers planning, renovating, procuring, or operating connected building systems, those modest changes are often far less costly than repeated emergency fixes. Listen to the full episode of Built, Wired & Secured for a practical discussion of how to apply these decisions before the next outage exposes the gaps.