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-3-3, Annex A, Clause A.3.2
Reference: ISA/IEC 62443-1-1, Clause 5.10
ISA/IEC 62443-3-3 maps system security requirements to Foundational Requirements and Security Levels. Annex A Clause A.3.2 is the teaching focus when you need to state, select and verify cybersecurity capability in system-requirements language — including how SL types and SL vectors are written.
A Security Level answers how strong the posture of a system, zone or conduit must be so it can keep functioning under cyber stress. Assigning levels to zones and conduits lets different parts of the architecture get protection matched to risk.
Pick the level from risk thinking: attack likelihood, consequence (safety, environment, production, reputation), asset criticality, and adversary capability and motivation. Levels are cumulative — each step up builds on the capability demanded below it.
For Part 1-1 concept foundations, see IEC 62443-1-1 Clause 5.10 – Security Levels.
In industrial projects, SL 1–4 are the usual engineering targets; SL 0 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 intentional cyber resistance is out of scope for that system — often isolated labs, stand-alone tests or non-critical demos. Physical isolation and operational discipline may still matter; they are simply not framed as an SL target.
SL 1 addresses mistakes and low-effort misuse. Adversaries are assumed to know little about IACS and to have little motivation. Teaching examples include basic authentication and accounts, simple access rules and everyday awareness practices.
SL 2 assumes deliberate targeting with everyday tools and limited means — general technical skill without deep ICS expertise or large budgets. Typical responses include role-based access, stronger authentication, segmentation, logging, hardening and basic monitoring.
SL 3 assumes adversaries with IACS knowledge who can tailor attacks and work around ordinary safeguards. Designs emphasise defence-in-depth: strong authentication, controlled remote access, protected communications, robust segmentation, rich monitoring and ongoing vulnerability and risk review.
SL 4 covers highly capable, well-resourced adversaries, including advanced persistent threat styles of campaign. Expect intensified segmentation and hardening, continuous monitoring, secure-by-design engineering, strict access management and mature incident response.
Annex A Clause A.3.2 uses the same 0–4 scale for three different engineering questions when system security requirements are applied:
| 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. | Product selection, integration and comparing supplier capability against IEC 62443-3-3 requirements. |
| 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.
A single SL number can hide uneven needs across Foundational Requirements. Clause A.3.2 therefore supports richer expression — notably the security level vector — so targets match how requirements are applied in practice.
Instead of only saying “SL-T = 3”, a vector can assign a level to each of the seven Foundational Requirements (FRs):
Example form:
SL-T (Zone) = { FR1, FR2, FR3, FR4, FR5, FR6, FR7 }
That lets a zone demand stronger identification and authentication than confidentiality when risk analysis supports the split. The same vector idea applies to SL-C and SL-A when you compare capability and achievement to target.
SL-A reflects the installed solution: device and system strengths (including claimed SL-C), surrounding countermeasures, conduit strength, neighbouring zone levels, configuration and integration quality, and operational processes such as patching, accounts, backup, incident response, audit and test cycles.
A high SL-C product can still yield a weak SL-A if it is misconfigured, poorly segmented or run without adequate procedures.
Carry Security Levels through the IACS lifecycle:
If SL-A trails SL-T, strengthen design and compensations or reopen risk acceptance explicitly — do not leave the gap unstated.