Conduit Security for Building Automation Networks

The Scenario: When "Conduit Security" Comes Up

The phrase usually surfaces in one of three ways. An auditor or insurer asks how traffic between your building automation zones is controlled, and the honest answer is "the core switch routes between the VLANs and there are no rules." An IT security team adopting IEC 62443 hands the BAS integrator a spreadsheet with a "conduit" column and nobody is sure what goes in it. Or a flat BAS network gets segmented into VLANs, and the moment inter-VLAN routing is enabled, the segmentation that looked good on the diagram does nothing — because a VLAN boundary with open routing is not a secured conduit.

One disambiguation first, because the search term is overloaded: this article is about the network and communications conduit from the IEC 62443 standard, not electrical conduit (the physical raceway that protects wiring). Both matter on a building site, but they are unrelated security concepts.

What a Conduit Actually Is

IEC 62443 models an automation network as zones connected by conduits. A zone is a grouping of assets that share the same security requirements. A conduit is a logical grouping of the communication channels that connect two or more zones — the standard treats it as a special kind of zone whose job is to carry and control traffic rather than to host equipment.

The key idea is that a conduit is not just a cable or a VLAN trunk. It includes everything that inspects, filters, or controls the traffic crossing the boundary: firewalls, switch access control lists, protocol-aware gateways, VPN or BACnet/SC endpoints, and the monitoring attached to them. When the standard says a conduit has its own security requirements, it means the enforcement points along that path are what you assess and harden — not the wire.

Conduits are introduced in the risk-assessment part of the series (IEC 62443-3-2), and the security requirements that apply to them sit in the system requirements part (IEC 62443-3-3). Among the seven foundational requirements the standard defines, the one most directly about zones and conduits is Restricted Data Flow — the principle that data should only move where it needs to, and that boundaries should be enforced to stop everything else. A conduit is how Restricted Data Flow is actually implemented on the network.

For the full picture of how zones and conduits fit together — including how to define zones and assign security levels — see IEC 62443 Security Zones for Building Automation. This article focuses on the conduit itself.

What Makes a Conduit Secure

A conduit is secured when four things are true about it. These map onto what an auditor expects to see documented for each boundary:

• Defined endpoints and purpose. The conduit connects two named zones, and you can state why traffic needs to cross at all. A conduit with no clear reason to exist is a conduit to remove, not to secure.
• Restricted protocols and ports. Only the protocols the two zones legitimately exchange are permitted — for example BACnet/IP on UDP 47808 between a supervisor and a field-controller zone, or Modbus TCP on port 502 from a metering zone to a collection point. Everything else is denied by default. A protocol-aware gateway can go further and block specific service requests, such as a write or a firmware download, while still allowing reads.
• Controlled direction. Many BAS data flows are one-directional by intent: trend data leaving the field for a historian, with no return path that could push commands back. Enforcing direction at the conduit — with stateful rules or, for the strictest cases, a unidirectional gateway — closes a path an attacker would otherwise reuse.
• Monitoring and logging. The conduit logs connection attempts and, where the enforcement device can see it, protocol activity. Without this you can enforce a rule but never know it was tested, and you have nothing to replay after an incident.

There is one rule that catches people out: a conduit connecting a higher-security zone to a lower-security one must enforce the requirements of the higher zone. The conduit is the place a compromised device in a weak zone would try to reach a strong one, so it inherits the stronger zone's controls. You cannot let the weaker side set the bar.

How to Secure a Conduit: Step by Step

1. Find every boundary crossing. Walk the network and list each place traffic moves between zones — inter-VLAN routes, BBMD forwarding paths, IP-to-MS/TP routers, the IT/OT handoff, and any remote-access entry point. Each crossing is a candidate conduit. Most sites find more than the diagram shows.
2. Document each conduit before you touch a rule. For every conduit record the two zones it connects, the protocols and ports it carries, the direction of flow, the device that enforces the rules, and how it is monitored. An undocumented conduit is, by definition, an uncontrolled one.
3. Apply default-deny, then open only what the documentation lists. Start from "nothing crosses" and add the specific protocol, port, and address pairs the zones actually need. For the BACnet-specific rules — broadcast handling, the UDP 47808 details, BACnet/SC over TLS — see BACnet Firewall Rules: Ports to Open and Block.
4. Enforce direction where the flow is one-way. If a zone only ever publishes data, the conduit should not accept inbound connections from the other side. Make the rule match the real data flow, not the protocol's theoretical capability.
5. Treat remote access as its own conduit. A technician connecting from outside is a conduit crossing into a BAS zone, and it has security requirements distinct from the zone it enters — identity-bound access, a time-boxed session, protocol restriction, and a full audit trail. This is where most third-party exposure lives. See Secure Remote Access for Cyber-Physical Systems (CPS) for the architecture patterns that hold up.
6. Turn on monitoring and verify the rules bite. Confirm that denied traffic is actually blocked and logged, not silently passing because of a shadowed rule or an open route you forgot. A conduit you never tested is a hope, not a control.

Common Pitfalls

• Defining zones but not conduits. Carving the network into VLANs is the visible half of the model and feels like progress. But if the router between those VLANs has no rules, you have drawn zone boundaries and left every conduit wide open. Segmentation without conduit controls is a diagram, not a defense.
• Treating the VLAN tag as the access control. A VLAN is a segmentation primitive. Anything that can route between VLANs has reached across the boundary. The control has to live at the conduit — the firewall or ACL on that path — not in the existence of the VLAN.
• Forgetting the remote-access and vendor conduits. Elevator monitoring, energy analytics, and vendor support links all cross into the BAS from outside. A vendor appliance sitting on the same VLAN as your supervisory controllers is an undocumented conduit with no controls — and it is exactly the path third-party access incidents follow.
• Letting the weaker zone set the rules. When a conduit joins zones of different security levels, the lower one cannot define what crosses. The conduit must enforce the higher zone's requirements, or the weak zone becomes a staging point for reaching the strong one.
• Documenting once and never again. Conduits drift. A new integration, a new controller, a temporary troubleshooting route that became permanent — each adds or widens a conduit. If the documentation was accurate two years ago and nobody has revisited it, the live network and the model no longer match.

When to Escalate

Bring in dedicated OT security help — internal or an outside firm — when any of these are true:

• An auditor, insurer, or regulator is asking for documented conduit controls and you cannot produce them.
• You are pursuing formal IEC 62443 conformance rather than just borrowing its model; the risk-assessment and security-level work is a structured exercise best done with someone who has run it before.
• The team responsible for the BAS network does not have BACnet, Modbus, or Niagara experience — generic IT firewall tooling will model these protocols incorrectly and may block legitimate broadcast traffic while missing the flows that matter.
• You are moving from a single building to a portfolio, and conduit rules written by hand per site will not stay consistent as the network grows.

Source Attribution

The guidance in this entry draws on the following publicly available sources:

• ISA — ISA/IEC 62443 Series of Standards — International Society of Automation. The normative reference for the zone-and-conduit model, the foundational requirements, and security levels.
• ISAGCA — Quick Start Guide to ISA/IEC 62443 — ISA Global Cybersecurity Alliance. Plain-language overview of zones, conduits, and the foundational requirements.
• NIST SP 800-82 — Guide to Operational Technology (OT) Security — National Institute of Standards and Technology. Network segmentation and boundary-protection guidance for OT environments.
• CISA — Industrial Control Systems guidance — U.S. Cybersecurity and Infrastructure Security Agency advisories on segmentation and remote access to control systems.
• ASHRAE Standard 135 (BACnet) — The normative reference for BACnet/IP and BACnet/SC behavior, including the secure-connect transport that lets a conduit carry BACnet over TLS.

Additional patterns and field guidance from SiteConduit's work with building owners and integrators.