IEC 62443 Security Zones for Building Automation

What Is IEC 62443

IEC 62443 is not a single document—it is a family of standards published jointly by the International Society of Automation (ISA) and the International Electrotechnical Commission (IEC). The series is organized into four groups: General (Part 1), Policies and Procedures (Part 2), System (Part 3), and Component (Part 4). Together, these parts cover everything from organizational security programs and risk assessment methodology to technical requirements for individual devices and the systems that integrate them.

Originally developed for manufacturing and process control environments, IEC 62443 has become the de-facto global cybersecurity standard for all operational technology (OT) sectors—including building automation. Major BAS vendors such as Johnson Controls, Siemens, Honeywell, and Schneider Electric now reference IEC 62443 in their product security documentation and certification programs. The ISA Global Cybersecurity Alliance (ISAGCA) has published guidance explicitly recognizing BAS as an IACS domain covered by the standard.

For BAS professionals, the most relevant parts are IEC 62443-3-2 (security risk assessment, zone and conduit definition) and IEC 62443-3-3 (system security requirements and security levels). These two parts provide the framework for segmenting a building's automation network and assigning appropriate security controls to each segment.

Security Levels Explained

IEC 62443 defines four security levels (SL) that describe the intensity of threat a zone must withstand. Security levels are not arbitrary—they correlate directly to the capability of potential adversaries.

A critical distinction: you do not assign one security level to your entire building. You assess each zone independently based on the consequences of compromise. A chiller plant controller in a data center may warrant SL-3 because losing cooling destroys millions of dollars in equipment, while the lighting controller in the same building's lobby might only require SL-1. This risk-proportionate approach is fundamental to IEC 62443 and prevents the two extremes that plague BAS security—either doing nothing or making every system so locked down that technicians cannot perform routine maintenance.

IEC 62443 also distinguishes between three types of security levels: SL-T (target—what the zone needs), SL-C (capability—what the installed system can achieve), and SL-A (achieved—what is actually operational after configuration). The gap between SL-T and SL-A is where most real-world BAS vulnerabilities live: a controller may be capable of encrypted communication (SL-C of 2) but ship with TLS disabled by default (SL-A of 1).

Defining Zones for BAS

A security zone is a logical grouping of BAS assets that share the same security requirements. Zone boundaries do not have to follow physical network boundaries, though in practice they often align with VLANs or subnet boundaries because that makes enforcement easier.

When defining zones for a building automation system, group assets by these criteria:

• Functional role. Devices performing the same function (all AHU controllers, all lighting panels, all metering gateways) tend to share security requirements and communicate heavily with each other.
• Consequence of compromise. What happens if every device in this group is taken offline or manipulated? Group devices with similar consequence severity together.
• Trust level. Devices managed by the same organization, updated on the same schedule, and subject to the same access policies belong together. A third-party vendor's energy monitoring appliance does not belong in the same zone as your primary HVAC controllers.
• Protocol and connectivity. BACnet MS/TP devices behind a single IP-to-MS/TP router naturally form a zone because the router is the only ingress and egress point. BACnet/IP and Modbus TCP devices on separate VLANs are natural zone candidates.

A typical commercial building BAS deployment results in four to seven zones. Trying to create a zone per device is impractical and creates unmanageable conduit complexity. Conversely, putting the entire BAS into one zone defeats the purpose of segmentation.

Conduits Between Zones

A conduit is the controlled communication path between two zones. Every data flow crossing a zone boundary must pass through a defined conduit. The conduit is not just a cable or a VLAN trunk—it includes all the devices and configurations that inspect, filter, or control that traffic: firewalls, access control lists (ACLs), protocol-aware gateways, and monitoring tools.

Conduits have their own security requirements. IEC 62443-3-2 requires you to document what traffic the conduit carries, which zones it connects, the protocols and ports in use, and the security controls applied. For BAS, the most common conduit controls are:

• Firewall rules or switch ACLs restricting traffic to specific protocols and ports (e.g., UDP 47808 for BACnet/IP, TCP 502 for Modbus TCP) between specific IP addresses.
• Protocol-aware filtering that can inspect BACnet or Modbus payloads and block unauthorized service requests such as WriteProperty or device firmware downloads.
• Unidirectional gateways (data diodes) for conduits where data should only flow one direction—for example, trend data flowing from the field controller zone to the historian zone, with no return path that could be used to push commands back to controllers.
• VPN tunnels or BACnet/SC connections for conduits that cross untrusted network segments, such as the path between a remote site's BAS and a centralized management server.
• Logging and monitoring on every conduit to detect anomalous traffic patterns, unauthorized connection attempts, or protocol violations.

A conduit that connects a high-security zone to a low-security zone must enforce the security requirements of the higher zone. This prevents a compromised device in a low-security zone from using the conduit to attack assets in the high-security zone.

Practical BAS Zone Example

The following example illustrates how IEC 62443 zones and conduits apply to a mid-size commercial office building with centralized HVAC, lighting, metering, and access control. This is a representative architecture—your actual zone boundaries will depend on your risk assessment.

Conduit map for this example:

• Conduit A (Zone 1 ↔ Zone 2): BACnet/IP and BACnet MS/TP traffic only. Firewall permits UDP 47808 between supervisory controller IPs and IP-to-MS/TP router IPs. All other traffic denied.
• Conduit B (Zone 2 ↔ Zone 3): BACnet/IP for point data, HTTPS for controller web configuration. Restricted to supervisory controller IPs and the BAS server IP. Logging enabled for all WriteProperty and DeviceCommunicationControl service requests.
• Conduit C (Zone 3 ↔ Zone 4): HTTPS only (TCP 443) for dashboard API calls. No BACnet traffic crosses this boundary—the API gateway translates between BACnet objects and REST endpoints. This conduit is the critical IT/OT boundary.
• Conduit D (Zone 5 ↔ Zone 2): Modbus TCP (port 502) from metering gateways to a dedicated data collection point on a supervisory controller. Read-only—no write commands permitted from Zone 5 into Zone 2.
• Conduit E (Zone 4 ↔ External): Outbound HTTPS for remote access via a secured platform. No inbound connections from the public internet directly to any BAS zone. All remote sessions authenticated and logged.

Common IEC 62443 Mistakes for BAS

• Treating the entire BAS as one flat zone. Many buildings run every BACnet device—from field-level VAV controllers to the head-end server—on a single VLAN with no segmentation. This violates the foundational IEC 62443 principle that assets with different security requirements belong in different zones. A compromised field device on a flat network has direct network access to the server that stores every credential and controls every schedule in the building. At minimum, separate field controllers, supervisory controllers, and the head-end server into distinct zones.
• Assigning security levels without a risk assessment. IEC 62443-3-2 explicitly requires a documented risk assessment before setting target security levels. Picking SL-2 for everything because it "sounds reasonable" skips the analysis of what each zone actually protects and what the consequences of compromise are. A zone protecting chiller plant controls in a pharmaceutical cold-storage facility has fundamentally different risk characteristics than the same controller type in a retail storefront. The risk assessment drives the security level, not the other way around.
• Ignoring conduit documentation. Defining zones is only half the model. Every communication path between zones is a conduit that needs documented security requirements: what protocols are allowed, what direction data flows, what devices enforce the rules, and how the conduit is monitored. BAS integrators routinely define VLANs (zones) but leave the inter-VLAN routing wide open (undocumented conduits with no controls). An undocumented conduit is an uncontrolled conduit.
• Forgetting third-party and vendor remote access. Elevator monitoring systems, energy analytics platforms, and vendor support connections all introduce external trust boundaries into your BAS network. IEC 62443 requires that these be placed in their own zone or sub-zone with conduits that limit their access to only the data and devices they need. Allowing a vendor VPN appliance to sit on the same VLAN as your supervisory controllers gives that vendor—and anyone who compromises their credentials—unrestricted access to your BAS.
• Treating IEC 62443 as a one-time project. The standard requires ongoing security management, not a one-time network segmentation effort. IEC 62443-2-1 mandates a cybersecurity management system (CSMS) with continuous monitoring, periodic reassessment of zone security levels, patch management, incident response procedures, and personnel training. A building that was properly zoned three years ago but has since added new controllers, new integrations, and new remote access paths without updating the zone and conduit documentation has drifted out of alignment with the standard.

Platform Compatibility

IEC 62443 is protocol-agnostic and vendor-agnostic. The zones-and-conduits model applies regardless of whether your BAS uses BACnet/IP, BACnet MS/TP, Modbus TCP, Modbus RTU, LonWorks, KNX, or proprietary protocols. The standard defines what security controls are required, not how to implement them on a specific platform.

Source Attribution

This guide synthesizes IEC 62443 concepts for building automation professionals. The following sources informed its content:

• Dragos — Understanding ISA/IEC 62443: A Guide for OT Security Teams
• Fortinet — IEC 62443 Standard: Enhancing Cybersecurity for Industrial Automation and Control Systems
• ISA — ISA/IEC 62443 Series of Standards
• ISAGCA — Quick Start Guide to ISA/IEC 62443
• ISASecure — IEC 62443 for Building Automation Systems
• Rockwell Automation — IEC 62443: Ultimate OT Security Guide
• ACET Solutions — ISA/IEC 62443: Why Implementation Fails and What OT Leaders Must Do Differently
• Graftholders — IEC 62443 Security Levels Explained