Airflow & Airwaves: Segmenting HVAC and OT to Keep Buildings Running

Why HVAC and OT Segmentation Matters

This episode of Built, Wired, and Secured focuses on a practical building operations problem that can quickly become a tenant-facing outage: what happens when HVAC and other operational technology systems share network infrastructure with IT or tenant services. The conversation opens with a realistic scenario. A firmware update on a rooftop air handler triggers repeated reboots on the building management controller. Climate controls begin fluctuating across multiple floors, tenant internet drops as a shared switch hits high CPU, and lobby doors stop working because access control depends on the same network. What starts as a controls issue becomes a broader business disruption.

The central message is straightforward: when OT is connected without clear design boundaries, a single fault can spread across multiple services. That is not just an IT inconvenience. It affects occupant comfort, productivity, safety, vendor coordination, and ultimately revenue.

How OT Ends Up on Shared Networks

One of the most useful parts of the episode is the explanation of how these situations happen. The issue is usually not reckless design. It is a combination of convenience, deadlines, and unclear scope. Michael Harrington explains that OT often lands on shared networks through familiar patterns:

• Contractors piggyback on existing tenant or IT switches to avoid running new cabling.
• Owners push for systems to get online quickly to meet move-in schedules.
• Integrators rely on remote access over the corporate internet because it is easier to deploy.
• Vendor scope stops at making the system function, without clearly defining responsibility after handover.

Each shortcut may reduce upfront cost or schedule pressure, but it introduces coupling. That coupling can stay invisible for a long time. The problem only becomes obvious when something fails and multiple groups are suddenly trying to determine ownership while tenants are already impacted.

The Real Trade-Offs: Isolation vs. Managed Connectivity

The discussion does a good job avoiding oversimplified advice. Strict isolation sounds safer, and in many cases it is. Physically separate networks or dedicated switches can limit the blast radius of failures and make root cause analysis easier. But that approach also brings more capital expense and more operational overhead.

Managed connectivity offers another path. VLANs, firewalls, ACLs, and controlled cross-connects can preserve flexibility and reduce cost while still creating meaningful segmentation. The catch is that shared infrastructure only works when it is supported by disciplined operations. Without that discipline, logical segmentation may exist on a diagram but fail in practice.

The decision comes down to three practical factors discussed in the episode:

• Uptime requirements
• Manageability
• Vendor access needs

The higher the operational risk and the greater the impact on occupants, the stronger the case for more deliberate separation.

What Teams Need If They Choose Managed Connectivity

For organizations that do not go with full physical isolation, the episode lays out several non-negotiables. These are not optional add-ons. They are the controls that make segmentation credible:

• Role-based access controls for vendor accounts
• Centralized logging and monitoring across OT and IT
• Documented change control tied to maintenance windows
• Clear escalation paths when incidents occur
• Tested failover and recovery procedures

One of the strongest lines in the conversation is the idea that monitoring proves whether segmentation is working in practice, not just on paper. That is an important operational lens. A network can be technically segmented and still be poorly governed if teams cannot see changes, trace activity, or respond quickly when something drifts.

Architecture Patterns That Reduce Risk

The episode highlights three pragmatic architecture patterns that reduce operational risk without creating unnecessary complexity.

• Logical segmentation with enforced boundaries, using VLANs plus firewall rules and ACLs that explicitly limit east-west traffic.
• Physical separation for critical systems, including separate conduits, separate risers, or dedicated switches for environments where uptime and safety are especially sensitive.
• Clear service demarcations and handover documentation, including labeling, responsibility matrices in the operations and maintenance manual, and accepted test procedures before closeout.

These patterns are useful because they do more than improve security posture. They reduce troubleshooting time, make accountability clearer, and limit the blast radius when a device, update, or vendor action causes trouble.

Why Remote Access Needs More Discipline

Remote vendor access is another area where avoidable problems start. Rather than relying on static VPNs or shared credentials, the recommendation is to use brokered remote access, jump boxes, or vendor portals that provide time-limited, logged sessions. Multifactored authentication and documented approval for each session should be part of the design, not an afterthought.

Just as important, the episode stresses that remote access must be addressed in contracts and handover documents. Teams should define who configures it, who pays for it, and who reviews the logs. That level of clarity prevents the familiar post-incident finger-pointing that often follows untracked changes.

Two Real-World Examples

The episode uses two short examples to make the risks tangible. In one multi-tenant office, the building management system was sitting on the landlord network. A software update overwhelmed a shared switch and took down tenant internet on two floors during a lease renewal period. The remediation was relatively modest but operationally meaningful: a dedicated BMS VLAN, enforced ACLs, a separate management plane for BMS ports, and an updated vendor scope. The result was dramatically faster recovery and fewer disputes.

The second example comes from a regional healthcare campus that invested in separation during renovations by adding separate conduits and a second riser for OT. It cost more upfront, but later allowed operations, IT, and clinical teams to work in parallel during a network refresh without risking critical HVAC stability. The lesson is clear: thoughtful separation can protect uptime and also simplify future projects.

Three Decisions to Make Now

The episode closes with three practical decisions building owners, operators, and project teams can act on immediately:

• Define service demarcation upfront, including ownership of cabling, switches, and access controls in both contracts and the operations manual.
• Require monitored segmentation, whether that means VLANs or physical separation, so isolation is verified through logging and alerting.
• Make remote access accountable with brokered access, MFA, session logging, and periodic audits tied to vendor scope and payments.

The broader takeaway is that pragmatic segmentation is not just a technical design choice. It is an operational strategy that reduces downtime, clarifies ownership, and protects tenant experience. Small architectural changes, paired with disciplined handover, are often far less expensive than repeated emergency fixes after a preventable outage.

HVAC and OT Segmentation Is Not Just an IT Issue

In commercial buildings, network design decisions do not stay confined to the server room. They reach tenant suites, access control systems, maintenance operations, and the everyday experience of everyone inside the property. That is the practical point at the center of this episode of Built, Wired, and Secured, which looks at why segmenting HVAC and other operational technology systems matters so much for uptime, accountability, and business continuity.

The episode begins with a scenario that feels uncomfortably plausible. A firmware update on a rooftop air handler causes repeated reboots on the building management controller. Soon, climate control becomes unstable on multiple floors. Tenant internet drops because a shared switch is overwhelmed. Lobby doors stop working because access control depends on the same network. At that point, the problem is no longer about one subsystem. It has become a visible building-wide disruption.

That kind of cascade is exactly why segmentation deserves attention during planning, procurement, renovation, and vendor handover. When HVAC and OT share infrastructure with IT or tenant services without clear boundaries, a fault in one environment can spread into others. The result is not simply technical inconvenience. It affects occupants, staff productivity, vendor coordination, and in some cases safety.

How Buildings End Up Here

One of the most useful aspects of the conversation is that it treats this as an operational reality rather than a theoretical design failure. OT rarely lands on shared networks because someone intentionally wants more risk. More often, teams are responding to time pressure, budget pressure, or ambiguous scope.

The episode identifies several common pathways. Contractors may piggyback on tenant or IT switches to avoid running new cabling. Owners may push for systems to be connected quickly so move-in dates are not delayed. Integrators may use remote access over the corporate internet because it is the fastest path to support. In many cases, vendor scope ends with making the system work, not with documenting long-term ownership and support boundaries.

These choices can look efficient in the moment. They reduce friction, keep projects moving, and avoid immediate cost. But they also create coupling between systems that were never meant to fail together. That coupling tends to remain invisible until an update, outage, or troubleshooting event exposes it. Then the organization pays in the form of tenant complaints, emergency repairs, slower incident response, and arguments about responsibility.

The Real Decision Is About Risk, Not Preference

The episode avoids pushing a one-size-fits-all answer. Instead, it frames the segmentation question around three practical axes: uptime, manageability, and vendor access.

Strict isolation, such as physically separate networks or dedicated switching, offers strong protection. It limits the blast radius when something goes wrong and often makes root cause analysis faster because fewer variables are involved. But strict isolation has a price. It can increase capital costs, add operational overhead, and require more deliberate planning for remote support and maintenance.

Managed connectivity sits in the middle. Using VLANs, firewall rules, ACLs, and controlled cross-connects can provide meaningful separation while still allowing organizations to share some infrastructure and control costs. That flexibility can be valuable, especially in buildings where multiple systems need to coexist. The risk is that logical segmentation only delivers resilience if it is backed by disciplined operations. Without that, segmentation becomes more of a drawing than a control.

That is why the episode consistently brings the conversation back to accountability. The best design choice depends on how critical the systems are, how much downtime the property can tolerate, and whether the organization is truly prepared to govern a shared environment.

What Managed Connectivity Actually Requires

For teams that choose managed connectivity instead of full physical isolation, the episode is clear about what must be in place. These are not nice-to-haves. They are operating requirements.

• Role-based access controls for vendor accounts so access is limited by function and responsibility.
• Centralized logging and monitoring that can detect anomalies across both OT and IT environments.
• Documented change control that ties vendor activity to approved maintenance windows.
• Clear escalation paths so teams know exactly who engages when an incident crosses boundaries.
• Failover and recovery plans that are tested rather than assumed.

This operational perspective matters. A segmented network is only as strong as the processes around it. If no one is tracking vendor changes, reviewing logs, or validating recovery procedures, the organization is not really controlling risk. It is simply hoping the design holds under pressure.

Architecture Patterns That Work in Practice

The episode outlines three pragmatic patterns that reduce risk without adding unnecessary complexity.

The first is logical segmentation with enforced boundaries. That means VLANs paired with firewall rules and ACLs that explicitly restrict east-west traffic. In multi-tenant properties, that also means keeping tenant services isolated from operational systems rather than letting everything ride the same infrastructure.

The second is physical separation for critical systems. Separate conduits, separate risers, or dedicated switches can make sense when uptime and safety are especially important. The point is not to overspend everywhere. It is to recognize where the operational consequences of shared infrastructure are too high to accept.

The third is service demarcation and handover clarity. Labeling, responsibility matrices, operations and maintenance documentation, and accepted test procedures before closeout all help create a system that people can actually support after the project team leaves. That clarity often matters just as much as the network design itself.

Remote Access Is Often the Hidden Weak Point

Another practical point from the episode is that remote vendor access can quietly undermine otherwise good architecture. Static VPNs and shared credentials create ambiguity and make post-incident analysis harder. By contrast, brokered remote access, jump boxes, or vendor portals with time-limited logged sessions create a clearer control structure.

The recommendation is to require multifactor authentication and formal approval for each session. Just as important, remote access should be addressed in contracts and handover materials. Who configures it? Who pays for it? Who reviews the logs? If those questions are unanswered, the building is likely to discover the gap during an outage, when it is most expensive to resolve.

Why Small Design Changes Can Pay Off Quickly

The two examples in the episode make the value proposition easy to understand. In a multi-tenant office environment, moving the building management system into a dedicated VLAN, enforcing ACLs, separating management ports, and updating vendor scope dramatically improved recovery time and reduced disputes. The change was not a complete rebuild. It was a targeted correction that reduced operational friction.

In a regional healthcare setting, the decision to invest in separate conduits and a second riser for OT during renovations created more upfront cost. But that cost bought future flexibility. When the network was later refreshed, operations, IT, and clinical teams could work in parallel without putting critical HVAC stability at risk. That is an important reminder that good segmentation is not just about avoiding outages today. It can also make future projects safer and easier to execute.

Three Decisions Building Teams Should Make Early

If there is one theme that runs through the entire episode, it is that these decisions should be made early, not after handover. Three actions stand out.

• Define service demarcation up front, including ownership of cabling, switches, and access controls in both contracts and the operations manual.
• Require monitored segmentation so isolation is validated through alerting and logging, whether the design uses VLANs or physical separation.
• Make remote access accountable by requiring brokered access, MFA, session logging, and periodic audits tied to vendor obligations.

Those steps are practical, specific, and achievable. More importantly, they connect technical design choices to business outcomes. Better segmentation reduces downtime, shortens troubleshooting, limits finger-pointing, and protects the tenant experience.

Why This Matters for Owners and Operators

For owners, operators, and anyone responsible for workplace technology, the lesson is simple: segmentation is not just a security discussion. It is a reliability and accountability decision. The cost of getting it wrong shows up in emergency service calls, avoidable outages, slower recovery, and frustrated occupants. The benefit of getting it right is a building environment that is easier to operate, easier to support, and less vulnerable to cascading failures.

That is a strong example of what good technology planning should do. It should not just connect systems. It should define boundaries, support operational clarity, and keep critical environments running when something inevitably changes. For listeners who want to go deeper, this episode offers a solid framework for evaluating architecture choices before they become outage stories. Give the full conversation a listen, then take those three decisions back into your next design review, renovation plan, or vendor handover discussion.