Do all systems need to aim for SL 3 or SL 4?

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.