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:
- Pick one or two representative lines or cells and perform a structured risk and asset assessment.
- Define 2 to 3 zone classes and map these pilot areas to those classes.
- Translate the classes into a minimal, implementable control set that operations can live with.
- Validate that required availability, quality, and regulatory obligations are maintained after changes.
- 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.
