Learn everything about the security levels for systems and components in IEC 62443, from basics to implementation for manufacturers.
Security levels (SL) in IEC 62443 are defined tiers of security that apply to both entire systems and individual components. They range from SL 0, which implies no specific requirements, up to SL 4, the highest security level. Each higher level provides stronger protection against potential threats.
| Level | Definition |
|---|---|
| SL 0 | Security level 0 is implicit and means that no specific security requirements or protections are necessary. |
| SL 1 | Protection against casual or coincidental violation |
| SL 2 | Protection against an intentional violation using simple means and low resources, general skills and low motivation |
| SL 3 | Protection against an intentional violation using sophisticated means and medium resources, IACS-specific skills and medium motivation (IACS = industrial automation and control systems) |
| SL 4 | Protection against an intentional violation using highly sophisticated means and significant resources, IACS-specific skills and high motivation |
The security levels are defined separately for each of the seven Fundamental Requirements (FRs). These FRs include:
- Identification and authentication
- Use control
- System integrity
- Data confidentiality
- Restricted data flow
- Timely response to events
- Resource availability
By treating each FR individually, the standard enables precise tailoring of security measures to the specific needs and risks of a system.
How security levels differ for systems and components
Application of the security levels takes place at both the system and component level. At the system level, as described in IEC 62443-3-3, specific security requirements (Security Requirements, SRs) are defined for each FR. These SRs consist of baseline requirements and optional enhancements (Requirement Enhancements, REs) that are mapped to the different SLs.
On the component level, governed by IEC 62443-4-2, those SRs and REs are translated into component requirements (Component Requirements, CRs) and corresponding REs.
The IEC 62443-4-2 distinguishes four types of components:
Host device
These are devices that use 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 include file systems, programmable services, no real-time scheduler and a full human-machine interface (HMI) with keyboard, mouse, etc.
Network device
These devices enable or restrict data flow between devices but do not interact directly with a control process. They typically have an embedded operating system or firmware, no HMI, no real-time scheduler and are configured via an external interface.
Software application
This category includes one or more software programs and their dependencies that are used to interact with the process or the control system itself. An example is configuration software. Software applications typically run on host devices or embedded devices.
Embedded device
These are devices that use embedded software to directly monitor, control or actuate industrial processes. Typical characteristics include programming via an external interface, embedded operating system and a real-time scheduler. Examples are PLCs, sensors and safety controllers.
While most CRs and REs apply to all component types, there are also requirements specific to certain component categories.
Received a security level requirement?
Many requirements for IEC 62443 SL 2 or SL 3 are not formulated unambiguously. We support manufacturers in classifying such requirements technically, deriving relevant requirements from IEC 62443-3-3 and IEC 62443-4-2, and preparing robust evidence for customers, audits or certifications.
Classify requirement
How to achieve the security levels
Achieving security levels differs for systems and components. At the system level, the process starts with zoning according to IEC 62443-3-2. The required SLs for each zone are then defined and the system is assembled accordingly. If a component does not meet a required SL, compensating countermeasures must be planned for that component.
For components the process is slightly different. First, the intended use must be determined or defined, possibly working with assumptions. Next, the risk and the required SL are determined. Finally, it is specified which security requirements the component itself should meet and which should be met by integration into the system.
When assessing components it is important to understand that not all security requirements must be met directly by the component itself. Requirements can be divided into two categories: those that are met by the component itself (“met by component”) and those that can be met by integration into the system (“met by integration into system”).
This distinction allows a flexible approach to security implementation and recognizes that some security functions can be implemented more effectively at the system level. When evaluating and selecting components it is therefore important to consider both the inherent security capabilities of the component and the possibilities for integration into the overall system. This enables a balanced and efficient distribution of responsibilities between components and the overarching system.
Challenges in applying the security levels
Applying the security levels presents various challenges for organizations. One of the biggest hurdles is continuously adapting to the ever-changing threat landscape. Protections that are sufficient today may no longer be adequate tomorrow.
Another issue is the risk of over- or under-fulfilling component requirements through blanket SL assignments. It is neither sensible nor in line with IEC 62443 to assign a blanket security level to a component or product. Security requirements depend heavily on the context of use and the overall system. A product used in a critical system may require higher security measures than the same product in a less sensitive environment.
Comparability of SLs further complicates application. Marketing tends to use blanket SLs for components that are not meaningful in practice. The desire for easy comparability of products through blanket SLs—especially in the context of certifications—contradicts the differentiated approach of IEC 62443. Oversimplification can lead to a misjudgment of the actual security situation. There are, however, industry efforts to label components with blanket SLs. Some certification schemes, like ISASecure, assign such blanket SLs to components. This practice does not align with the intention of IEC 62443 and should be viewed critically.
Recommendations and conclusion
For effective application of the security levels according to IEC 62443, a holistic approach is recommended that analyzes security requirements in the context of the overall system. Detailed documentation of product security capabilities with respect to the various FRs is essential. Possible compensating countermeasures for requirements not directly met should also be considered. Regular review and updating of security assessments are crucial.
The security levels of IEC 62443 provide a structured approach to defining and achieving cybersecurity goals in IACS. Their effective application requires a differentiated understanding and a careful balance between standardization and flexibility.
The challenges in applying security levels, especially in the area of product certification, highlight the need for a holistic and context-sensitive approach. Organizations must tailor their security measures to their specific requirements and risks in order to build robust protection against cyber threats.
Ultimately, successful implementation of security levels according to IEC 62443 is a continuous process that requires expertise, diligence and adaptability. Only through this comprehensive approach can organizations ensure the security of their industrial automation and control systems in a constantly evolving threat landscape.
Do you need to apply security levels in practice according to IEC 62443?
When customers, auditors or certification bodies set security level requirements, it must be clear whether these refer to a system, a zone, a component or individual requirements. We help classify requirements, derive concrete measures and prepare robust evidence.
Discuss security level
