IEC 62443 Security Levels: What They Mean and How to Pick a Target
Security levels are one of the most useful ideas in IEC 62443, and one of the most misunderstood. They are often treated as a grade to brag about, as in "we're SL3", when they are really a way to match protection to the threat a particular part of your system realistically faces. Getting them right saves money and focuses effort where it counts.
What a security level describes
In 62443, a security level (SL) describes the kind of adversary a zone, system or component is able to resist. It is not a measure of how important an asset is, and it is not a maturity score for your organization. It answers one question: against what level of attacker capability and intent is this protection intended to hold?
The levels are defined in terms of the means, resources, skills and motivation of whoever is trying to cause harm. There is also an SL0, which simply means no specific security requirements apply.
The four levels
SL1: Protection against casual or coincidental violation. This covers mistakes and accidents: an operator plugging in the wrong laptop, a contractor changing a setting they should not have access to, or malware that wanders in without anyone targeting you.
SL2: Protection against intentional violation using simple means with low resources, generic skills and low motivation. Think of an opportunistic attacker using widely available tools and general IT knowledge, with no particular interest in your facility.
SL3: Protection against intentional violation using sophisticated means with moderate resources, IACS-specific skills and moderate motivation. This is an attacker who understands industrial protocols and control systems and has a reason to go after you, such as an organized criminal group or a capable hacktivist.
SL4: Protection against intentional violation using sophisticated means with extended resources, IACS-specific skills and high motivation. This is the well-funded, persistent adversary, the kind of threat that governments have publicly attributed to state-backed groups targeting critical infrastructure.
The jump between levels is not just more controls. Each step assumes a more capable and determined adversary, which usually means stronger authentication, tighter segmentation, better monitoring and more rigorous change control.
Target, achieved and capability
62443 uses three related terms, and confusing them causes most of the trouble.
SL-T (target security level) is the level you decide a zone or conduit needs, based on your risk assessment. It is a requirement.
SL-A (achieved security level) is the level the zone actually reaches in practice, once you account for how systems are configured, operated and maintained. It is a measurement.
SL-C (capability security level) is the level a component or system can reach when properly configured. It describes what the product is capable of, typically as stated by the supplier or confirmed through certification against 62443-3-3 or 62443-4-2.
The relationship is straightforward. You set SL-T. You choose products whose SL-C is high enough to meet it. Then you configure, operate and verify the system so that SL-A actually matches SL-T. A product with SL-C 3 installed with default passwords and an open remote access path will not give you an SL-A of 3.
Security levels are a vector, not a single number
Strictly speaking, a security level is assigned per foundational requirement, so a zone has seven values rather than one. A zone might need SL3 for restricted data flow and use control, but only SL1 for data confidentiality because the data it carries is not sensitive. In practice many organizations simplify to a single headline number per zone, which is fine as a starting point, but the per-requirement view is where you find savings and spot weak points.
How to pick a target for each zone
Target levels come out of the risk assessment process in 62443-3-2. A practical approach looks like this:
Start with consequences. For each zone, ask what the worst credible outcome would be if it were compromised: a safety incident, an environmental release, a long outage, a quality problem or a minor inconvenience.
Consider who would realistically target it. A remote water lift station and a pipeline control centre face different adversaries. Public profile, sector and geopolitical exposure all matter.
Account for existing safeguards. Safety instrumented systems, mechanical protections and manual fallbacks reduce consequence and can lower the target you need.
Set the target per zone and per conduit. Conduits that cross into a zone generally need protection consistent with the higher of the zones they connect.
Record the reasoning. A short, written justification for each target makes later audits, purchasing decisions and reassessments far easier.
Not every zone needs SL3
A common mistake is to declare SL3 or SL4 everywhere because it sounds responsible. It usually is not. Higher targets drive real cost in hardware, licensing, staffing and operational friction, and an unrealistic target tends to produce a plan that never gets finished.
A typical facility might reasonably end up with something like this:
A safety instrumented system zone at a high target, because the consequences of compromise are severe.
Core control zones for critical processes at SL2 or SL3, depending on threat exposure.
Less critical areas, such as building systems or non-production test benches, at SL1 or SL2.
Remote access conduits and the industrial DMZ at a level at least as high as the most sensitive zone they reach.
The goal is honest alignment between risk and protection. A well-justified SL2 that is actually achieved is worth far more than an SL3 that exists only on paper.
How QBits Networks can help
Our IEC 62443 gap assessments help you set defensible target security levels for each zone and measure how far your achieved levels fall short. Paired with a network segmentation review, that gives you a clear picture of where to invest first. Tell us what you need through our contact page and we'll scope it with you.