Why Security Levels Do Not Add Up Like Safety Integrity Levels
The same equation comes up in project meetings again and again. A product reaches SIL 2, so it also needs SL-C 2, and both describe roughly the same level of rigor. The number may match, but the logic behind it does not. You cannot tick off security levels at component level and then add them up to a secure overall system.
Contents
- How do safety integrity levels and security levels differ?
- Why can safety integrity levels be combined?
- Why does this principle not work for security?
- What does a security level under IEC 62443 express?
- Why does the CRA require a risk-based approach?
- What does this mean for manufacturers of generic components?
- Same number, different meaning
How do safety integrity levels and security levels differ?
The safety integrity level (SIL) under IEC 61508 describes how reliably a safety function withstands random failures. It is based on failure probabilities. Security levels under IEC 62443 describe the kind of attacker a system must withstand, so they deal with intent rather than chance. This difference decides whether levels can be combined or not.
The performance level (PL) under ISO 13849-1 and the automotive safety integrity level (ASIL) under ISO 26262 are separate metrics with their own calculation methods. They follow the same basic logic, though. What this article says about SIL applies to both accordingly.
Why can safety integrity levels be combined?
IEC 61508 describes a safety function by the probability of a dangerous failure, expressed as PFD or PFH. These values can be added up across the subsystems of a safety chain: sensor, logic unit, and actuator each contribute to the total. If the sum falls within the target band, the required SIL is reached.
ISO 13849-1 calculates differently but follows the same principle. The performance level results from MTTFd, diagnostic coverage, common cause failures, and the selected category. ISO 26262 even allows ASIL decomposition, which deliberately splits a requirement across several independent elements. In all three cases, combining subsystems with known metrics gives a calculable statement about the whole.
This is why the safety element out of context works in the safety domain. A supplier develops an element without a specific target system, documents its assumptions, and supplies verifiable metrics. The integrator continues the calculation with them. The assumptions stay manageable because physical failure mechanisms do not adapt to the application. A relay ages by the same laws in a packaging machine as in a water treatment plant.
Why does this principle not work for security?
An attacker chooses the target, the tool, and the timing. They use the spot where assumptions were not met. There is no failure rate for that.
Take a machine control system whose components all have a security level capability of SL-C 2. Each supports role-based access control, password policies, and encrypted communication. During commissioning, the service account keeps its default password because maintenance needs a shared account. The components still fully meet their requirements, yet the system is open to attack.
A capability must be configured, operated, and maintained, or it has no effect. A PFH value has no such gap between the figure and its effect. It follows that a security element out of context cannot exist. Without the intended purpose, environment, threat situation, and assumptions about the operator, a security level statement has no meaning.
What does a security level under IEC 62443 express?
In IEC 62443, a security level is not a scalar but a vector across the seven foundational requirements, from identification and authentication control to resource availability. A product can reach SL 3 for access control (use control) and SL 1 for availability. The shorthand “the device has SL 2” loses this information.
The standard also distinguishes the target level SL-T from the risk assessment of the zone, the capability SL-C of the product, and the level SL-A achieved in operation.
For manufacturers, IEC 62443-4-1 is the decisive standard. It describes the secure development process and requires two things at its start. SR-1 requires a documented product security context: the environment, purpose, and assumptions under which the product is used. SR-2 builds on this and requires a threat model. Only from these can you derive which requirements of IEC 62443-4-2 are relevant and which security level capability a product can claim. The standard prescribes the order: context, threats, measures, level.
Why does the CRA require a risk-based approach?
The Cyber Resilience Act (Regulation (EU) 2024/2847), or CRA, anchors the same logic in law. Annex I, Part I, point 1 requires products with digital elements to ensure an appropriate level of cybersecurity based on the risks. Each of the product requirements in point 2 applies on the basis of the cybersecurity risk assessment and where applicable. Article 13(2) and (3) require manufacturers to carry out and document a cybersecurity risk assessment, and Article 13(4) requires them to include it in the technical documentation under Annex VII.
The intended purpose and the reasonably foreseeable use are what count. A blanket SL-C 2 does not answer this question: for a safety-critical part of a plant it is too little, for a device operated in isolation it is too much. At this interface, CRA requirements and IEC 62443 processes have to be translated into each other. See IEC 62443 as a basis for the CRA.
What does this mean for manufacturers of generic components?
The situation is hardest when products end up in very different plants. Take an embedded controller with a web interface and fieldbus. It may sit behind a firewall in a packaging machine, connect to the mobile network in a remote pumping station, or run in a test rig with changing service access. The threats and the appropriate measures differ considerably.
The answer is not to set the level as high as possible. It is a manageable number of typical deployment scenarios. For each one, assess and document:
- which assumptions about the environment apply,
- which protective measures the product provides,
- which measures the integrator or operator must provide, and
- which security level capability applies under which conditions.
IEC 62443-4-2 explicitly allows requirements to be met by compensating countermeasures at system level, provided this is documented.
Integrators and asset owners need this documentation anyway. A number in the data sheet does not help them with their own risk assessment under IEC 62443-3-2. A reliable list of assumptions and residual risks does.
Same number, different meaning
SIL 2 and SL-C 2 sound similar but mean different things. The safety integrity level describes a calculable property that can be combined across subsystems, and the same applies to the performance level and ASIL. The security level describes a capability that only becomes security in a defined context and through correct operation. Security must therefore be designed from the deployment scenario and the operator, not from the component.
How does this apply to your product?
A blanket security level is not enough. What matters is whether your development process derives the context, the threats, and the measures properly. Not sure where you stand with IEC 62443-4-1? Book a call.
