RSC Topic: Security levels (IEC 62443)

In IEC 62443, SL-T and SL-C represent different but related concepts in how you plan and implement cybersecurity for industrial control systems.

Core difference

• SL-T (Target Security Level): The security level you need for a specific zone or conduit based on risk assessment and overall system requirements.
• SL-C (Capability Security Level): The security level a specific component or product is technically able to support, as demonstrated by design, testing, and (where applicable) certification.

In practice: SL-T is defined top-down from risk and system context; SL-C is defined bottom-up from what equipment, software, and systems can actually do.

Where they come from in the IEC 62443 series

• SL-T is set during system and risk engineering activities (e.g., IEC 62443-3-2 and -3-3) when you define zones, conduits, and required protections.
• SL-C is established in the product and component context (e.g., IEC 62443-4-1 and -4-2), focusing on individual devices, applications, or systems and what they can demonstrably support.

How SL-T is determined

SL-T is driven by:

• Risk assessment for safety, quality, production continuity, IP protection, and regulatory exposure.
• Zone and conduit definition: which assets are grouped and how they communicate.
• Threat environment: expected adversary capability, motivation, and potential impact.
• Organizational policies and industry norms (for example, typical expectations for safety-critical or GxP-related systems).

SL-T is not a property of a device. It is a requirement placed on a zone or conduit that may consist of many devices, networks, and applications.

How SL-C is determined

SL-C is typically established by:

• Vendor design and documentation for a controller, PLC, gateway, MES, DCS, or network component.
• Testing and evaluation against IEC 62443-4-2 (for components) or related parts of the standard.
• Sometimes third-party evaluations or certificates that show capability up to a particular security level for specific requirement families.

SL-C is a technical capability. It does not guarantee that a deployed system actually achieves that level in your plant. That depends on configuration, integration, and operational discipline.

How SL-T and SL-C interact in real projects

In a realistic industrial deployment, you will see these patterns:

• SL-C >= SL-T: Components can meet or exceed the required target. You may still need correct configuration, hardening, and procedures to actually reach SL-T.
• SL-C < SL-T: The component is not capable of meeting the target on its own. This is common in legacy or vendor-locked systems.

When SL-C is lower than SL-T, you usually have to:

• Add compensating controls (for example, firewalls, one-way gateways, network segmentation, enhanced monitoring).
• Adjust zone boundaries so that lower capability components are isolated and protected by higher capability infrastructure.
• Apply procedural and administrative controls where technical controls are not feasible.
• Document residual risk acceptance when you cannot practically close the gap, especially in highly regulated environments.

Brownfield and regulated environment realities

In brownfield plants with long-lived assets, it is normal for existing controllers, HMIs, or legacy MES to have SL-C values that lag the SL-T you would choose on a clean sheet. Full replacement to close the gap is often not viable due to:

• Validation and qualification burden for safety, quality, and regulatory approval.
• Downtime constraints and production risk when replacing core control or execution systems.
• Integration complexity with MES, ERP, historians, QMS, and vendor-specific tools.
• Traceability and change control requirements that slow major platform changes.

As a result, many programs focus on:

• Using SL-T to prioritize zones and conduits where higher security is most critical.
• Mapping current assets to their SL-C and identifying gaps by requirement family (e.g., identification & authentication, use control, data integrity).
• Designing architectural and procedural compensating controls rather than trying to immediately replace non-compliant components.
• Maintaining traceable documentation of SL-T, SL-C, compensating controls, and residual risks for internal governance and external audits, without implying that this guarantees compliance outcomes.

How to use SL-T and SL-C in your program

For a typical industrial or manufacturing organization, a practical workflow is:

1. Define zones and conduits and perform risk assessment to establish SL-T for each.
2. Inventory components and determine SL-C per component or per group of similar components, using available vendor information and internal testing where needed.
3. Compare SL-T vs SL-C for each zone/conduit and requirement family to identify gaps.
4. Plan mitigations: architecture changes, network controls, system hardening, and procedures to help the overall zone reach its SL-T, even if individual components have limited SL-C.
5. Implement under change control and document assumptions, dependencies, and known limitations as part of your cybersecurity management and quality systems.

IEC 62443 is structured so that SL-T drives what you need, and SL-C describes what you have. Effective programs manage the gap deliberately instead of assuming they will match by default.

No. Not all systems should aim for Security Level (SL) 3 or SL 4. In most regulated industrial environments, trying to push every asset to SL 3/4 is not realistic, not necessary for risk reduction, and often not achievable for legacy equipment.

What SL 3 and SL 4 actually imply

In the IEC 62443 family, higher SLs imply stronger, more comprehensive security controls and tighter assurance around them. In practice:

• SL 1: Protect against casual or coincidental violations (basic hardening).
• SL 2: Protect against intentional misuse with basic resources and low skills.
• SL 3: Protect against attackers with moderate resources, IACS knowledge, and skills.
• SL 4: Protect against highly resourced, sophisticated attackers (e.g., nation-state level).

SL 3/4 require stronger authentication, more granular authorization, deeper monitoring, stricter change control, and tighter network segmentation, as well as confidence (through testing, evidence, and sometimes certification) that controls perform as intended.

Why “everything SL 3 or SL 4” is usually the wrong goal

For most plants, aiming for SL 3 or SL 4 everywhere conflicts with real operational constraints:

• Legacy controls and equipment: Many PLCs, drives, and tools cannot technically meet SL 3/4 requirements (e.g., no modern authentication, encryption, or logging). Replacing them purely for cybersecurity is rarely viable.
• Validation and qualification burden: In regulated environments, changing control systems or adding security components (gateways, agents, monitoring) can trigger requalification, revalidation, and documentation updates.
• Downtime and cutover risk: Upgrading to architectures that fully support SL 3/4 can require extended outages, complex migration steps, and rollback plans, which may not be acceptable for high-utilization or safety-critical assets.
• Integration complexity: Higher SL requirements across OT/IT boundaries expose issues with MES/ERP/QMS integrations, shared accounts, legacy OPC, and flat networks that are expensive and slow to remediate.
• Cost vs. risk reduction: The marginal risk reduction from forcing SL 3/4 for low-impact systems often does not justify the cost, especially where compensating controls can adequately reduce risk.

How to decide what SL to target

In practice, target security levels should be defined by risk and criticality, not by a blanket policy. A typical approach:

1. Segment by zone and conduit
   Use IEC 62443 zoning: group assets into zones with similar function, criticality, and trust, then define conduits between them. You set target SLs at the zone/conduit level, not per individual device.
2. Assess impact and threat
   For each zone, consider safety impact, product quality impact, regulatory exposure, and business continuity if the zone is compromised. Combine that with credible threat scenarios (e.g., ransomware spreading through remote access, insider abuse, third-party vendor connection).
3. Map feasible controls
   Evaluate what controls are technically and operationally possible: authentication, logging, segmentation, allow-listing, system hardening, and monitoring. For legacy or vendor-locked systems, document constraints explicitly.
4. Set a target SL that can be justified and maintained
   Choose an SL that is proportional to the risk and can be implemented, validated, and sustained over the asset lifecycle. This may mean:

• SL 3 near safety-critical or product-critical control systems that are modern enough to support it.
• SL 2 for supporting systems or mixed-legacy zones where SL 3 controls are not technically feasible, but where network and procedural controls still reduce risk.
• SL 1 with strong perimeter and monitoring around truly constrained, legacy islands.

Typical SL patterns in brownfield, regulated plants

In most brownfield environments with long-lived equipment and heavy qualification requirements, a more realistic pattern is:

• Core safety and critical control zones: Target SL 2+ or SL 3 where feasible, with strong segmentation from corporate IT and external networks, strict change control, and detailed logging.
• Manufacturing applications (MES, QMS, historians): Often aim for SL 2 or “SL 2 with some SL 3 controls,” because many commercial products have partial IEC 62443 alignment but still rely on legacy protocols or shared services.
• Legacy islands (older PLCs, test stands, CNCs): Declare constraints, then protect with compensating measures such as locked cabinets, one-way data flows, jump hosts, and restricted remote access, instead of forcing device-level SL 3.
• Enterprise IT systems: Typically do not map directly to IEC 62443 SLs, but their security posture still influences OT risk through interfaces, credentials, and shared infrastructure.

This zoned approach allows higher SL where it matters most, without forcing wholesale replacement of validated equipment or destabilizing running lines.

Regulatory and audit considerations

Regulators and auditors typically expect risk-based justification, not a particular SL number everywhere. You should be able to show:

• How zones and conduits are defined and why.
• How you chose target SLs for each zone, based on risk and constraints.
• What compensating controls you use when you cannot meet a target SL at the device or application level.
• How changes to security controls are managed under configuration/change control, with traceability.

Stating that “everything must be SL 3/4” and then failing to achieve it in practice is usually worse, from an audit perspective, than a documented, defensible SL strategy that reflects real plant constraints.

When to genuinely consider SL 3 or SL 4

You should explicitly consider SL 3 or SL 4 for:

• Safety-critical control systems where compromise could cause serious harm.
• High-value or highly sensitive production (e.g., defense, aerospace, certain pharmaceutical operations) where disruption or data theft has strategic impact.
• Externally connected zones with many third-party connections or remote access paths, where threat exposure is higher.
• New builds or major greenfield expansions where designing for higher SL is easier before validation and integration debt accumulate.

Even in these cases, reaching full SL 4 across a complex mixed-vendor stack is unusual; the focus is often on achieving a pragmatic subset of SL 3/4 controls where they reduce concrete risks.

Key takeaway

Not every system should target SL 3 or SL 4. In regulated, brownfield manufacturing, security levels need to be:

• Set by risk and impact, not by aspiration.
• Assigned at the zone/conduit level, not blindly per device.
• Aligned with what is technically feasible and sustainable given validation, downtime, and integration constraints.

A documented, risk-based mix of SL 1, SL 2, and selective SL 3 controls, with compensating measures for legacy systems, is usually more realistic and defensible than a blanket SL 3/4 mandate.

In practice, a truly legacy PLC is very unlikely to be individually compliant with IEC 62443, because the standard assumes security capabilities that these devices generally do not have. However, it can still be part of an IEC 62443-aligned system if it is appropriately segmented, monitored, and controlled, and if the residual risk is explicitly assessed and accepted.

What IEC 62443 actually applies to

IEC 62443 is a family of standards that covers:

• System-level requirements for industrial automation and control systems (IACS)
• Component-level requirements for products such as PLCs, RTUs, and network devices
• Security lifecycle and processes (for asset owners and integrators)

When people ask whether a PLC is “compliant,” they are usually mixing two ideas:

• Product conformance: The PLC itself implements the relevant technical security requirements for a target security level (e.g., 62443-4-2).
• System compliance/alignment: The overall IACS architecture, including compensating controls, meets the intent of 62443-3-3 for identified zones and conduits.

Legacy PLCs almost always fail the product conformance test if evaluated directly against 62443-4-2. But they can still exist inside a system that is engineered to meet 62443-3-3 objectives as far as reasonably practicable.

Why legacy PLCs usually cannot be directly compliant

Typical limitations of older PLCs include:

• No native user authentication or only a shared password
• No role-based access control or fine-grained authorization
• No encryption for engineering, HMI, or SCADA traffic
• No secure boot, firmware signing, or integrity protection
• No event logging suitable for modern security monitoring
• Vendor no longer providing security patches or firmware updates

Many IEC 62443 technical requirements assume these capabilities are available. If the PLC simply cannot implement them, you cannot truthfully claim that the device by itself meets the relevant component standard.

In regulated environments, there is also the added constraint that changing firmware or replacing hardware triggers validation, requalification, and documentation updates. This often locks in older devices for long periods, even when they are security-weak.

What “compliance” usually looks like in brownfield plants

For most aerospace, pharma, and other regulated plants with long-lived assets, IEC 62443 alignment is achieved at the system level, not by upgrading every PLC to a modern, certifiable platform. Common patterns include:

• Network segmentation and zoning: Placing legacy PLCs in tightly controlled security zones with minimal and well-defined conduits.
• Compensating controls: Using firewalls, data diodes, jump servers, VPNs, and application proxies to enforce authentication, access control, and logging around the PLC.
• Configuration hardening: Disabling unused ports/protocols, read-only configurations where possible, and removing or locking down programming access in production.
• Restricted engineering workflows: Strict procedures for who can connect to the PLC, from where, and under what change control, often with dual control or approvals.
• Monitoring and detection: Network-based intrusion detection, baseline traffic profiles, and alerting for unexpected changes or communications.
• Physical security: Locked panels, controlled access to cabinets, and managed use of removable media to compensate for weak logical security.

Under IEC 62443, this is acceptable only if:

• The risk is formally assessed (e.g., SL-T vs SL-A gap is documented).
• Compensating controls are designed, justified, and validated.
• Residual risk is explicitly accepted by the appropriate risk owner.
• Controls and assumptions are captured in configuration, design, and change records.

When the honest answer is simply “no”

There are situations where even with compensating controls, the correct answer is that the legacy PLC cannot be made acceptably aligned with the intended IEC 62443 security level for its zone:

• If the PLC is directly exposed to routable networks and cannot be adequately isolated without breaking required functionality.
• If there is no practical way to control or authenticate programming access.
• If the asset’s criticality (e.g., safety impact, product quality impact) demands a higher security level than compensating controls can realistically provide.

In these cases, you may need to:

• Lower the target security level for the zone and explicitly document the risk and rationale, or
• Plan a controlled migration to a more secure PLC, with appropriate validation and downtime planning.

In regulated environments, any migration usually involves:

• Change control and impact assessment
• Revalidation or requalification of equipment and processes
• Retesting of critical functions and failure modes
• Traceability updates to design, maintenance, and cybersecurity documentation

These burdens are why many sites choose to live with legacy PLCs under strong compensating controls rather than pursue immediate replacement.

How to approach legacy PLCs under IEC 62443

A pragmatic approach is usually:

1. Inventory and classify
   Identify all legacy PLCs, firmware levels, communication paths, and process criticality. Treat missing information as a risk item.
2. Perform a threat and risk assessment
   Use IEC 62443 risk methodologies to define target security levels for zones and identify where legacy PLCs fall short.
3. Design compensating controls
   Layer network, system, and procedural controls to address the most impactful gaps. Validate that they work and are maintainable with existing staff and tools.
4. Document residual risk and justification
   Capture assumptions, limitations, and risk acceptance decisions in your cybersecurity, quality, and engineering documentation.
5. Plan gradual modernization
   Where risk or obsolescence is unacceptable, plan staged replacements aligned with outages, validation cycles, and capital planning.

Trying to “rip and replace” all legacy PLCs at once rarely succeeds in regulated, long-lifecycle environments, due to downtime constraints, integration complexity, qualification burden, and the risk of introducing new, insufficiently understood failure modes.

Bottom line

Truly legacy PLCs are almost never directly compliant with IEC 62443 as standalone products. In most brownfield, regulated plants, the realistic goal is to:

• Use zoning, compensating controls, and strict procedures to bring the system into reasonable alignment with IEC 62443 expectations.
• Be transparent about gaps, residual risks, and risk acceptance decisions.
• Prioritize and plan replacements where the risk or obsolescence cannot be managed by architecture and process alone.

Any claim of full IEC 62443 compliance for legacy PLCs without this level of analysis, documentation, and control is likely misleading and will not stand up to a rigorous technical or regulatory review.

Asset owners should usually prioritize the IEC 62443 parts that establish governance, risk assessment, and high-level requirements before going deep into detailed technical controls. The exact sequence depends on your current maturity, installed base, and regulatory constraints, but a practical order for most regulated, brownfield environments is:

1. Start with IEC 62443-2-1/62443-2-1 Ed.2 (security program for IACS)

IEC 62443-2-1 defines the requirements for an industrial automation and control systems (IACS) cybersecurity management system. For asset owners this is usually the highest priority because it frames everything else:

• Roles and responsibilities across engineering, IT, OT, and quality
• Policies for access control, remote access, patching, backups, and incident handling
• Lifecycle processes that fit into existing change control, validation, and qualification
• Integration with existing QMS, safety, and configuration management systems

Without this program layer, technical implementations are hard to sustain, difficult to audit, and often conflict with established manufacturing and validation processes.

2. In parallel or next, IEC 62443-3-2 (risk assessment & system design)

IEC 62443-3-2 focuses on risk assessment and the definition of zones and conduits. For asset owners running mixed-vendor and legacy infrastructure, this is usually the next critical step:

• Identify and classify assets in OT/ICS, including legacy PLCs, DCS, SCADA, HMIs, historians, MES interfaces, and OEM skids
• Define security zones and conduits that respect physical, process, and validation constraints
• Evaluate risks in the context of safety, quality, and regulatory impact, not only confidentiality
• Prioritize where additional controls are feasible without unacceptable downtime or revalidation burden

Because most regulated plants cannot easily re-architect entire networks or replace legacy controllers, 3-2 helps you find realistic, high-leverage changes (for example, segmenting OEM skids or hardening remote access) rather than chasing idealized target architectures.

3. Then IEC 62443-3-3 (system security requirements & SLs)

IEC 62443-3-3 defines system-level security requirements and security levels (SLs). Once you have a program (2-1) and risk-based zoning (3-2), 3-3 lets you:

• Map zones and conduits to target security levels that are realistic for your assets and vendors
• Translate high-level policies into concrete system requirements for integrators, OEMs, and internal engineering
• Align procurement specifications and FAT/SAT criteria with consistent, standard-based requirements
• Identify where legacy equipment cannot meet target SLs and must be compensated with procedural or architectural controls

In brownfield environments, you will rarely achieve uniform SLs across all zones. 3-3 helps document the rationale, compensating controls, and residual risk in a structured way, which is valuable for internal governance and external scrutiny.

4. Introduce product-focused parts as you renew or add assets

After the program and system layers are in place, product-level standards become more useful for asset owners, especially in procurement and vendor management:

• IEC 62443-4-1: Secure development lifecycle requirements for IACS products. Useful to evaluate vendor practices and include in contracts, RFQs, and technical agreements.
• IEC 62443-4-2: Technical security requirements for IACS components (controllers, network devices, software). Useful to define minimum capabilities for new purchases and upgrades.

Trying to drive strict 4-1/4-2 conformance on an existing, heterogeneous installed base usually fails or causes significant disruption and revalidation work. These parts are most effective when applied to new projects, major retrofits, or asset refresh cycles.

5. Use other 2.x parts selectively, based on your gaps

Other parts in the 2.x family can be helpful, but usually after 2-1, 3-2, and 3-3 are in motion:

• IEC 62443-2-3 (if available to you): Often referenced for patch and update management processes across mixed IT/OT environments.
• IEC 62443-2-4: Requirements for service providers. Useful if you rely heavily on OEMs, system integrators, and managed service providers for design, maintenance, or remote support.

The practical value of these depends heavily on your outsourcing model and on how much leverage you have over suppliers and integrators.

Tradeoffs and dependencies in regulated, brownfield environments

In aerospace, pharma, medical devices, and similar sectors, aggressive “start with product conformance” or “rip-and-replace” strategies often underperform because:

• Qualification and validation burdens make frequent hardware/software changes expensive and slow.
• Downtime windows are tightly constrained, especially on bottleneck or validated lines.
• Interdependencies between MES, historians, batch systems, PLCs, and QMS are poorly documented and risky to disturb.
• OEM skids and special machines may not support modern security features without major redesign.

Prioritizing 2-1, 3-2, and 3-3 first allows you to improve cybersecurity posture within these constraints, using zoning, network controls, procedural safeguards, and controlled change instead of wholesale system replacement.

How to choose the starting point for your site

The recommended priority (2-1, 3-2, 3-3, then 4-x) is a strong pattern, but you should still confirm it against your local context:

• If you have no consistent OT security governance, start with 2-1 to align policy, roles, and change control with your existing QMS and engineering processes.
• If you already have basic governance but no clear view of assets and zones, 3-2 may be more urgent to support network changes, remote access control, and firewall rules.
• If you are planning a new greenfield line or major control system replacement, bring 3-3 and 4-2 into the project requirements early, but still anchor them in 2-1 and 3-2 so they fit your enterprise practices.

Whichever part you start with, integration with existing change control, validation, and documentation practices is critical. Treat 62443 adoption as an evolution of your operational and quality systems, not a parallel cybersecurity track.

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.

Deciding the security level for a production zone is primarily a risk decision, not a tooling decision. You need to link technical controls back to business, safety, quality, and regulatory impact, then apply an accepted reference model such as IEC 62443. The right level depends on what the zone contains, how it is connected, and how much change and validation the plant can realistically absorb.

1. Start from criticality and impact, not from firewalls

First classify the production zone by what could go wrong if it is compromised. At a minimum, consider:

• Safety impact: Could loss of control or integrity cause injury, environmental release, or equipment damage?
• Product quality impact: Could undetected manipulation affect product conformity, recalls, or airworthiness/field-safety risk?
• Regulatory and contractual impact: Are there data types subject to export controls, customer-imposed cybersecurity controls, or industry schemes (for example, defense, pharmaceuticals, medical devices, aviation)?
• Operational impact: What is the cost of downtime or degraded performance if this zone is unavailable, or needs to be taken offline for incident response?
• Business and IP impact: Does the zone host process recipes, NC programs, or proprietary work instructions whose disclosure or loss would materially harm the business?

Zones with high safety, quality, or regulatory impact almost always require higher security levels than ones where the impact is primarily cost or local rework.

2. Identify assets and data flows within and across the zone

Security level decisions are only as good as your understanding of what is actually in the zone.

• List OT assets: PLCs, CNCs, robots, HMIs, SCADA, historians, test stands, inspection systems.
• List IT assets in or touching the zone: local servers, thin clients, engineering workstations, on-prem gateways, wireless access points.
• Map data flows: MES to machines, machines to quality systems, remote support connections, vendor cloud links, file drops, removable media usage.
• Note trust assumptions: where do you rely on the corporate network, vendor networks, or operator behavior for security?

This mapping shows where an attacker could enter or pivot, and which connections might need a higher level of control (for example, isolated conduits, strict remote access management).

3. Use a reference model such as IEC 62443 zones and conduits

For industrial environments, IEC 62443 is a common starting point for defining zones and target security levels. Even if you do not formally certify, the concepts are useful:

• Zones: Logical groupings of assets with similar security requirements (for example, safety instrumented systems, general production cells, engineering workstations).
• Conduits: Controlled communication paths between zones (for example, firewalled links from production to corporate IT, vendor remote access tunnels).
• Security levels (SLs): Increasing robustness against more capable and motivated adversaries, across foundational requirements such as identification and authentication, use control, data integrity, confidentiality, and availability.

You do not have to implement every clause of IEC 62443 to benefit from the structure. What matters is a consistent, documented method of assigning target SLs to zones based on risk and then tailoring controls accordingly.

4. Define a repeatable risk-based classification for your plant

To avoid one-off debates for every area, define a simple classification scheme and apply it consistently. For example:

• Zone Class A (highest): Direct impact on safety or regulated product quality; often includes safety systems, batch control for regulated products, critical test cells. Requires high integrity, tight change control, minimal external connectivity, and strong monitoring.
• Zone Class B: Core production with quality impact but limited direct safety risk; typical machining and assembly cells. Requires strong access control, network segmentation from office IT, controlled remote access, and basic monitoring.
• Zone Class C: Support or low-impact areas: training rigs, non-production experiments, non-critical utilities. May use lighter controls but still needs basic hygiene (patching strategy, malware protection, configuration management).

Align each class with target capabilities (often informed by IEC 62443 SLs), but keep the classification understandable to operations and engineering, not just cybersecurity specialists.

5. Balance target security level with change and validation realities

In regulated, long-lifecycle plants you cannot simply enforce the theoretical highest level everywhere:

• Legacy and vendor constraints: Some PLCs, CNCs, or test systems cannot support modern agents, frequent patching, or strong authentication without vendor requalification.
• Validation and qualification burden: For GMP, aviation, medical, or defense programs, tightening controls can trigger revalidation of equipment, software, and processes.
• Downtime risk: Aggressive network segmentation or traffic inspection can affect latency or availability, and changing it may require rare maintenance windows.
• Supportability: Controls must be operable by your existing staff. A security level that depends on 24/7 expert tuning and rapid patching may be unrealistic.

Where you cannot reach the ideal target level without excessive disruption, document the gap and consider compensating controls such as stricter procedures, enhanced monitoring, or tighter controls at adjacent zones and conduits.

6. Specify concrete control expectations per security level

Once you have classes or target SLs, define what they mean in practice. For example, for a production zone:

• Access control: Role-based access, unique accounts, central identity where feasible, clear rules for shared operator accounts if still required by equipment design.
• Network segmentation: Separate OT and IT networks, industrial DMZs, whitelisted protocols, restricted internet access from shop-floor equipment.
• Remote access: Brokered, time-bound sessions with multifactor authentication and logging; no persistent vendor tunnels without monitoring.
• Change and configuration management: Documented baselines for PLC programs, CNC part programs, and HMI/SCADA configurations; formal change control aligned with your QMS and validation processes.
• Monitoring and logging: Event collection from key assets, central log retention, and basic alerting on obvious anomalies. For higher levels, OT-aware intrusion detection.
• Malware protection and hardening: Appropriate to the asset type (for example, antivirus or application allowlisting on HMIs and engineering workstations; configuration hardening on controllers).

Connect each control expectation back to the zone class or target SL so audits and internal reviews can see a consistent rationale.

7. Plan for coexistence of multiple security levels

In brownfield plants you will rarely have a single uniform level across production. Expect:

• Mixed maturity: New lines may support higher controls than legacy lines on the same network.
• Constrained upgrades: Some vendor black boxes cannot be hardened without invalidating support.
• Gradual segmentation: You may start by isolating the most critical zones and then iteratively segment others as windows and budgets allow.

Document these differences and ensure higher security zones are not undermined by weak conduits to lower-level areas. Often the highest value comes from strengthening boundaries and administrative controls around a few critical zones rather than attempting a full plant-wide uplift at once.

8. Document rationale, traceability, and review cycle

For regulated environments, the decision about security level is almost as important as the controls themselves.

• Maintain a zone inventory with assigned class or target SL, asset list, and key data flows.
• Record risk assessments showing why a given level was chosen, including known gaps and compensating measures.
• Integrate security changes into change control and validation processes so that firewall changes, remote access solutions, and OT monitoring tools are evaluated like any other plant change.
• Set a review cadence (for example, annually or with major process changes) to revisit zone classification and adjust security levels as impact, connectivity, or threat landscape changes.

This documentation supports internal governance and gives external auditors and customers a clear line of sight from risk to control, without implying any guarantee of compliance or certification.

9. Practical starting approach

If you are starting from a low or uneven baseline:

1. Pick one or two representative lines or cells and perform a structured risk and asset assessment.
2. Define 2 to 3 zone classes and map these pilot areas to those classes.
3. Translate the classes into a minimal, implementable control set that operations can live with.
4. Validate that required availability, quality, and regulatory obligations are maintained after changes.
5. Use lessons learned to scale the approach to other zones gradually.

This iterative method respects brownfield realities, reduces the risk of overdesigning security levels that you cannot maintain, and keeps the focus on demonstrated risk reduction rather than theoretical maximums.