How do I decide which assets belong in the same IEC 62443 zone?

IEC 62443 zones group assets that share similar security requirements, risk exposure, and trust assumptions. You do not zone by convenience or physical layout alone. You zone based on where segmentation would materially reduce risk without creating unsustainable cost, complexity, or validation burden.

Start from functions and risk, not network diagrams

Before drawing zones, work from a simple set of questions for each asset or group of assets:

• What function does it perform? (e.g., safety, basic control, historian, engineering, quality inspection, ERP interface)
• What is the impact if compromised? (safety, environmental, product quality, IP loss, regulatory exposure, production loss)
• Who needs to access it and from where? (operators only, engineering, vendors, remote users, corporate IT)
• What is its security/patching profile? (current OS, patch cadence, vendor support, ability to harden)
• What protocols and communication patterns does it use? (deterministic control traffic vs. general-purpose IT traffic)

Assets that answer these questions in broadly similar ways are candidates to share a zone. Assets with clearly different answers are candidates for separate zones.

Core criteria for putting assets in the same zone

In IEC 62443 practice, assets belong in the same zone when:

• They have similar security levels and requirements. You expect to protect them to roughly the same IEC 62443 Security Level (SL) and with comparable controls. Mixing assets that need high assurance with those you cannot realistically harden forces weak compromises.
• They share trust assumptions. You are comfortable assuming that a compromise of one asset implies potential compromise of its peers. If that feels unacceptable, you should not put them in the same zone.
• They support a common operational function. For example, a production line’s PLCs, IO modules, and local HMI that work together in one cell often form a zone. Safety instrumented systems might be separate if their risk profile and requirements differ.
• They have similar connectivity needs. The same set of users, applications, and external networks need access, using similar protocols and directions of traffic.
• You can feasibly implement and maintain similar controls. E.g., you can patch, harden, and monitor them with comparable tooling and change-control effort.

Red flags that assets should be in different zones

You should strongly consider separating assets into different zones when:

• They have very different consequence of compromise. For example, a safety PLC or batch controller governing high-hazard processes versus a non-critical utility monitoring device.
• They require fundamentally different access controls. A vendor-maintained system with routine remote access should not normally be in the same zone as a system that must never be directly reachable from outside the site.
• They differ greatly in hardening potential. Modern, patchable Windows or Linux hosts vs. unpatchable legacy embedded devices. Co-locating can drag the more secure assets down to the weakest assumptions.
• They serve different lifecycle or validation constraints. Validated batch systems subject to strict change control versus test systems that change frequently. Coupling them in one zone can make changes and revalidation harder and riskier.
• They bridge distinct trust domains. For example, an OT data diode or DMZ historian that connects plant networks to corporate IT should not share a zone with the systems it mediates between.

Balancing risk reduction against operational and validation cost

In regulated, long-lifecycle environments you cannot split every asset into its own zone. Each additional zone introduces cost and complexity:

• More enforcement points. Firewalls, industrial switches, or security gateways must be specified, installed, configured, monitored, and managed under change control.
• More integration work. You need to understand and document traffic between zones, often in systems with incomplete vendor documentation or legacy protocols.
• More validation and requalification. Segmenting networks and modifying communication paths can trigger revalidation of manufacturing systems, which is expensive and time-consuming.
• Potential availability risks. Misconfigured segmentation can cause outages. In high-availability plants with limited downtime windows, this risk strongly shapes zoning decisions.

In practice, you decide which assets to group by asking: Does splitting these into separate zones reduce materially important risk enough to justify the cost, complexity, and downtime or validation impact? If the answer is “not really,” they typically remain in the same zone.

Typical zoning patterns in brownfield plants

Given existing constraints, most plants end up with layered but imperfect zoning. Common patterns include:

• Site-wide or building-level OT core zone. Legacy DCS/MES, historians, engineering workstations, and some HMIs may be grouped because they share infrastructure and are costly to re-zone without major redesign.
• Cell or line zones. PLCs, IO, local HMIs, and drives for a specific production line or cell. This can be a workable compromise between risk reduction and rewiring effort.
• Separate safety zones. Safety PLCs and related components, especially where safety functions and SIL/PL requirements differ from basic control.
• Vendor or remote-access zones. Systems that require third-party access, remote diagnostics, or cloud connectivity, typically placed behind DMZs or tightly controlled jump hosts.
• Quality / lab zones. LIMS, test stands, metrology equipment, and lab instruments, often with different data integrity and regulatory concerns than core production controls.

These patterns are shaped as much by cable routes, legacy switches, and downtime constraints as by ideal reference architectures. You often have to accept coarser zoning than theory suggests and then apply compensating controls (hardening, monitoring, strict remote-access processes) within a zone.

Handling legacy and mixed-vendor systems

In brownfield, mixed-vendor environments you will encounter assets that are difficult to classify neatly:

• Legacy controllers with no security features. Often grouped into a dedicated low-trust zone, with strict boundaries to higher-value assets and heavy reliance on perimeter controls.
• “Black box” vendor systems. If you cannot harden or inspect them easily, avoid putting them in the same zone as your most critical or tightly controlled assets.
• Multi-role servers. Systems that host historian, batch, and reporting functions may need to remain in a shared zone initially. Over time, you can refactor functions into better aligned zones as you refresh hardware or upgrade software.

A common pitfall is attempting a complete re-zoning and full replacement of network or control layers in one project. In regulated environments, that typically fails due to qualification burden, downtime risk, and integration complexity. Iterative zoning aligned with natural upgrade windows is usually more realistic.

Practical steps to decide zone membership

A simple, repeatable approach is:

1. Inventory and group by function. Map each asset to a functional group (e.g., Line 1 control, facility utilities, packaging QA, lab testing, ERP integration).
2. Rate impact and criticality. For each group, rate safety, environmental, product-quality, and production-impact consequences of compromise. Use your existing risk or hazard frameworks where possible.
3. Document connectivity. For each group, list which other groups and external networks it must talk to, and with what directionality and protocols.
4. Assess security capability. Note patchability, vendor support, authentication capability, and logging/monitoring options for each group.
5. Propose initial zones. Group assets where impact, connectivity, and security capability are similar, and where internal segmentation would not add much risk reduction.
6. Identify candidates for separation. Look specifically for high-impact or hard-to-harden assets co-located with lower-impact assets. These are candidates for their own zone or for additional compensating controls.
7. Validate against operations and change control. Review with operations, engineering, quality, and IT/OT security to confirm the zoning is implementable without unacceptable downtime or revalidation scope.

Traceability and documentation

For regulated and safety-critical environments, it is important to document:

• The rationale for each zone. Why these assets share a zone, including assumptions about risk, access, and security level.
• Zone boundaries and conduits. Which devices and rules enforce separation, and what traffic is allowed.
• Dependencies on other systems. MES, QMS, ERP, PLM and any cross-zone integrations, to support change impact analysis.
• Change history. How zones have evolved, and how each change was tested, validated, and approved.

This documentation does not guarantee compliance or audit outcomes, but it supports traceability, consistent decision-making, and defensible risk management over the long equipment lifecycle.