Setting security level targets under IEC 62443

Setting security level targets under IEC 62443 is one of the most important design decisions in an industrial security programme, but it is also one of the easiest to get wrong. If the target is too low, you leave critical process areas exposed to avoidable risk. If it is too high, you can create complexity, cost, and operational friction that the plant will struggle to sustain.

The useful way to approach IEC 62443 is not to start with the standard and work outwards. Start with the operational technology, the process, and the business impact. Then define what level of resistance each zone needs, based on realistic threats and the consequences of failure. That gives you a target security level, often written as SL-T, that can actually be implemented and maintained.

What security level targets are in IEC 62443

In IEC 62443, a security level target describes the level of resistance a zone or system should have against defined threat capabilities. It is a design target, not a statement that the environment is already secure. In practice, it helps you translate risk into engineering requirements.

It is useful to distinguish between the target and the achieved level. The target is what you want a zone or conduit to withstand. The achieved level is what the current design or implementation actually provides. That gap is where remediation work usually sits.

This distinction matters because many teams jump straight to control selection without agreeing the target. That often leads to controls being added because they are familiar, not because they are proportionate. If you have already worked through zone and conduit modelling under IEC 62443, the target-setting step becomes much easier because the boundaries are already defined.

Target setting also gives engineering, operations, and management a common language. Instead of saying a line is “high risk”, you can say the zone needs a higher level of resistance because loss of integrity or availability would stop production, affect safety, or create a wider site impact.

Start with the OT risk context, not the standard

IEC 62443 is a framework for industrial environments, but the right target still depends on your own process. A packaging line, a water treatment plant, and a batch chemical process do not have the same tolerance for disruption. The same is true for a small SME with one production cell versus a multi-site manufacturer with shared engineering services.

Begin by identifying what needs protecting and from whom. In OT environments, the threat is not only external attackers. It can also include accidental change, contractor access, compromised remote support, lateral movement from IT, and misuse of engineering workstations. The target should reflect the most credible threat paths, not just the most dramatic ones.

Then frame the risk in terms of process impact, safety, and availability. Confidentiality still matters, especially for recipes, setpoints, and intellectual property, but in OT the immediate business pain is often loss of control, loss of visibility, or loss of production. A good SL-T should reflect those realities.

If you already use formal risk assessment methods in your ISMS, you can align the OT exercise with that approach. The key is to keep the analysis operationally grounded. A control that looks strong on paper is not useful if it cannot survive shift changes, maintenance windows, or vendor support arrangements. For a broader treatment approach, risk assessment and treatment under ISO 27001 can be used as a useful reference point for structuring the decision process, even though OT implementation has its own constraints.

Understand the four IEC 62443 security levels

IEC 62443 defines four security levels. In simple terms, they describe increasing resistance to increasingly capable attackers.

SL1 is intended to resist casual or accidental violation. That might include basic misuse, opportunistic probing, or simple mistakes. SL2 is aimed at intentional violation using simple means with low resources, such as a basic attacker who understands the environment but is not highly skilled.

SL3 is for more sophisticated attackers with moderate resources and better knowledge of the target. SL4 is the highest level and is intended to resist highly sophisticated attackers with extensive resources and strong motivation.

In practice, most SME OT environments will not need every zone at the top end. That does not mean the environment is weak. It means the target should be proportionate to the exposure and consequence. A small engineering support zone may only need a modest target, while a safety-related or production-critical zone may justify a higher one.

It is also worth being realistic about what higher levels mean for operations. Higher resistance often implies stronger authentication, tighter remote access, more segmentation, better logging, more rigorous change control, and more disciplined asset management. Those are all sensible controls, but they are not free. The right target is the one you can support consistently.

Build a defensible SL-T for each zone

A defensible SL-T is one you can explain in terms of threat, consequence, and feasibility. The easiest way to build it is to work zone by zone and ask three questions. What is the worst credible outcome if this zone is compromised? How capable would an attacker need to be to cause that outcome? Can the organisation realistically maintain the controls needed to resist that level of threat?

For example, a historian or reporting zone may need a lower target than a zone that directly influences process control. A remote access zone may need stronger resistance than an isolated local maintenance network because the exposure is higher. A safety instrumented system may need a more conservative target than a non-critical monitoring segment because the consequence of compromise is much more serious.

Different zones can and should have different targets. That is one of the main reasons the zone and conduit model exists. It lets you avoid the trap of applying a single security posture to the whole plant. If you need a refresher on the design pattern itself, segmenting OT networks with the Purdue model and IEC 62443 zones is a useful companion article.

When you set the target, be explicit about assumptions. For example, if you assume that a zone is only reachable through a hardened jump host, say so. If you assume vendor access is time-bound and monitored, document that. If the target depends on physical separation or restricted plant-floor access, note that as well. These assumptions are part of the security case.

Use the zone and conduit model to scope targets

SL-T should be applied where exposure and criticality differ. That usually means you set a target for each zone and, where relevant, for the conduits between them. A conduit is the communication path between zones, so it is often where remote access, protocol translation, and trust boundaries become visible.

Do not treat the whole plant as one security domain. That approach tends to produce a single, inflated target that is hard to implement and even harder to sustain. It also hides the real risk differences between assets. A PLC network, an engineering workstation zone, and a business reporting interface do not deserve the same treatment.

For SMEs, the most practical approach is often to start with a small number of meaningful zones. For example, you might separate enterprise IT, OT supervisory systems, engineering workstations, and control networks. Then define the conduits between them, especially where remote support, patching, or data transfer is required.

Once the boundaries are clear, the target-setting exercise becomes more precise. You can decide whether a conduit needs stronger authentication, protocol filtering, one-way transfer, or a tightly controlled remote access pattern. This is where target levels become engineering decisions rather than abstract labels.

Map SL-T to IEC 62443-3-3 system requirements

Security level targets only become useful when they are translated into system requirements. IEC 62443-3-3 is where those system security requirements are typically expressed. The practical job is to turn a target into expectations for identification and authentication, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability.

For example, if a zone needs a higher target, you may need stronger authentication for operators and engineers, tighter role-based access control, better session management, and more robust logging. If the target is driven by availability, you may need resilience measures, rate limiting, fail-safe behaviour, and careful control of remote changes.

Do not assume every requirement must be implemented in the same way across every asset. A PLC, a SCADA server, and a remote access gateway will support different control patterns. The point is to ensure the overall zone design meets the target, not to force identical configuration on every device.

This is also where feasibility matters. Some legacy OT assets cannot support modern authentication or logging features. In those cases, the target may still be valid, but the implementation path may rely on compensating controls such as segmentation, protocol restriction, jump hosts, or monitored maintenance windows. The target should drive the architecture, but the architecture must still fit the plant.

If you are mapping requirements into a broader control set, it can help to align the OT work with your wider governance model. For organisations already using ISO 27001, the OT target-setting exercise can sit alongside risk treatment, asset management, supplier assurance, and change control rather than being treated as a separate island.

Common mistakes when setting SL targets

One common mistake is overshooting the target. Teams sometimes choose a higher level because it sounds safer, but that can lead to unnecessary complexity. More controls mean more configuration, more exceptions, more vendor dependency, and more opportunities for drift. If the organisation cannot operate the controls reliably, the target is not helping.

Another mistake is setting one target for every asset. That usually ignores the real differences between zones. It can also create a false sense of consistency. A site-wide target may look neat in a spreadsheet, but it rarely reflects how industrial systems actually work.

A third mistake is treating the target as a one-time exercise. OT environments change through upgrades, new production lines, remote support arrangements, and supplier changes. If the target is not revisited, it quickly becomes stale.

A final mistake is failing to document the rationale. If you cannot explain why a zone was assigned a particular target, it becomes difficult to defend the design, prioritise remediation, or review the decision later. Good documentation is not bureaucracy. It is part of making the target usable.

A practical method for SMEs to set SL targets

For SMEs, a repeatable workshop process is usually the best starting point. Bring together operations, engineering, IT, and whoever owns risk or governance. Keep the session focused on a small number of zones and the most important conduits. The aim is not to solve every issue in one meeting. The aim is to agree a sensible target and the assumptions behind it.

A practical sequence looks like this:

First, define the zone boundaries and the key assets inside each zone. Second, identify the main threats, including remote access, contractor activity, IT-to-OT pathways, and misuse of engineering tools. Third, assess the likely consequences if the zone is compromised, with emphasis on safety, production, quality, and recovery time. Fourth, decide the minimum resistance needed to make those threats difficult enough to be acceptable.

At that point, translate the target into a short list of implementation expectations. For example, you might require strong authentication for privileged access, network separation between zones, logging of engineering changes, and controlled vendor access. Keep the list specific enough for engineers to work from, but not so prescriptive that it blocks sensible design choices.

It can also help to compare the OT target with your existing security architecture patterns. If you already use identity controls, network segmentation, and central logging elsewhere in the business, you may be able to reuse some of those patterns in the OT environment, with appropriate safeguards for uptime and vendor support.

How to validate and maintain SL targets over time

Once the target is set, validate it against the actual design. Ask whether the current architecture can realistically achieve the target without creating instability. If not, identify the gap and decide whether to reduce exposure, add compensating controls, or revise the target with a documented rationale.

Review the target after significant change. That includes new lines, new remote access methods, major patching programmes, supplier changes, and incidents. A target that made sense before a redesign may no longer be appropriate afterwards.

It is also sensible to align review with engineering and risk management cycles. For example, revisit targets during annual risk reviews, major maintenance windows, or architecture changes. That keeps the OT security model connected to how the site actually operates.

Where possible, test the assumptions behind the target. If the design assumes a conduit is tightly controlled, verify that it really is. If the target assumes privileged access is limited, check the actual account and session behaviour. If the target depends on logging and monitoring, confirm that the logs are being collected and reviewed. This is similar in spirit to the way you would validate other control sets, such as the technical and organisational measures described in technical and organisational measures under GDPR, although the operational context is different.

What good evidence looks like

Good evidence is not a large document pack. It is a clear record of why each target was chosen, what assumptions were made, and how the target maps to the current design. That usually includes a zone inventory, a short threat summary, the consequence assessment, the chosen SL-T, and any gaps or compensating controls.

For engineering teams, the evidence should be detailed enough to support implementation. For assurance teams, it should be clear enough to show that the decision was deliberate and risk-based. For management, it should be concise enough to support prioritisation and investment decisions.

If you keep the evidence structured, it becomes much easier to update. A small change to a conduit or a remote access method can then be assessed against the existing rationale rather than starting again from scratch.

That is the real value of setting security level targets properly. It gives you a practical bridge between OT risk, architecture, and day-to-day operations. Done well, it helps you spend money where it reduces real exposure, rather than where it simply adds complexity.

If you want help turning IEC 62443 target setting into a workable plan for your site, speak to a consultant. We can help you review your zones, define proportionate SL-Ts, and translate them into controls your team can actually operate.

Frequently asked questions

What is the difference between SL-T and SL-A in IEC 62443?

SL-T is the target security level you want a zone or system to achieve, while SL-A is the achieved level based on the current design and implementation. The gap between them shows what still needs to be improved.

How do you decide whether a zone needs SL1, SL2, SL3, or SL4?

Base the decision on the most credible threat capability, the operational consequence of compromise, and how much resistance the organisation can realistically maintain. Higher levels are not automatically better if they create controls that the site cannot operate reliably.

Do all zones need the same security level target?

No. Different zones usually have different exposure, criticality, and recovery needs, so they often justify different targets. A one-size-fits-all target can over-engineer low-risk areas and under-protect critical ones.

Can a target security level be lower than the achieved level?

Yes. That can happen where existing controls exceed the current target. It is still worth checking whether the achieved level is intentional, sustainable, and aligned to the real risk.