Learn everything about the security levels for systems and components in IEC 62443, from fundamentals to implementation for manufacturers.
What are security levels?
Security levels (SLs) in IEC 62443 are defined tiers of security that apply both to entire systems and to individual components. They range from SL 0, which implies no specific requirements, to SL 4, the highest security level. Each higher level offers stronger protection against potential threats.
| Level | Definition |
|---|---|
| SL 0 | Security level 0 is implicitly defined and means that no security requirements or protection are necessary. |
| SL 1 | Protection against casual or accidental breach |
| SL 2 | Protection against an intentional breach using simple means and limited resources, general skills, and low motivation. |
| SL 3 | Protection against an intentional breach using sophisticated means and moderate resources, IACS-specific skills and moderate motivation |
| SL 4 | Protection against an intentional breach using highly sophisticated means and significant resources, IACS-specific skills and high motivation |
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
This differentiated approach allows the standard to precisely tailor security measures to the specific requirements and risks of a system.
How do security levels differ for systems and components?
Application of security levels takes place at both the system and the component level. At the system level, as described in IEC 62443-3-3, specific security requirements (SRs) are defined for each FR. These SRs consist of base requirements and optional requirement enhancements (REs) that are mapped to the different SLs.
Relationship between FR, SR and RE in IEC 62443-3-3
On the component level, governed by IEC 62443-4-2, these SRs and REs are translated into component requirements (CRs) and corresponding REs.
Relationship between FR, SR, CR and RE in IEC 62443-4-2
IEC 62443-4-2 distinguishes four types of components:
Host devices (host device)
These are devices that 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 include file systems, programmable services, no real-time scheduler and a full human-machine interface (HMI) with keyboard, mouse, etc.
Network devices (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 applications (software application)
These include one or more software programs and their dependencies used to interact with the process or the control system itself. An example is configuration software. Software applications are typically run on host devices or embedded devices.
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, an 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 specific requirements for certain component types.
How are security levels achieved?
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 determined and the system is assembled accordingly. If a component does not meet a required SL, compensating countermeasures for that component must be planned.
For components the process is slightly different. First, the intended use must be determined or defined, potentially working with assumptions. Then the risk and required SL are assessed. Finally, it is specified which security requirements the component itself should meet and which can be fulfilled through integration into the system.
When evaluating components, it is important to understand that not all security requirements have to be met directly by the component itself. Requirements can be divided into two categories: requirements that are "met by component" and those that can be "met by integration into system."
This distinction enables a flexible approach to security implementation and acknowledges that some security functions can be more effectively implemented 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 allows for a balanced and efficient allocation of responsibilities between components and the overarching system.
Challenges when applying security levels
Applying security levels presents various challenges for organizations. One of the biggest hurdles is the continuous adaptation to an ever-changing threat landscape. Protections that are considered sufficient today may be inadequate tomorrow.
Another issue is the risk of over- or under-fulfillment of component requirements through blanket SL assignments. It is neither sensible nor in line with IEC 62443 to assign a component or product a blanket security level. 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.
The comparability of SLs further complicates application. Marketing tends to use blanket SLs for components that are not practically meaningful. The desire for easy product comparison through blanket SLs - particularly in the context of certifications - contradicts the differentiated approach of IEC 62443. Oversimplification can lead to a misjudgment of the actual security posture. Nevertheless, there are industry efforts to label components with blanket SLs. Some certification schemes (such as ISASecure) grant such blanket SLs for components. This practice does not align with the intent of IEC 62443 and should be viewed critically.
Recommendations and conclusion
For effective application of 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 in relation to the different FRs is essential. Possible compensating countermeasures for requirements that are 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 objectives in IACS. Their effective application requires a differentiated understanding and careful balancing of standardization and flexibility.
Challenges in applying security levels, especially in product certification, highlight the need for a holistic and context-based approach. Organizations must align their security measures with their specific requirements and risks to build robust protection against cyber threats.
Ultimately, successful implementation of security levels according to IEC 62443 is an ongoing 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 changing threat landscape.
Support for implementing IEC 62443
The IEC 62443 series provides a comprehensive framework for cybersecurity in industrial automation and control systems. For many organizations, practical implementation is a complex task - from correct zoning to determining appropriate security levels and implementing required security measures and compensating countermeasures.
Secuvi supports companies in systematically and practically implementing the requirements of IEC 62443. Whether risk analysis and zoning, determining the required security levels for specific use cases, or developing tailored security concepts - we help translate the complex requirements of the standard into actionable strategies that meet regulatory demands while remaining economically feasible.
If you are facing the challenge of implementing IEC 62443 in your organization or want to assess and optimize existing security concepts, we offer experienced expertise and proven solutions.