Security Levels in IEC 62443 and How to Achieve Them
The IEC 62443 series sets cybersecurity requirements for industrial automation and control systems (IACS). One of its central concepts is the security level (SL), which defines graded levels of protection. This article explains what the security levels mean and how systems and components achieve them.
Contents
What are security levels?
Security levels (SLs) in IEC 62443 are defined levels of protection that apply both to whole systems and to individual components. They range from SL 0, which means no specific requirements, to SL 4, the highest level. Each higher level provides stronger protection against potential threats.
| Level | Definition |
|---|---|
| SL 0 | Defined implicitly: no security requirements or security protection are necessary. |
| SL 1 | Protection against casual or coincidental violation |
| SL 2 | Protection against intentional violation using simple means with low resources, generic skills, and low motivation |
| SL 3 | Protection against intentional violation using sophisticated means with moderate resources, IACS-specific skills, and moderate motivation |
| SL 4 | Protection against intentional violation using sophisticated means with extended resources, IACS-specific skills, and high motivation |
Security levels are defined separately for each of the seven foundational requirements (FRs):
- Identification and authentication control
- Use control
- System integrity
- Data confidentiality
- Restricted data flow
- Timely response to events
- Resource availability
This differentiated view lets you match security measures precisely to the specific requirements and risks of a system.
How do security levels differ for systems and components?
Security levels apply at both system and component level. At system level, as described in IEC 62443-3-3, the standard defines specific system requirements (SRs) for each FR. These SRs consist of base requirements and optional requirement enhancements (REs), which are assigned to the different SLs.
At component level, covered by IEC 62443-4-2, these SRs and REs are translated into component requirements (CRs) and corresponding REs.
IEC 62443-4-2 distinguishes four types of components:
Host devices
These devices run an operating system such as Microsoft Windows or Linux. They can host one or more software applications, data stores, or functions from different vendors. Typical characteristics are file systems, programmable services, no real-time scheduler, and a full human-machine interface (HMI) with keyboard, mouse, and so on.
Network devices
These devices enable or restrict the flow of data between devices but do not interact directly with a control process. They typically have an embedded operating system or firmware, no HMI, and no real-time scheduler, and they are configured through an external interface.
Software applications
These are one or more software programs and their dependencies that are used to interact with the process or with the control system itself. Configuration software is an example. Software applications usually run on host devices or embedded devices.
Embedded devices
These devices use embedded software to monitor, control, or actuate industrial processes directly. Typical characteristics are programming through an external interface, an embedded operating system, and a real-time scheduler. Examples are PLCs, sensors, and safety controllers.
Most CRs and REs apply to all component types, but some requirements apply only to specific component types.
Received a security level requirement?
Many requirements for IEC 62443 SL 2 or SL 3 are not worded clearly. We help manufacturers interpret such requirements, derive the relevant requirements from IEC 62443-3-3 and IEC 62443-4-2, and prepare reliable evidence for customers, audits, or certification.
How do you achieve a security level?
The path to a security level differs for systems and components. At system level, the process starts with zoning according to IEC 62443-3-2. You then set the required SL for each zone and put the system together accordingly. If a component does not reach a required SL, you must plan compensating countermeasures for that component.
For components, the process is somewhat different. First, you determine or define the intended use, working with assumptions where necessary. Next, you determine the risk and the required SL. Finally, you decide which security requirements the component meets itself and which are met through integration into the system.
When you assess components, keep in mind that the component itself does not have to meet every security requirement directly. The requirements fall into two categories: those met by the component itself and those that can be met by integration into the system.
This distinction allows a flexible approach to implementing security and reflects that some security functions work better at system level. When you assess and select components, you should therefore consider both the inherent security capabilities of the component and the options for integrating it into the overall system. This allows a balanced and efficient split of responsibilities between components and the system above them.
Challenges in applying security levels
Applying security levels poses several challenges for companies. One of the biggest is keeping up with a threat situation that keeps changing. Protective measures that are considered sufficient today may no longer be enough tomorrow.
Another problem is the risk of over- or under-fulfilling component requirements through blanket SL assignments. Assigning a blanket security level to a component or product makes little sense and does not reflect the intent of IEC 62443. Security requirements depend heavily on the context of use and on the overall system. A product used in a critical system may need stronger security measures than the same product in a less sensitive environment.
Comparability also makes SLs harder to apply. Marketing tends to use blanket SLs for components, which make little sense in practice. The wish to compare products easily through blanket SLs, especially in certification, conflicts with the differentiated approach of IEC 62443. Oversimplification can lead to a wrong assessment of the actual security situation. Even so, parts of the industry are pushing to label components with blanket SLs. Some certification schemes, such as ISASecure, award such blanket SLs to components. This practice does not match the intent of IEC 62443, and you should question it critically.
Recommendations
To apply security levels under IEC 62443 effectively, analyze security requirements in the context of the overall system. Document the security capabilities of your products in detail for each FR. Consider possible compensating countermeasures for requirements that are not met directly. Review and update your security assessments regularly.
The security levels of IEC 62443 give you a structured way to define and achieve cybersecurity objectives in IACS. Using them well requires a differentiated understanding and a careful balance between standardization and flexibility.
The challenges, especially in product certification, show why the approach must be context-based and consider the whole system. Organizations should tailor their security measures to their specific requirements and risks to build strong protection against cyber threats.
Implementing security levels under IEC 62443 is a continuous process. It requires expertise, care, and the ability to adapt, because the threats to industrial automation and control systems keep changing.
Do you need to apply IEC 62443 security levels in practice?
When customers, auditors, or certification bodies set security level requirements, it must be clear whether they refer to a system, a zone, a component, or individual requirements. We help you interpret them, derive specific measures, and prepare reliable evidence.
