Security levels in IEC 62443 are not a one-size-fits-all product attribute. The deployment context determines them and SL 1 through SL 4 have different implications for manufacturers.
This article deliberately adopts the decision-making perspective: how do you as a manufacturer derive the appropriate security level for your product? If you first want to understand what the individual security levels mean in substance and how to achieve them technically, also read our introductory article Security level in IEC 62443: what they mean and how to achieve them.
A widespread misconception: a product has a single security level, similar to an IP protection class or a SIL rating. In practice, however, the security level in IEC 62443 is not a single value but a vector. That means different levels can apply to different security aspects (for example authentication, integrity protection, or availability).
The basis is the seven Foundational Requirements (FR) that serve as the foundation for all security requirements in IEC 62443:
- FR 1: Identification and authentication (IAC)
- FR 2: Use control (UC)
- FR 3: System integrity (SI)
- FR 4: Confidentiality (DC)
- FR 5: Restricted data flow (RDF)
- FR 6: Timely response to events (TRE)
- FR 7: Resource availability (RA)
The security level is determined separately for each of these Foundational Requirements. The concrete technical requirements for components are in IEC 62443-4-2, and the corresponding requirements for systems are in IEC 62443-3-3. A product may therefore, for example, require SL 3 for authentication but only SL 1 for confidentiality, depending on which threats are relevant in the specific deployment context.
Who sets the security level?
Here is the second key point that surprises many manufacturers at first: the security level is not defined by the manufacturer, but results from the deployment context at the operator. IEC 62443 distinguishes three perspectives on security levels:
- SL-T (Target): The target security level defined by the operator for their plant or zone. It is based on a threat and risk analysis of the specific deployment environment. A sensor in a publicly accessible building has different requirements than the same sensor in an isolated production facility.
- SL-C (Capability): The security level that a component or system can technically provide. This is the manufacturer’s perspective: which security functions are implemented in the product?
- SL-A (Achieved): The security level actually achieved in operation, depending on configuration, integration, and organizational measures.
For manufacturers the distinction between SL-T and SL-C is crucial: the operator defines what they need via SL-T. The manufacturer must demonstrate with SL-C what their product can deliver. The manufacturer’s task is to develop products that achieve a certain capability level so that operators can deploy them in the appropriate zones.
What distinguishes SL 1 to SL 4?
The four security levels describe increasing threat scenarios and the associated protection effort. The decisive factor is the assumed attacker profile in terms of means, resources, skills, and motivation:
| Security level | Threat / attacker | Resources | Know-how and motivation | Typical environment |
|---|---|---|---|---|
| SL 1 | Protection against random or accidental compromise | low | no special skills or motivation | environments with low threat potential |
| SL 2 | Intentional access using simple means | low | generic skills, low motivation | many industrial applications |
| SL 3 | Intentional access using advanced means | moderate | IACS-specific skills, medium motivation | facilities with increased protection needs |
| SL 4 | Intentional access using sophisticated means | extensive | IACS-specific skills, high motivation | critical infrastructures |
The jump between levels is not linear. The additional requirements from SL 1 to SL 2 are manageable. From SL 2 to SL 3 the development and evidence effort increases significantly. SL 4 is in practice relevant for only a very small portion of products, typically in the context of critical infrastructures.
What does this mean for manufacturers?
The central insight: you cannot set your product’s security level in isolation. It follows from the question of which deployment environments your product will be used in and which threat scenarios are realistic there. This has concrete consequences for product development:
- Understand target markets. You must know which markets and deployment scenarios you are addressing. A manufacturer whose components are used exclusively in noncritical building automation systems has different requirements than a manufacturer supplying controllers to utilities.
- Not a one-time decision but ongoing. The security level is not a decision to be made once and then forgotten. If the deployment context changes or an operator tightens their requirements, the product must be able to keep up, otherwise it will no longer fit into the intended zone.
- Capability level determines the effort. The targeted capability level determines the development effort. Which cryptographic methods are necessary? Which authentication mechanisms? Which logging and monitoring capabilities? All of this depends directly on the target SL.
If you use IEC 62443 as a basis for complying with the Cyber Resilience Act, see our article IEC 62443 as a basis for implementing the Cyber Resilience Act.
Conclusion
The question “Which security level does my product need?” cannot be answered with a single number. Security levels in IEC 62443 are a vector made up of the deployment context, the threat scenarios, and the specific Foundational Requirements. For manufacturers this means: those who know their target markets and the typical operator requirements there can derive the appropriate capability level and invest purposefully in the right security functions.
Unsure which security level your product must achieve?
Secuvise supports you in deriving the appropriate capability level from your target markets and deployment contexts and in prioritizing the right security functions.
Schedule a consultation
