IEC 62443 uses Security Levels (SLs) as a shared language for how much cybersecurity protection an Industrial Automation and Control System (IACS) needs. The aim is risk-proportionate objectives — not the same control set forced onto every system.
Reference: ISA/IEC 62443-1-1, Clause 5.10
Reference: ISA/IEC 62443-3-3, Annex A, Clause A.3.2
A Security Level is a compact way to say how strong the cybersecurity posture of a system, zone or conduit needs to be so that it can keep doing its job under cyber stress. Assigning levels to zones and conduits lets different parts of the plant receive protection matched to risk instead of a single plant-wide setting.
Choose the level from risk thinking, not habit. Ask how likely an attack is, what could go wrong for safety, environment, production or reputation, how critical the assets are, and how capable and motivated plausible adversaries look.
Levels stack: each step up assumes everything below it and then demands more capability.
Clause 5.10 gives a graduated protection scale. In industrial projects, SL 1–4 are the usual engineering targets; SL 0 simply means no specific cybersecurity requirements were set.
| Security Level | Protection Against | Threat Capability |
|---|---|---|
| SL 0 | No specific cybersecurity requirements. | No intentional cyber threat is specifically addressed. |
| SL 1 | Casual or accidental violation. | Unintentional misuse or casual attackers with little ICS knowledge. |
| SL 2 | Intentional violation using simple means. | Low-skilled attackers using common tools and limited resources. |
| SL 3 | Intentional violation using sophisticated means. | Skilled attackers with moderate resources and IACS-specific knowledge. |
| SL 4 | Intentional violation using sophisticated means with extended resources. | Highly capable, well-resourced attackers (for example advanced persistent threats). |
Use SL 0 when the organisation has decided that the asset does not need a defined cyber protection target. It is not “secure by hope”; it is explicit recognition that intentional cyber resistance is out of scope — often because the system is isolated, temporary or non-critical (lab benches, stand-alone demos, pure test rigs). Physical isolation and operational discipline may still apply, but they are not framed as an SL target.
SL 1 is the baseline for mistakes and low-effort misuse rather than determined attack. Expect adversaries with little IACS knowledge and little drive. Teaching examples of controls include basic accounts and passwords, simple access rules and everyday security awareness — enough to stop casual harm without building a full high-assurance architecture.
At SL 2 someone is trying, but with everyday tools and modest means. They may understand IT security broadly yet lack deep ICS expertise or budgets for custom campaigns. Typical plant responses move beyond passwords alone: role-based access, stronger authentication, network segmentation, logging, hardening and basic monitoring.
SL 3 assumes adversaries who know industrial systems, can tailor attacks and will try to bypass ordinary safeguards. Resources are meaningful but not unlimited. Designs lean on defence-in-depth: strong authentication, carefully controlled remote access, protected communications, serious segmentation, rich logging and monitoring, and ongoing vulnerability and risk review.
SL 4 is reserved for the hardest cases — adversaries with time, money, advanced techniques and deep knowledge of the target, including nation-state style campaigns. Controls intensify across the board: fine-grained segmentation, aggressive hardening, continuous monitoring, secure-by-design engineering, tightly managed access and a mature incident-response capability.
The same 0–4 numbers appear in three engineering questions. Clause 5.10 (and related type definitions) separates what you aim for, what a product can deliver on its own, and what the installed system actually achieves.
| Type | Meaning | When Used |
|---|---|---|
| SL-T (Target) |
The Security Level you need for a system, zone or conduit after risk assessment. | Risk work, requirements writing and design. |
| SL-C (Capability) |
What a product or system can deliver natively when correctly configured and integrated, before counting extra compensating controls. | Choosing products, integrating systems and comparing supplier offerings. |
| SL-A (Achieved) |
What you actually get once the design is built, configured and checked. | Verification, commissioning, operations and improvement cycles. |
Relationship: Risk Assessment → Determine SL-T → Select and configure products with sufficient SL-C → Implement compensating controls where required → Validate that SL-A ≥ SL-T.
For the system-requirements expression of these concepts (including SL vectors), see IEC 62443-3-3 Security Levels (Annex A.3.2).
SL-A is an outcome of the installed solution, not a sticker on a box. In practice it reflects device and system strengths (including claimed SL-C), the countermeasures wrapped around them, the strength of connecting conduits, the levels of neighbouring zones, how well the plant was configured and integrated, and whether day-to-day processes — patching, accounts, backup, incident response, audit and test cycles — keep that posture alive.
A high SL-C product can still land at a weak SL-A if it is misconfigured, poorly segmented or run without adequate procedures.
Treat Security Levels as a lifecycle thread, not a one-off design label:
If SL-A trails SL-T, either strengthen design and compensations or reopen the risk-acceptance decision explicitly — do not leave the gap implicit.