ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
IEC 62443 security levels come in three flavours — target, capability and achieved — and confusing them is the most expensive mistake an asset owner can make. Recording a supplier’s capability claim as though your plant had achieved it is a mistake that shows up in an audit report, not in a datasheet.
This guide explains what each one means, how to assign a target level that you can defend, and why a single number per plant is almost always the wrong answer.
Everything in this area gets easier once you separate the three.
| Level | Question it answers | Where it comes from |
|---|---|---|
| SL-T — target | What does this zone need? | Your risk assessment |
| SL-C — capability | What can this equipment do? | A supplier claim, which you verify |
| SL-A — achieved | What does the installed system actually deliver? | Verification of the system as configured |
Of the three IEC 62443 security levels, only SL-A delivers actual security. SL-T is the requirement; SL-C is a property of a product sitting in a box. Only SL-A describes your plant.
A component capable of SL 3, deployed with default credentials and no logging, achieves SL 1 at best. That gap between the capability on the datasheet and the reality on the panel is where most industrial security programmes quietly live.
| SL | Protects against a violation that is… |
|---|---|
| 0 | No specific requirement |
| 1 | Casual or coincidental |
| 2 | Intentional, using simple means, low resources, generic skills, low motivation |
| 3 | Intentional, using sophisticated means, moderate resources, IACS-specific skills, moderate motivation |
| 4 | Intentional, using sophisticated means, extended resources, IACS-specific skills, high motivation |
The dividing line between SL 2 and SL 3 is the presence of IACS-specific skills in the adversary. That gives you a usable question rather than an abstract one: would an attacker need to understand this kind of plant to cause the consequence you are worried about?
If someone could cause it with commodity malware and no process knowledge, you are in SL 2 territory. If causing real damage requires knowing how a batch reactor behaves, you are looking at SL 3.
IEC 62443 security levels are assigned per zone and conduit, never to a whole plant. That assignment comes out of the detailed risk assessment for the zone — specifically from the consequence of compromise and the threat capability credibly directed at it.
Use this as a starting position, then adjust with recorded reasoning:
| Assessed consequence | Credible threat | Indicative SL-T |
|---|---|---|
| Catastrophic or major safety or environmental | Capable, motivated, sector-targeted | 3 to 4 |
| Major production or equipment loss | Capable but not specifically targeted | 2 to 3 |
| Moderate, recoverable | Opportunistic | 2 |
| Minor, contained | Incidental | 1 |
Adjust down only on evidence. Cost and inconvenience are not grounds for lowering a target level. They are grounds for a roadmap entry and a recorded interim shortfall, which is a completely different thing from deciding the risk is smaller than it is.
Expressing IEC 62443 security levels as one number per zone is fine for a management report. For engineering, express the target as a vector across the seven foundational requirements of IEC 62443-3-3: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability.
Zones rarely need uniform strength. A batch control zone might need high system integrity and resource availability and comparatively little data confidentiality — the process values are not commercially sensitive, but their corruption is a safety matter.
Specifying a flat SL 3 across all seven buys you controls nobody needs while missing the ones that matter. The vector costs nothing extra to produce and makes procurement far more precise.
When you buy, ask for the claimed SL-C per foundational requirement, the component type it is claimed against, and the evidence. Then read the conditions.
A capability claim almost always depends on configuration — a feature being enabled, a particular mode being used, a companion product being present. A claim whose conditions are not met in your installed configuration simply does not apply to you.
Weight the evidence honestly:
Version matters more than people expect. Assurance that a product family is developed under a secure lifecycle does not establish that the firmware version running in your cabinet was.
Achieved IEC 62443 security levels are determined per zone, for the system as installed, configured and operated. For each applicable requirement, work through four questions:
That fourth question catches a lot. A technical capability with no process behind it does not deliver the requirement — logging that nobody reviews, or multifactor authentication with no joiners and leavers process, are capabilities on paper only.
The achieved level for a zone is set by its weakest relevant element. One unsupported device with no authentication holds the whole zone down for identification and authentication control, no matter how good everything else is.
This is why a gap analysis that shows which element is holding a zone down is worth more than one that just reports a number. It turns a gap into an investment case with a named component attached.
Where a requirement is satisfied by a compensating measure rather than by the component itself, record it that way. The distinction matters, because compensating measures usually depend on a process that can lapse — and when it lapses, the achieved level drops without anything visibly breaking.
A configuration change can lower achieved IEC 62443 security levels silently. That is why re-verification is tied to change control rather than left to an annual review: a hardening setting reverted during fault-finding and never restored is the classic case, and nothing alarms when it happens.
Re-verify after any change to a zone’s components or configuration, after a patch or firmware update, after a change to the zone model, when a supplier withdraws support for a component, and at least annually.
You can, but it will be wrong in both directions. Your safety-related zones will be under-protected and your reporting zones over-engineered. Uniform assignment across a model is almost always a sign the levels were copied rather than derived, and it is one of the first things an assessor tests.
No. Every level above what the risk requires costs money, adds operational friction and can introduce availability risk of its own. The point of assigning IEC 62443 security levels from risk is to spend protection where consequence actually lives.
Not by itself. Ask which part it is certified against — 4-2 is the component standard, 4-1 covers their development process, and they are different claims. Then ask for the scope statement and check it covers the model and firmware version you are buying, and that the conditions the claim depends on are met in your configuration.
Record the shortfall per foundational requirement, apply compensating measures, assess the residual risk, get it accepted in writing with a review date, and put the remediation on the roadmap. A recorded, compensated, scheduled shortfall is a managed position. The same shortfall undocumented is a finding.
IEC 62443 security levels sit downstream of partitioning — you cannot assign a target to a zone that has not been drawn yet. If you have not done that work, start with IEC 62443 zones and conduits and come back here.
Downstream, your target IEC 62443 security levels become the specification you hand to suppliers and engineers. For operators in scope of European regulation, they also evidence the technical measures behind NIS2 requirements, and the boundary between plant and corporate security is worth reading alongside NIS2 and ISO 27001.
The full system requirements and their per-level enhancements are defined in IEC 62443-3-3.
Our IEC 62443 Toolkit includes the security level determination procedure, the target level register with the seven-requirement vector, the rationale report and a gap workbook comparing target, capability and achieved levels — 117 editable documents in all. Whichever way you build them, keep the three levels apart on the page, because that separation is what makes the numbers mean something.
August 26, 2026
August 26, 2026
August 26, 2026
August 26, 2026
August 26, 2026