The Safety Integrity Level can be summed across subsystems, the Security Level Capability cannot. This explains why SIL and SL-C follow different logic.
The Safety Integrity Level (SIL) according to IEC 61508 describes how reliably a safety function withstands random failures. It is based on failure probabilities. Security levels under IEC 62443 describe which type of attacker a system should withstand — that is, intent rather than randomness. This difference determines whether levels can be added together or not.
The Performance Level (PL) under ISO 13849-1 and the Automotive Safety Integrity Level (ASIL) under ISO 26262 are independent metrics with their own calculation methods, but they follow the same basic logic. What follows about SIL applies analogously to both.
Why safety integrity levels can 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 across the subsystems of a safety chain: sensor, logic unit, and actuator each contribute to the total value. If the sum falls within the target band, the required SIL is achieved.
ISO 13849-1 calculates differently, but according to the same principle. The Performance Level is derived from MTTFd, diagnostic coverage, common-cause failures, and the chosen category. ISO 26262 even allows ASIL decomposition to split a requirement deliberately across several independent elements. In all three cases, combining subsystems with known metrics yields a calculable statement about the whole.
That 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 provides verifiable parameters. The integrator then continues the calculations using those values. The assumptions remain manageable because physical failure mechanisms do not adapt to the use case. A relay ages in a packing machine under the same laws as in water treatment.
Why this principle does not work for security
An attacker chooses the target, the tools, and the timing. They exploit wherever assumptions were not met. There is no failure rate for that.
Take a machine control whose components all advertise a Security Level Capability of SL-C 2. Each supports role-based access control, password policies, and encrypted communication. During commissioning the service account is left on the factory-default password because maintenance needs a shared access. The components still meet their stated capabilities, yet the system remains vulnerable.
A capability must be configured, operated, and maintained, otherwise it has no effect. There is no such gap between a PFH value and its effect. From this follows: a security element out of context cannot exist. Without a defined purpose, environment, threat landscape, and assumptions about the operator, stating a Security Level is meaningless.
What the security level under IEC 62443 means
A security level there is not a scalar but a vector across the seven Foundational Requirements, from identification and authentication control to resource availability. A product can achieve SL 3 for access control and SL 1 for availability. The short form “the device has SL 2” loses that information.
The standard also distinguishes the target level SL‑T from the zone risk assessment, the product capability SL‑C, and the achieved level SL‑A 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 demands a documented product security context — that is, the definition of the environment, purpose, and assumptions for product use. SR‑2 then requires a threat model based on that context. Only from that can one deduce which requirements from IEC 62443‑4‑2 are relevant and which Security Level Capability a product can claim. The order is normative: context, threats, measures, level.
Why the CRA requires a risk‑based approach
The Cyber Resilience Act (Regulation (EU) 2024/2847) anchors the same logic in law. Annex I Part I number 1 requires that products with digital elements ensure an appropriate level of cybersecurity based on the risks. The product requirements in number 2 are each subject to the proviso that they must be appropriate to the risks. Articles 13(2) and 13(3) obligate manufacturers to perform a cybersecurity risk assessment and to document it in the technical documentation per Annex VII.
Decisive are the intended use and the reasonably foreseeable use. A blanket SL‑C 2 does not answer that question: it is insufficient for a safety‑critical plant component and excessive for an isolated device. How the CRA requirements and the processes of IEC 62443 translate into one another concerns that interface.
What this means for manufacturers of generic components
The hardest situation is when products end up in very different plants. An embedded controller with a web interface and fieldbus can sit behind a firewall in a packaging machine, hang on a cellular network in a decentralized pump station, or run in a test rig with changing service accesses. The threat landscape and sensible measures differ considerably.
The answer is not to set the highest possible level, but a manageable number of typical use scenarios: each evaluated and documented with which assumptions about the environment apply, which protective measures the product provides, which the integrator or operator must provide, and under which conditions which Security Level Capability applies. IEC 62443‑4‑2 explicitly allows that requirements can also be met by compensating measures at the system level, provided this is documented.
Integrators and operators need this documentation anyway. A single number in the data sheet does not help them with their own risk assessment under IEC 62443‑3‑2; a robust list of assumptions and residual risks does.
Conclusion
SIL 2 and SL‑C 2 sound similar but mean different things. The Safety Integrity Level describes a calculable property that can be derived from subsystems; the same applies to Performance Level and ASIL. The Security Level describes a capability that only becomes security in a defined context and through correct operation. Security therefore must be thought from the use case and the operator, not from the component.
And how does that look for your product?
A blanket security level is not enough. What matters is whether your development process derives the context, the threats, and the measures cleanly. The free 15‑question check shows you in a few minutes where you stand with IEC 62443‑4‑1 — with immediate recommendations for action.
