How to Calculate an IEC 62443 Security Level
IEC 62443 is the international standard for securing industrial automation and control systems, and its Security Level model is how OT teams express how much protection a zone needs and whether it has it. This guide shows you how to calculate a Security Level end to end — partition the system into zones, set a risk-based target, map it across the seven Foundational Requirements, and find the gap between the level you need and the level you actually have.
In plain words
Calculating an IEC 62443 Security Level means deciding how much protection an OT zone needs (the target, SL-T), checking how much it actually delivers (the achieved level, SL-A), and planning the difference — and PlayCISO has a free, browser-based calculator that does it with you. The Security Level is not one number: it is a vector of one value per Foundational Requirement.
IEC 62443-3-3 defines Security Levels 0 to 4 — from no specific protection up to resistance against sophisticated, well-resourced attackers — across seven Foundational Requirements: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. The goal is a defensible, risk-based level per zone, not the maximum everywhere.
Step by step
- 1
Partition the system into zones and conduits
Per IEC 62443-3-2, group assets with common security requirements into zones and define the conduits (the communication paths) that carry traffic between them. A zone might be a safety instrumented system, a control network, or a DMZ; a conduit is the firewalled link between them. You calculate a Security Level per zone and per conduit, not for the plant as a whole, so the boundary you draw here determines everything that follows.
- 2
Set the target Security Level (SL-T) from a risk assessment
SL-T is the Security Level you need a zone to reach, and it is driven by a risk assessment (IEC 62443-3-2), not chosen arbitrarily. IEC 62443 defines five levels: SL 0 (no specific protection), SL 1 (protection against casual or coincidental violation), SL 2 (intentional violation using simple means, low resources and generic skills), SL 3 (sophisticated means, moderate resources and IACS-specific skills), and SL 4 (sophisticated means, extended resources and high motivation). A zone protecting a safety function usually targets SL 3; a business-side zone may only need SL 1.
- 3
Understand the seven Foundational Requirements
IEC 62443-3-3 organizes every system requirement under seven Foundational Requirements (FRs): FR1 Identification and Authentication Control, FR2 Use Control, FR3 System Integrity, FR4 Data Confidentiality, FR5 Restricted Data Flow, FR6 Timely Response to Events, and FR7 Resource Availability. A Security Level is not a single number — it is a vector of one SL per FR, so a zone can target SL 3 for system integrity (FR3) while only needing SL 1 for data confidentiality (FR4).
- 4
Map each FR to SL 1–4 using system requirements
Within each FR, IEC 62443-3-3 lists system requirements (SRs) and optional requirement enhancements (REs). The base SR is generally what is needed for SL 1; the requirement enhancements add capability for SL 2, 3 and 4. For FR1, for example, higher levels add multifactor authentication and tighter credential management. Work out, per FR, exactly which SRs and REs the target level demands so you have a concrete checklist rather than a label.
- 5
Assess the achieved Security Level (SL-A) with evidence
SL-A is what the zone actually delivers once installed, configured and operating — as distinct from SL-C, the security capability a component or system can provide when correctly configured. Walk each FR and verify, with evidence (configuration exports, test results, architecture review), which SRs and REs are genuinely met in the live environment. A control that exists but is misconfigured or disabled does not count toward the achieved level.
- 6
Find the gaps — where achieved is below target
Compare SL-A against SL-T for every one of the seven FRs. Any FR where the achieved level is below the target is a gap, and because SL is a vector the gaps are specific: you might meet SL-T on six FRs and fall short only on FR5 (restricted data flow) because a conduit lacks proper segmentation. Record each shortfall against the exact SR or RE that is missing so the gap is actionable, not just a lower number.
- 7
Plan remediation or justified compensating controls
Turn each gap into a plan: add the missing control to raise the achieved level to target, or — where a control is impractical on legacy OT equipment — document a compensating control (network segmentation, monitoring, or restricted access) and the residual risk the asset owner formally accepts. Sequence the work by the risk each gap leaves open, re-assess after changes, and keep the SL-T / SL-A vectors as living records that move toward target over time.
Set a target SL per zone, map it across all seven Foundational Requirements, record the achieved level with evidence, and see the gaps — in your browser, no spreadsheet required.
Related
The interactive target-vs-achieved Security Level tool this guide walks you through.
OT / ICS security guideThe broader context — segmentation, zones, and defending industrial control systems.
OT compliance mapperMap IEC 62443 controls across the other OT frameworks and regulations you answer to.
ICS attack threat modelModel the ICS threats that justify the target Security Level you set for each zone.
Frequently asked questions
What is the difference between SL-T, SL-C and SL-A?
SL-T (target) is the Security Level a zone needs to reach, derived from a risk assessment. SL-C (capability) is the security capability a component or system can deliver when it is correctly configured — what it is capable of, independent of deployment. SL-A (achieved) is what the zone actually delivers once installed, configured and operating in the real environment. You set SL-T, you select products whose SL-C meets it, and you verify the as-built SL-A matches. A gap is any FR where SL-A is below SL-T.
What are the seven Foundational Requirements?
IEC 62443-3-3 defines seven FRs that every system requirement rolls up to: FR1 Identification and Authentication Control, FR2 Use Control, FR3 System Integrity, FR4 Data Confidentiality, FR5 Restricted Data Flow, FR6 Timely Response to Events, and FR7 Resource Availability. A Security Level is expressed as a vector of one SL value per FR, so a zone does not have a single SL — it has seven, one for each Foundational Requirement.
What do the Security Levels 0 to 4 actually mean?
They describe the sophistication of attacker a zone can resist (per IEC 62443-3-3). SL 0 means no specific security requirements. SL 1 protects against casual or coincidental violation. SL 2 protects against intentional violation using simple means with low resources, generic skills and low motivation. SL 3 protects against sophisticated means with moderate resources, IACS-specific skills and moderate motivation. SL 4 protects against sophisticated means with extended resources, IACS-specific skills and high motivation — nation-state-grade effort.
How do I actually calculate the SL for an FR?
Within each Foundational Requirement, IEC 62443-3-3 lists system requirements (SRs) and optional requirement enhancements (REs). The base SRs are generally required for SL 1, and the requirement enhancements raise the bar for SL 2, 3 and 4. To determine the achieved level for an FR, check which SRs and REs are genuinely met with evidence; the highest level for which all required SRs and REs are satisfied is the achieved SL for that FR. Describe the exact mapping per the IEC 62443-3-3 tables for your version of the standard.
Do all seven FRs have to hit the same Security Level?
No. Because the Security Level is a vector, different FRs can target different levels based on the risk to that zone. A safety-critical control zone might target SL 3 for system integrity (FR3) and resource availability (FR7) but only SL 1 for data confidentiality (FR4) if the data it carries is not sensitive. Forcing every FR to the highest level wastes effort on OT equipment where some protections add little risk reduction.
What if legacy OT equipment cannot meet the target SL?
This is common, and IEC 62443 anticipates it. Where a device cannot be upgraded to meet the target level for an FR, you document a compensating control — network segmentation, strict conduit rules, enhanced monitoring, or restricted physical and logical access — and the asset owner formally accepts the residual risk. The goal is a defensible, documented risk posture per zone, not pretending a 1990s PLC can authenticate like a modern server.