IEC 62443 security level explained - guide to implementation

IEC 62443 security level explained - guide to implementation

IEC 62443 security levels describe target, capability and achieved security for industrial automation and control systems. This guide explains SL 0 to SL 4, the seven foundational requirements and how to apply levels at system and component level.

Security levels from SL 0 to SL 4

IEC 62443 uses SL 0 and the numbered levels SL 1 to SL 4. SL 0 applies where no specific security requirements or protection are necessary. SL 1 addresses casual or coincidental violations. SL 2 to SL 4 address intentional violations involving progressively more sophisticated means, resources, IACS-specific skills and motivation.

A higher number is not automatically appropriate. The target level must follow the risk assessment for the system boundary concerned.

Security levels can be considered separately for the seven foundational requirements:

  1. Identification and authentication control
  2. Use control
  3. System integrity
  4. Data confidentiality
  5. Restricted data flow
  6. Timely response to events
  7. Resource availability

A security level may therefore be expressed as a seven-element vector rather than a single number. A scalar level can be useful shorthand, but it can conceal differing needs across the foundational requirements.

Target, capability and achieved levels

IEC 62443 distinguishes between levels that answer different lifecycle questions:

  • SL-T is the target security level determined by risk assessment.
  • SL-C is the capability supported by a system or component against the mapped requirements.
  • SL-A is the achieved security level of the implemented design.

These labels are not interchangeable. A capability level does not by itself demonstrate that a target has been met, and neither establishes the achieved level of an integrated system.

Systems and components

IEC 62443-3-3:2013 maps system requirements and requirement enhancements to control-system capability security levels. It contains 51 distinct base system requirements across the seven foundational requirements; that count excludes requirement enhancements.

IEC 62443-4-2:2019 addresses technical component requirements and component capability security levels. Its component categories are software applications, embedded devices, host devices and network devices.

A component capability level does not replace a system assessment. The deployment context, zone, conduit, integration and any compensating countermeasures remain material. Where a component does not directly provide every needed capability, compensating countermeasures may contribute to meeting the system target only when they are selected and documented in the system design and reflected in the achieved assessment.

Applying security levels at system level

At system level, the work begins by defining the system under consideration and partitioning it into zones and conduits. Risks are assessed and an SL-T is determined for each zone and conduit. The system requirements, design and evidence can then be considered against those targets.

IEC 62443-3-2:2020 provides the system-level risk-assessment context for this work. Its published edition is listed by the IEC as valid, with a successor under development, as accessed on 24 August 2026.

For components, it is important to identify which requirements the component itself supports and which are met only through integration into the wider system. Broad level assignments without deployment context can simplify or misrepresent the actual security position.

Practical application

A practical, evidence-led implementation record can connect:

  1. The system boundary
  2. Zones and conduits
  3. Risk criteria and assessment
  4. The SL-T or security-level vector for each zone and conduit
  5. Selected requirements
  6. Design decisions and compensating countermeasures
  7. Verification evidence and the resulting SL-A assessment

This is a practical workflow rather than a certification guarantee. Target, capability and achieved security levels answer different questions and should not be treated as equivalent labels.

Need help implementing cyber regulation?

Talk to Secuvi →