On a building automation site, "conduit" carries two meanings, and they get confused constantly. The first is physical — the metal or plastic raceway that protects cabling. The second comes from the IEC 62443 zone-and-conduit model: a conduit is a logical grouping of the communication paths between two security zones, with its own defined controls. If you are securing an OT network, the conduit that matters is the second one — every place where traffic crosses from one zone (say, the BAS network) into another (corporate IT, a vendor connection, the internet) is a conduit, and on most sites those crossings have never been inventoried or controlled.
Two things "conduit" means on a site
Search for "conduit" in a building context and you get electrical results — EMT, rigid, flex, fill tables, bend radii. That is the physical conduit: the raceway that carries and protects the wiring on a job site. It is real work, and it has nothing to do with network security.
The other conduit is a security concept. In the IEC 62443 series — the international standard for industrial automation and control system security, formerly ISA-99 — a conduit is the logical channel that connects two zones and carries traffic between them. When a controls contractor says "we need to document the conduits on this site," they almost always mean this second definition: the controlled pathways between groups of systems, not the pipe in the wall.
This article is about the second one, applied to a single building site. If you arrived looking for electrical conduit sizing, this is not it. If you are trying to figure out how traffic crosses between your BAS network and everything else, read on.
What a conduit is in the zone-and-conduit model
IEC 62443 organizes a network into zones and conduits. A zone is a grouping of assets that share the same security requirements — for example, all the field controllers and the supervisor on a BAS network. A conduit is the grouping of communication channels that connect zones, with its own defined security controls. Put plainly: zones are where systems live, conduits are how they talk to each other.
The point of drawing these boundaries is to make every cross-zone path explicit. A zone with no documented conduits is supposed to have no traffic crossing its boundary. The moment traffic does cross — a supervisor reaching a cloud analytics service, a vendor laptop dialing into a JACE, an IT workstation pulling trend data — that path is a conduit, and it needs controls: what protocols are allowed, in which direction, who is authenticated, and what is logged.
On a single site, the typical conduits are the link between the OT/BAS zone and the corporate IT zone, the remote-access path used by integrators and service vendors, and any direct internet egress from controllers or gateways. Each one is a place where a problem in one zone can spread into another, which is exactly why the model insists you name them.
For the security properties a conduit is expected to enforce — and why an undocumented one is a finding in an audit — see our companion entry on conduit security for building automation networks. For the broader zone structure that conduits connect, see IEC 62443 security zones for building automation.
How to inventory the conduits on one site
You cannot control a conduit you have not found. Before any segmentation work, walk the site and build a list of every place traffic crosses a zone boundary. A practical sequence:
- Draw the zones first. Group the systems on the site by who owns them and what they need to protect: the BAS/OT zone, the corporate IT zone, any tenant networks, and any safety or life-safety systems that should stand alone. Keep it coarse at first — you can split zones later.
- Find every link between zones. Walk the network drawings, the switch and firewall configs, and the physical racks. Each connection that leaves one zone and enters another is a candidate conduit. Do not forget wireless bridges, cellular gateways, and serial-to-IP converters — they cross boundaries just like an Ethernet uplink does.
- Record what each conduit carries. For each one, note the protocols and direction. BACnet/IP rides on UDP 47808; Modbus TCP uses TCP 502; a Niagara station talks Fox to Workbench and other stations. Capture what is actually flowing, not what the design document claims — they are often different.
- Mark the remote-access and internet conduits. The path a vendor uses to reach a controller, and any direct egress from a gateway to a cloud service, are the highest-risk conduits on most sites. Flag them. These are the ones that most often turn out to be a flat VPN or an open port-forward.
- Note what controls each conduit has today. For every conduit, write down what is enforcing it: a firewall rule, an ACL, a protocol filter, or nothing. "Nothing" is the most common and most useful answer to surface.
When you are done you have a site-specific map: zones, the conduits between them, what each carries, and what controls it. That map is the input to every later decision about segmentation and access.
What separates a controlled conduit from a wide-open one
A conduit is not secure just because it exists on a diagram. A controlled conduit restricts traffic to only the protocols and directions the two zones actually need — default-deny, with explicit allowances. A wide-open conduit is the opposite: inter-VLAN routing left unrestricted, or a remote-access path that drops a vendor onto the full BAS network instead of the one device they came to service.
NIST SP 800-82, the U.S. guide to operational technology security, makes the same point from the other direction: network segmentation and boundary protection between IT and OT are foundational controls, and the boundary is only as good as the rules enforced on it. A conduit with no enforcement is a documented hole, not a control. The value of naming conduits is that each one becomes a place you can point a rule at — allow BACnet/IP in one direction, deny everything else, log the rest.
Common pitfalls
- Treating the physical and logical conduit as the same thing. They are unrelated. Running new EMT does nothing for your network segmentation, and a tightly controlled logical conduit can run over a shared physical pathway. Keep the two vocabularies separate on the project.
- Counting zones but never the conduits. Teams draw nice zone diagrams and stop there. The security work lives in the conduits — an unlabeled line between two zones on a drawing is an uncontrolled path in reality.
- Forgetting the remote-access conduit. Vendor and integrator access is a conduit into the OT zone, and it is the one most often left as a persistent VPN with standing credentials. Roughly 70% of OT security incidents involve third-party access, so this conduit deserves the most attention, not the least.
- Assuming "air-gapped" means no conduits. Very few BAS networks are truly isolated. A cellular gateway, a cloud trend export, or a temporary contractor laptop is a conduit, even if the design says the network is standalone. Verify by capture, not by assumption.
- Documenting conduits once and never again. A new analytics integration, a replaced gateway, or a fresh vendor connection all add conduits. If the map is not updated when the site changes, it stops reflecting reality within months.
When to bring in help
A small site with one BAS network and one IT uplink is something an integrator or facilities team can map and tighten on their own. Escalate to an OT security specialist when the site has multiple interconnected systems, tenant networks, life-safety integration, or a remote-access arrangement that you cannot fully account for. The same is true if an insurer, auditor, or IEC 62443 / NIST assessment is driving the work — the formal zone-and-conduit documentation and risk-assessment steps (IEC 62443-3-2 covers the risk assessment that partitions a system into zones and conduits) are easier to get right with someone who does them regularly.
However you proceed, the order is the same: name the zones, find the conduits, document what each carries, then control them.
Source attribution
The technical guidance in this entry is informed by the following public sources:
- IEC 62443 series (formerly ISA-99) — Security for industrial automation and control systems. The normative source for the zone-and-conduit model; IEC 62443-3-2 addresses security risk assessment and the partitioning of a system into zones and conduits, and IEC 62443-3-3 covers system security requirements and security levels.
- 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.
- ASHRAE Standard 135 — BACnet—A Data Communication Protocol for Building Automation and Control Networks. Reference for the BACnet/IP transport noted above.
Additional field validation by SiteConduit.
Was this article helpful?
Related Articles
Need to do this remotely? SiteConduit provides secure Layer 2 remote access to BAS networks with protocol-level controls. Join the waitlist.
SiteConduit Technical Team
Idea Networks Inc.
SiteConduit builds managed remote access for building automation. Our knowledge base is maintained by BAS professionals with hands-on experience deploying and troubleshooting BACnet, Niagara, Modbus, and Facility Explorer systems.