One level, seven numbers

The question comes up in audits, in tenders and from the insurer: "What security level does your production have?" Whoever answers "SL 2" has not read the standard. Whoever answers "it depends" has read it, but does not sound like it.

Four levels, defined by the attacker

IEC 62443 describes security levels 1 to 4 not by measures but by the adversary they are meant to withstand. SL 1 protects against casual or coincidental violation. SL 2 against intentional attacks with simple means, low resources and generic skills. SL 3 against sophisticated means, moderate resources and skills specific to industrial control systems. SL 4 against the same with extended resources and high motivation.

That is the first reason a number on its own says nothing: it describes an adversary, not a state.

Seven foundational requirements

The second reason is that the standard splits protection into seven foundational requirements: identification and authentication, use control, system integrity, data confidentiality, restricted data flow, timely response, resource availability. Each has system requirements with a minimum level from which they apply.

A production cell may need SL 3 for availability and SL 1 for data confidentiality, because the recipe is on the type plate anyway. A zone’s security level is therefore a vector of seven values. In the notation of the standard: SL 2 {3 2 2 1 2 1 2}. The number before the braces is the minimum; the braces are the statement.

Three letters

The third reason: there is not one level but three. SL-T is the target that comes out of the risk assessment. SL-A is what the zone actually achieves. SL-C is what a single device can deliver at all under 62443-4-2, and that is found only in the vendor’s evidence, not in the sales datasheet.

The gap is target minus achieved, per foundational requirement. Seven subtractions, and each can be red while the minimum before the braces stays green.

Where the target comes from

The target is not chosen, it is assessed. IEC 62443-3-2 first requires partitioning into zones with a shared protection need and conduits as the only permitted paths between them. Then, per zone, the worst plausible impact per damage dimension and the risk the organisation is prepared to carry. From that follows the proposal for the target vector, which the threat scenarios confirm or shift. Only approval writes it into the zone.

That is exactly how the OT security module in isidaten runs the assessment, in five steps with approval as a permission of its own. Without an assessment the target stays empty, and the cockpit counts the zone as "without target SL". An empty field is more honest here than a guessed 2.

No second inventory

Most OT tools start with their own asset inventory, and then the controller exists twice. The module therefore creates none: every OT device remains an IT system of the existing inventory, with its networks, vulnerabilities and risks, and gains an OT profile with device type, Purdue level, zone, firmware, vendor support, safety relevance and optionally SL-C. If the zone lacks an achieved level, the module takes the minimum of the device capabilities. If both are missing, there is no gap, only a notice.

Why the controller was on no list

A detail that surfaced while building: IT systems carry no firmware version. Advisory matching against the vendors’ CSAF documents therefore came up empty for controllers, not because there were no vulnerabilities, but because the field to check against was missing.

The OT profile now feeds vendor, product and firmware to the matching as candidates. Every hit becomes a patch decision with a deadline by severity. And where the profile requires vendor approval, the rule for machines under warranty, neither a change nor a rollout target is created without it. Compensation or acceptance with a justification remain; a silent patch does not.

The question to ask

Which zone of your production has an approved target level, and for which of the seven foundational requirements do you know the achieved one?

If the answer is a single number, it is the answer to a different question.

Sources

IEC 62443-3-2: Security risk assessment for system design (zones, conduits, target SL). IEC 62443-3-3: System security requirements and security levels (FR 1 to FR 7, SL 1 to 4). IEC 62443-4-2: Technical security requirements for IACS components (SL-C). BSI IT-Grundschutz, modules IND.1, IND.2.1 and IND.3.2 (2023 edition).