In 2013, attackers stole 40 million credit card numbers and 70 million personal records from Target Corporation. The entry point was not a zero-day exploit or a brute-force attack on a payment server. It was a set of network credentials belonging to an HVAC contractor.
Fazio Mechanical Services, a refrigeration and HVAC company, had credentials for Target's network for electronic billing and project management. Attackers compromised Fazio through a phishing email, pivoted through the HVAC contractor's access, and moved laterally across Target's network to reach payment card systems. The total cost: $202 million, including an $18.5 million multistate settlement.
That was over a decade ago. The lesson should have been clear: building automation systems do not belong on the same network as corporate IT assets.
It was not learned.
In September 2023, Johnson Controls International — the world's largest building automation vendor — was hit by a ransomware attack that exfiltrated over 27 terabytes of data, including building floor plans, industrial control system designs, and security details for U.S. federal agency buildings. The attackers demanded $51 million. Johnson Controls spent $27 million on remediation. The stolen data included the kind of architectural and control system information that makes future physical security breaches significantly easier.
These are not isolated incidents. Claroty's Team82 research group analyzed nearly 500,000 building management system devices across more than 500 organizations. Their findings: 75% of organizations have BMS devices affected by known exploited vulnerabilities. Sixty-nine percent have devices with vulnerabilities previously used in ransomware attacks. And 51% have BMS devices that are both linked to ransomware vulnerabilities and insecurely connected to the internet.
If your BAS devices sit on your corporate network today, you are one compromised controller away from a breach that has nothing to do with building automation.
What the frameworks say
This is not a matter of opinion or risk appetite. Every major cybersecurity framework that addresses operational technology is explicit: IT and OT networks must be separate.
NIST SP 800-82 Rev. 3
The National Institute of Standards and Technology's Guide to Operational Technology Security requires separating enterprise IT from OT networks. It mandates Industrial Demilitarized Zones (IDMZs) between the two environments, with controlled communication pathways that minimize lateral threat movement. This is not a recommendation buried in an appendix. It is a core architectural requirement.
IEC 62443
The international standard for industrial automation security defines a Zone and Conduit model: group assets by risk profile, place them in distinct security zones, and manage all communication between zones through controlled conduits. BAS controllers, HVAC systems, and lighting panels belong in their own security zone — not sharing network infrastructure with email servers, financial databases, and employee workstations.
ASHRAE BACnet guidance
ASHRAE's managed BACnet guidance includes an entire chapter — Chapter 14 — dedicated to network segmentation for building automation systems. The BACnet Secure Connect specification goes further, adopting a zero-trust posture: there is no "safe inside." Even traffic from peer devices on the same network should be treated as potentially hostile.
Cyber insurance requirements
In 2026, cyber insurance carriers are asking specifically whether OT networks are separated from IT networks during underwriting and renewal. Network segmentation is now part of the mandatory control stack that insurers evaluate. Missing it risks policy denial or significant premium increases. And carriers expect documentation — network diagrams, policy configurations, access logs — not just checkbox answers on a questionnaire.
The bottom line: NIST, IEC, ASHRAE, and your insurance carrier all agree. If your BAS is on your corporate network, you are out of alignment with every major framework and potentially uninsurable for the risk you are carrying.
Why enterprise IT gear is the wrong tool for OT
When IT managers are asked to build a separate OT network, they default to what they know: enterprise-grade switches, routers, and firewalls from the vendors they already work with. On the surface, this makes sense. They have existing vendor relationships, their team already knows the management interfaces, and procurement has pre-negotiated pricing.
The problem is not the quality of enterprise IT gear. It is excellent for enterprise IT networks. The problem is that it is dramatically overengineered and overpriced for what OT networks actually need.
The licensing trap
Enterprise network equipment now runs on subscription-based software licensing models. A typical managed switch requires a software subscription of $300 to $1,500 per device per year, depending on the feature tier. Annual support contracts add another 10–20% of the device's list price every year. These are not optional — they are mandatory at the time of purchase, and they repeat every renewal cycle.
For context: a real-world deployment of 200 enterprise switches with three-year software licensing and support totals $2.6 million — roughly $13,000 per switch. With the advanced feature tier, that rises to $3.3 million. Those numbers come from published pricing, not worst-case estimates.
Scale that down to a 10-site OT deployment. Even at modest per-device costs, you are looking at $50,000 to $150,000 or more in licensing fees alone over five years — for features your OT network will never use.
Features OT networks do not need
Enterprise networking gear comes loaded with capabilities designed for corporate IT environments: SD-WAN orchestration, Network Access Control with 802.1X RADIUS authentication, wireless controllers, application-aware traffic shaping, and cloud-managed dashboards with per-device licensing. These features drive the licensing costs, the management complexity, and the support contract requirements.
An OT network at a building site needs none of that. It needs encrypted tunneling for site-to-cloud connectivity. VLAN segmentation to isolate BAS protocols from other traffic. Firewall rules to restrict which protocols and ports are accessible. Static routing with simple, deterministic network paths. A hardware watchdog for unmanned site reliability. Low power consumption to fit inside a BAS panel or telecom closet.
Purpose-built OT networking equipment delivers exactly these capabilities at a fraction of the cost, with no annual licensing fees. A CPE device designed for OT environments handles encrypted tunneling, VLAN segmentation, and protocol-level firewalling without requiring a software subscription or annual support contract to maintain basic functionality.
This is not about cheap versus expensive. It is about right-sized versus overengineered. Enterprise IT gear is the right tool for enterprise IT networks. It is the wrong tool for a network that needs a VPN tunnel, a VLAN, and a firewall rule.
Why IT teams do not want to own this
Even if you solve the cost problem, there is a deeper structural issue: IT teams are not equipped to manage OT networks, and most of them know it.
Different patch cycles, different worlds
IT infrastructure runs on monthly patch cycles. Servers get security updates on Patch Tuesday. Switches and firewalls receive firmware updates quarterly. Hardware refreshes happen every three to five years. IT teams have built their entire operational rhythm around this cadence.
OT equipment operates on a completely different timeline. A BAS controller might run for 15 to 25 years. Firmware updates happen only during planned maintenance windows — which might occur once or twice a year. Patching a controller at the wrong time can disrupt building comfort, safety systems, or critical operations. There is no "roll it back in five minutes" option when the HVAC serving a data center or hospital wing goes offline.
Alien protocols
BACnet, Modbus, LonWorks, KNX — these protocols do not exist in the IT world. BACnet uses broadcast discovery mechanisms (WHO-IS / I-AM) that do not traverse standard IP routers. Modbus was designed in 1979 and has no built-in authentication or encryption. A single building site might run half a dozen different OT protocols from various vendors and vintages, none of which appear in any IT certification curriculum.
IT teams have no training, no diagnostic tools, and no operational playbooks for these protocols. Asking them to troubleshoot a BACnet broadcast storm is like asking a plumber to diagnose an electrical fault — adjacent trades, completely different expertise.
The expertise gap
An IDC study found that 37.2% of building stakeholders cite the expertise gap between IT and facilities teams as their most pressing challenge. IT security teams think in terms of confidentiality and data protection. OT engineers think in terms of availability and operational continuity. These are fundamentally different security priorities, and trying to force one team to adopt the other's mindset creates friction, blind spots, and misallocated resources.
Making matters worse, 55% of organizations have inaccurate or no asset inventory for their OT devices. You cannot secure what you cannot see, and most IT teams have no visibility into the BAS equipment on their networks.
Liability nobody wants
If IT manages the OT network and the HVAC fails in a server room, a hospital wing, or a pharmaceutical clean room — who is responsible? When an elevator controller loses communication or a fire suppression system goes offline, there is no redundant virtual machine to spin up. These are physical systems with physical consequences, and the liability exposure is real.
Organizations face what security analysts describe as "virtually limitless exposure to liability" when IT and OT responsibilities are unclear. The IT manager who agrees to manage the building automation network is signing up for accountability over systems they were never trained to support.
IT teams are already stretched thin
According to the ISC2 2025 Cybersecurity Workforce Study, 4.8 million cybersecurity jobs are vacant globally, with over 750,000 unfilled roles in the United States alone. Forty-eight percent of cybersecurity professionals report feeling exhausted trying to stay current on threats. Forty-seven percent feel overwhelmed by workload. And 88% of organizations experienced significant cybersecurity consequences due to skills shortages.
Adding OT network management to an already-overloaded IT team is not a staffing decision — it is a risk decision. Every hour an IT engineer spends troubleshooting a BACnet network issue is an hour not spent on the corporate infrastructure they were hired to protect.
The vendor access problem
BAS integrators operate differently from IT vendors. Many integrators share a single set of credentials companywide so that any technician can access any customer system. They use one remote access license with generic logins shared across an entire team of field technicians. Their devices — laptops, tablets, phones — are theft and compromise targets. A stolen laptop with saved credentials means building access. This is one reason VPNs fail for building automation remote access — they were designed for corporate employees, not the way BAS contractors actually work.
This access model directly violates every IT security policy on the books: least privilege, individual accountability, session logging, credential rotation. IT teams know this, and they know that trying to force BAS vendors into proper security practices is often met with resistance.
The conclusion is hard to avoid: asking IT to manage OT is asking them to take on liability for systems they do not understand, using tools that were not designed for the job, governed by protocols they have never seen, while they are already understaffed and overwhelmed. It is the wrong organizational model.
The better model: purpose-built OT networks with managed remote access
The answer to every problem described above is not better IT/OT convergence. It is deliberate IT/OT separation with a purpose-built management layer.
The model works like this: building automation devices live on a physically separate OT network that does not touch corporate IT infrastructure. No shared switches. No shared VLANs. No shared firewall rules. The OT network exists entirely outside the corporate IT perimeter.
At each building site, a pre-configured CPE device connects the local BAS network to a managed cloud platform through an encrypted tunnel. The device ships pre-configured and provisions itself automatically when plugged in — no on-site IT staff required. There are no exposed ports at the building site, no firewall holes for IT to maintain, and no VPN credentials to distribute.
When a technician needs access, they receive a time-limited, protocol-restricted session. They are individually authenticated. Their session is scoped to specific protocols — BACnet, Modbus, or whatever the building site requires. Access expires automatically after the defined window. There is no standing access between maintenance sessions.
Every session generates a complete audit record: who connected, when, which protocols they used, how much data they transferred, and how the session ended. This is not a firewall log that requires a SIEM to parse. It is structured, per-session, per-protocol accounting designed for compliance reporting.
The managed platform provides 24/7 device monitoring — connectivity status, health metrics, alerting — without involving the IT team. Building owners and facilities directors get a dashboard showing the status of every site. IT never needs to touch it.
This model is designed to support the architectural requirements of NIST 800-82, the zone and conduit model of IEC 62443, and the segmentation guidance in ASHRAE's managed BACnet standards. It provides the documentation and audit trail that cyber insurance carriers now require. And it achieves all of this without adding a single device, a single firewall rule, or a single support ticket to the IT team's workload.
For a deeper look at how protocol-level controls work for BACnet remote access specifically, including Layer 2 connectivity, protocol firewalling, and bandwidth limiting, we cover the technical details in a separate guide.
What this looks like in practice
Consider a commercial real estate firm managing a portfolio of 50 buildings across multiple cities. Each building has BAS equipment from various vendors — different controllers, different protocols, different vintages. Multiple integrator firms provide ongoing maintenance.
Today: BAS devices sit on corporate VLANs at each building. Integrators have persistent VPN tunnels punching through the corporate firewall. Multiple vendor credentials are stored in shared spreadsheets. There is no session logging. IT fields tickets about "the BACnet thing not working" that they cannot diagnose. Every integrator connection is an unaudited, unrestricted path into the corporate network.
After separation: Each building has a dedicated OT network with a CPE device connecting it to a central management platform. Integrators access their assigned buildings through time-limited, protocol-restricted sessions with individual authentication. The facilities team sees every session in real time. IT never sees a BAS-related ticket again. Compliance documentation generates automatically. The corporate network has zero OT traffic on it.
The result: a dramatically reduced attack surface, lower networking costs (no enterprise licensing on OT infrastructure), compliance documentation on demand, and an IT team that can focus entirely on IT. For a full breakdown of the threats that make this separation urgent, see our guide to BAS cybersecurity threats in 2026. The facilities team gets visibility they never had. The integrators get reliable remote access without fighting IT for firewall changes. And the building owner sleeps better knowing that a compromised BACnet controller cannot become the next $202 million headline.
The question is not whether to separate — it is how fast
If you are an IT manager, CISO, or building owner with BAS devices on your corporate network, the frameworks have spoken. Your insurance carrier is asking. The breach statistics are clear. IT/OT separation is not an aspirational best practice — it is a baseline requirement.
The good news: separating OT from IT does not require a massive infrastructure project. With purpose-built OT networking equipment and a managed remote access platform, you can isolate building automation systems at every site without adding workload to your IT team or deploying enterprise-grade gear that costs ten times what the job requires.
SiteConduit provides the secure remote access and monitoring layer for isolated OT networks. Pre-configured CPE devices, encrypted tunnels, protocol-restricted sessions, full audit trails, and 24/7 device monitoring — purpose-built for building automation.
Have questions about IT/OT separation for your buildings? Check our frequently asked questions, or join the waitlist to get early access.
Sources
- Krebs on Security — Target breach investigation (2014)
- Dark Reading — Johnson Controls ransomware cleanup costs (2024)
- Claroty Team82 — State of CPS Security 2025: Building Management System Exposures
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security
- IEC 62443 — Industrial Automation and Control Systems Security
- ASHRAE — Managed BACnet Guidance, Chapter 14: Network Segmentation
- ASHRAE — BACnet Secure Connect Whitepaper
- Datalink Networks, MIS Solutions, Breach Craft — Cyber Insurance Requirements 2026
- ORM Systems — Cisco License Cost and Renewal Considerations (2026)
- ORM Systems — Cisco SmartNet Pricing and Benefits
- IDC via Optigo Networks — IT/OT Expertise Gap in Building Stakeholders
- ISC2 — 2025 Cybersecurity Workforce Study
- Bitsight — IT Cybersecurity Burnout Statistics
- CISA — Managing Remote Access to OT Networks
- Gartner — Magic Quadrant for Cyber-Physical Systems Protection Platforms (2025)
Hayden Barker
Founder, SiteConduit — Idea Networks Inc.
Hayden has spent over a decade designing and deploying network infrastructure for building automation environments. He built SiteConduit after seeing firsthand how traditional VPNs and remote access tools fail to meet the security and operational needs of BAS integrators and building owners.