How EN62443 defines security levels for industrial control systems

During a design review for an industrial control system, it is easy to hear a requirement such as “the system must be EN62443 compliant” or “the PLC network needs Security Level 3.” Neither statement is sufficient on its own. A control system may contain operator workstations, controllers, remote-access gateways, safety-related equipment, engineering laptops, and cloud-connected monitoring services, each exposed to different threats and each needing different protection.

EN62443 defines security levels as protection targets against specified attacker capability, not as a universal cybersecurity maturity score. The standard uses Security Levels from SL 0 to SL 4, then applies them to zones, conduits, and seven foundational requirements. For technical evaluators, the central task is to verify whether the selected target level matches the assessed risk and whether the architecture, components, and operating procedures can actually achieve that target.

Security levels are tied to attacker capability

The EN62443 family, commonly aligned with the IEC 62443 industrial automation and control system standards, describes five levels of security. They indicate the degree of protection required against unauthorized access, misuse, disruption, disclosure, or modification within an industrial automation and control system (IACS).

The wording matters. SL 3 does not mean “three times more secure” than SL 1, and SL 4 is not automatically appropriate for a high-value facility. A higher level implies resistance to a more capable threat actor. The required level should follow an assessed consequence and threat scenario, rather than procurement preference or a generic corporate policy statement.

For example, an isolated machine cell with limited operational impact may need basic control of local access and configuration changes. A remotely operated process area connected to multiple business systems may require stronger segmentation, authenticated remote access, security event handling, and more robust protection of controller communications. These are different exposure conditions, even if both environments use similar PLCs or HMIs.

One “system level” can hide important differences

A frequent evaluation error is to assign one security level to an entire plant or production line and stop there. EN62443 instead supports a segmented view of the system. The relevant architecture is divided into zones and conduits.

A zone is a logical or physical grouping of assets with common security requirements. It may include a controller cabinet, a production cell, an operations network, a safety-related subsystem, or an engineering environment. A conduit is the controlled communication path between zones. It can be a firewall-protected network connection, a remote-support channel, a data diode path, or another managed interface.

This distinction becomes practical when a technical team reviews remote vendor access. The production-control zone may have a higher target level than the corporate network, while the remote-access conduit must enforce strict identity verification, authorization, encrypted communication, session controls, and logging. It is not enough to say that both networks are “behind a firewall.” The evaluator needs to identify what traffic crosses the boundary, who initiates it, which accounts are used, how access is approved, and how the connection is terminated.

Segmentation also avoids unnecessary overengineering. An asset in a low-risk monitoring zone does not automatically need the same technical requirements as a controller responsible for a critical process. Conversely, a weak conduit can undermine a well-protected zone. A hardened controller is still exposed when its engineering port is reachable through an uncontrolled shared network.

Target, achieved, and capability levels answer different questions

Security-level discussions become confusing when documentation does not distinguish among the terms used in the EN62443 framework.

• Security Level Target (SL-T) is the protection level required for a zone or conduit after risk assessment. It expresses the intended resistance to defined threat capability.
• Security Level Achieved (SL-A) is the level the implemented system can demonstrate, considering its deployed controls, configuration, integration, and operational use.
• Security Level Capability (SL-C) is associated with the security capability of a component or product. It does not prove that the deployed system achieves the same level.

That last distinction is essential in supplier assessment. A component may claim capabilities suitable for a particular security level, but the final system can still fall short because credentials are shared, unused services remain enabled, network rules are overly broad, patching is unmanaged, or the component is integrated through an insecure legacy protocol.

Likewise, a system-level target is not a product specification. Asking every device to meet the highest stated level can create compatibility problems and cost without addressing the actual attack path. Technical evaluation should ask where a compensating control sits. A legacy device with limited authentication may be acceptable inside a tightly controlled zone when the surrounding architecture restricts access, monitors traffic, and prevents unauthorized engineering actions. Whether that is acceptable depends on the target level, documented risk treatment, and the control’s ability to meet the applicable requirements.

The seven foundational requirements prevent a single-score mindset

EN62443-3-3 structures technical requirements around seven foundational requirements, often abbreviated as FRs. They are not optional categories to mention in a policy document; together, they provide the basis for defining and testing security-level targets.

1. Identification and authentication control (IAC): users, devices, and processes must be identifiable and authenticated where required. Evaluation may cover unique accounts, password handling, certificate use, service accounts, and treatment of local maintenance access.
2. Use control (UC): authenticated users should receive only permitted actions. Roles, privileges, session restrictions, and approval mechanisms are relevant here.
3. System integrity (SI): the system should resist unauthorized modification and detect integrity problems. Secure configuration, malware protection where appropriate, application control, signed updates, and configuration backup practices may contribute.
4. Data confidentiality (DC): sensitive information should be protected from unauthorized disclosure. The need is often strongest for credentials, configuration files, production recipes, remote-access traffic, and proprietary process information.
5. Restricted data flow (RDF): communications should be limited to authorized paths. Zone separation, allow-list firewall rules, protocol filtering, and managed conduits are key evidence.
6. Timely response to events (TRE): the system should detect, report, and respond to cybersecurity events in a timeframe appropriate to operational risk. Logging without review or escalation is not sufficient.
7. Resource availability (RA): the system should maintain required availability under adverse conditions. This can involve resilience against denial-of-service conditions, backup arrangements, redundancy, recovery procedures, and protection against resource exhaustion.

A security level may be expressed as a vector across these foundational requirements rather than a single identical number. A zone could require stronger restricted data flow and availability controls than confidentiality controls, for example. This reflects industrial reality: loss of control or loss of visibility may create a more serious operational consequence than disclosure of routine process data, while another environment may place heavier emphasis on confidentiality.

How to evaluate whether an SL-T is defensible

The starting point is not a product catalogue or a preset network diagram. Under EN62443-3-2, system risk assessment and security design establish the basis for security-level targets. A useful review begins by confirming the boundary of the system under assessment: included assets, external interfaces, operational roles, dependencies, and assumptions must be stated clearly.

Map the operational consequence before selecting controls

Identify what could happen if a zone were manipulated, interrupted, or used as a pivot point. Consider safety implications, environmental consequences, production interruption, equipment damage, product quality, regulatory exposure, and recovery difficulty. Do not assume that all assets in a production area carry equal consequence. A historian, a maintenance workstation, and a controller managing a hazardous process may require different treatment.

Describe plausible attack paths

Threat capability should be considered alongside exposure. Review removable media, temporary engineering connections, remote support, wireless links, shared credentials, unmanaged switches, business-to-control interfaces, and third-party integrations. The question is not whether every conceivable attack can be eliminated. It is whether the intended controls resist the attacker capability associated with the selected security level.

Assign targets to zones and conduits

Once boundaries and attack paths are understood, define the SL-T for each zone and conduit. Document why the target is assigned and which foundational requirements are relevant. A conduit connecting operations technology to enterprise IT often needs a distinct target because it is an exposure boundary, not merely a cable path.

Translate the target into verifiable requirements

EN62443-3-3 provides system security requirements and requirement enhancements that support the foundational requirements at different levels. Evaluation evidence should be concrete: network diagrams with trust boundaries, firewall rule sets, account-management procedures, configuration baselines, remote-access designs, event-handling workflows, backup and restoration records, and test results. A statement that a feature is “supported” is weaker than evidence that it is configured and works within the assessed system.

Where component certification fits—and where it does not

Component-level requirements in EN62443-4-2 help evaluators examine the security capabilities of products such as embedded devices, host devices, network devices, and software applications. Secure communication options, account controls, audit functions, update mechanisms, and hardening capabilities can all be relevant. The secure development lifecycle requirements in EN62443-4-1 address how a supplier develops and maintains products.

These are valuable inputs, but neither replaces system assessment. A technically capable security appliance may be bypassed by an undocumented wireless route. A controller with strong authentication options may still operate with default credentials because downtime constraints prevented commissioning changes. A supplier’s development process does not establish the security level of an installed architecture. Technical evaluators should maintain traceability from product claims to the exact requirements needed by the assigned zone or conduit.

Evidence gaps that usually affect the achieved level

In design packages, the most important gaps are often not missing technology but missing decisions. Shared operator accounts, unrestricted outbound connections, undocumented service ports, unclear ownership of patch approval, and backups that have never been restored can all prevent an organization from credibly claiming that its SL-A meets its SL-T.

Pay particular attention to temporary states: commissioning, emergency remote support, vendor maintenance, replacement of failed equipment, and recovery after a cyber incident. Controls that work only under normal production conditions may not provide the required protection when pressure to restore operations is highest.

EN62443 security levels therefore work best as an engineering discipline. They force a review team to connect risk assumptions, architecture boundaries, technical requirements, product capability, configuration evidence, and operating procedures. The useful outcome is not a label attached to a plant. It is a defensible explanation of what each critical zone and conduit must resist, how the installed controls meet that need, and where residual gaps still require treatment.