Choosing the Right IEC 62443 Security Level for Your Product

Manufacturers working with IEC 62443 often ask one question first: “Which security level does our product have to meet?” The short answer is that you do not decide this alone. The longer answer requires an understanding of how security levels in IEC 62443 actually work, and of why asking for “the one level” already points in the wrong direction.

This article takes the decision perspective: how do you as a manufacturer derive the right security level for your product? If you first want to understand what the individual security levels mean and how to achieve them technically, read our introduction Security Levels in IEC 62443 and How to Achieve Them.

Contents

1. Security levels are not a single value
2. Who sets the security level?
3. How do SL 1 to SL 4 differ?
4. What does this mean for manufacturers?
5. Derive the level from your markets, not from a single number

Security levels are not a single value

A common misunderstanding is that a product has one security level, similar to an IP rating or a SIL classification. In IEC 62443, however, the security level is not a single value but a vector. Different levels can apply to different security aspects, such as authentication, integrity protection, or availability.

The basis is the seven foundational requirements (FR), which form the foundation of all security requirements in IEC 62443:

• FR 1: Identification and authentication control (IAC)
• FR 2: Use control (UC)
• FR 3: System integrity (SI)
• FR 4: Data 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 specific 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 need SL 3 for authentication, for example, but only SL 1 for confidentiality, depending on which threats are relevant in the specific context of use.

Who sets the security level?

The second point surprises many manufacturers at first. The manufacturer does not define the security level. It follows from the asset owner's context of use. IEC 62443 distinguishes three views of a security level:

• SL-T (target): the target security level that the asset owner, often together with the system integrator, defines for its plant or zone. It is based on a threat and risk analysis of the specific operating environment. A sensor in a publicly accessible building has different requirements from the same sensor in an isolated production plant.
• SL-C (capability): the security level that a component or system can technically provide. This is the manufacturer's view: which security functions are implemented in the product?
• SL-A (achieved): the security level actually achieved in operation. It depends on configuration, integration, and organizational measures.

For manufacturers, the difference between SL-T and SL-C is what matters. Through the SL-T, the asset owner defines what it needs. Through the SL-C, the manufacturer must demonstrate what its product can do. Your task as a manufacturer is to develop products that reach a defined capability level, so that asset owners can use them in the corresponding zones.

How do SL 1 to SL 4 differ?

The four security levels describe increasingly demanding threat scenarios and the protection effort they require. The assumed attacker profile is decisive: means, resources, skills, and motivation.

Security level	Threat or attacker	Resources	Skills and motivation	Typical environment
SL 1	Protection against casual or coincidental violation	Low	None in particular	Environments with a low threat potential
SL 2	Intentional violation using simple means	Low	Generic skills, low motivation	Many industrial applications
SL 3	Intentional violation using sophisticated means	Moderate	IACS-specific skills, moderate motivation	Plants with higher protection needs
SL 4	Intentional violation using sophisticated means	Extended	IACS-specific skills, high motivation	Critical infrastructure

The step between levels is not linear. Going from SL 1 to SL 2 adds a manageable number of requirements. Going from SL 2 to SL 3 increases the development and verification effort considerably. In practice, SL 4 is relevant only for a very small share of products, typically in critical infrastructure.

What does this mean for manufacturers?

The main insight is that you cannot set the security level of your product in isolation. It depends on the environments in which your product is meant to be used, and on which threat scenarios are realistic there. This has concrete consequences for product development:

1. Understand your target markets. You must know which markets and use cases you address. A manufacturer whose components end up only in non-critical building automation systems has different requirements from a manufacturer that supplies controllers to energy utilities.
2. Treat it as ongoing, not one-off. The security level is not a decision you make once and then forget. If the context of use changes or an asset owner tightens its requirements, the product must be able to keep up. Otherwise, it no longer fits the intended zone.
3. The capability level determines the effort. The capability level you aim for determines the development effort. Which cryptographic methods do you need? Which authentication mechanisms? Which logging and monitoring capabilities? All of this depends directly on the target SL.

If you use IEC 62443 as the basis for meeting the Cyber Resilience Act, our article Using IEC 62443 to Meet Cyber Resilience Act Requirements explains how the two fit together.

Derive the level from your markets, not from a single number

The question “Which security level does my product need?” cannot be answered with a single number. Security levels in IEC 62443 form a vector that results from the context of use, the threat scenarios, and the individual foundational requirements. If you know your target markets and the asset owner requirements typical there, you can derive the right capability level and invest specifically in the security functions that matter.