Setting security level targets under IEC 62443

Setting security level targets under IEC 62443 is one of the most useful parts of the standard, but it is also one of the easiest to misunderstand. The target is not a badge to collect, and it is not simply a higher number that looks better on paper. It is a practical statement about the level of resistance a system, zone, or conduit should have against a defined threat profile.

For UK SMEs running industrial automation, process control, or other operational technology environments, the value of a well-set target is straightforward. It helps engineering, operations, and security teams make consistent decisions about segmentation, authentication, monitoring, remote access, and supplier access. It also stops security work from drifting into either overengineering or underprotection.

If you have already mapped your environment into zones and conduits, as described in our zone and conduit modelling under IEC 62443 article, then SL targets become the next design question. They tell you what each zone needs to withstand, and they give you a basis for deciding which controls are proportionate.

What security level targets are and why they matter

IEC 62443 uses security levels to express how resilient a system should be against a class of attacker. In practice, a security level target, often written as SL-T, is the desired level of protection for a zone, conduit, or system. It is derived from risk, not from a generic template.

At a practical level, the target should answer questions such as: what kind of attacker are we worried about, how capable are they, what access might they already have, and what would happen if they disrupted this part of the environment? Those answers should then shape the controls you design and the evidence you collect.

It is also important to distinguish the target from the achieved level. The target is what you want the design to meet. The achieved level, sometimes referred to as SL-A or SL-C depending on context, is what the implemented solution actually provides. In other words, the target drives design, while the achieved level is the result of implementation and verification.

This distinction matters because many organisations assume that once a control exists, the job is done. In OT environments, that is rarely true. A firewall rule, jump host, or account policy may exist, but if it is bypassed during maintenance or not supported by a supplier workflow, the effective protection may be lower than expected.

Start with the asset, process, and business context

Before you assign any target, define the system boundary clearly. In OT, that boundary should include the process being protected, the assets that support it, and the dependencies that could affect availability or safety. A PLC, HMI, engineering workstation, historian, remote access path, and supplier support channel may all sit inside the same operational picture even if they are physically separate.

For SMEs, the most useful starting point is usually a focused inventory of critical functions rather than a full enterprise asset register. Ask which functions would cause the most disruption if they failed, were manipulated, or were unavailable for several hours. That may include production lines, batching systems, packaging, environmental controls, or safety-related monitoring.

Availability and safety deserve special attention. In many industrial settings, confidentiality is still relevant, but loss of availability or integrity is often the dominant business risk. A system that is technically secure but impossible to maintain, patch, or recover is not a good outcome. Likewise, a control that introduces unsafe operator behaviour is not acceptable just because it improves a security metric.

This is where a broader risk view helps. If your organisation already uses structured risk treatment, the same thinking should apply here. Our risk assessment and treatment under ISO 27001 guide explains the discipline of turning risk into treatment decisions, and that approach maps well to IEC 62443 target setting.

Use threat modelling to inform the target

SL targets should be informed by threat modelling, even if the exercise is lightweight. You do not need a large workshop to get value. You do need a realistic view of likely threat actors and the paths they could use to reach the system.

For most UK SMEs, the relevant threat actors are usually not highly resourced nation-state groups. More often, the concerns are opportunistic attackers, criminal groups using commodity tooling, disgruntled insiders, compromised supplier accounts, or remote access abuse. In OT, even a low-skill attacker can cause meaningful disruption if the environment is flat, legacy, or poorly monitored.

Map likely attack paths across the environment. Consider how an attacker might move from IT into OT, how remote support is granted, whether engineering workstations can reach multiple zones, and whether removable media or shared credentials create shortcuts. If you have already documented trust boundaries, use them here. The point is to identify where the system is exposed and which paths need to be made harder.

Threat modelling does not need to be abstract. A simple table is often enough: asset, threat actor, entry path, likely impact, and candidate controls. If you want a more structured approach to modelling, our threat modelling concepts explained for SMEs article is a useful companion, even though it is not OT-specific.

Translate risk into a realistic SL-T

Once you understand the context and threats, translate that into a target that is defensible and achievable. The key word is achievable. A target that cannot be implemented, maintained, or supported by suppliers will not hold up in practice.

Do not overengineer controls just because the environment feels important. A higher target is not automatically better if it introduces brittle dependencies, excessive downtime for maintenance, or operational workarounds. In OT, the right answer is often a balanced target that reflects the actual exposure of each zone.

Different zones may need different targets. A safety-related control zone, a remote access zone, and a low-risk monitoring segment may not justify the same level of resistance. Similarly, a zone containing legacy equipment with limited authentication support may need compensating controls rather than a target that assumes modern capabilities the equipment does not have.

Think in terms of proportionality. A zone with direct process impact, broad connectivity, and supplier access will usually justify a higher target than a read-only reporting segment. But if the higher target would require replacing equipment that is not yet due for refresh, you may need to phase the improvement and document the interim position.

That is also why SL targets should be set with an understanding of the wider architecture. If you need to revisit how zones are defined before assigning targets, the zone and conduit modelling under IEC 62443 article gives the structural basis for that work.

How SL-T relates to IEC 62443-3-3 requirements

Security level targets are not just labels. They should drive specific system security requirements. IEC 62443-3-3 is the part of the standard that translates security expectations into technical requirements for system design. In practice, the target should help you decide which requirements are needed, where they apply, and how strong the implementation needs to be.

For example, if a zone requires stronger resistance to unauthorised access, that may influence authentication design, account management, session handling, and remote access controls. If the main concern is integrity of control commands, then message protection, network segmentation, and strict conduit rules may matter more than broad endpoint hardening alone.

The useful way to work is from target to requirement to design decision. That chain gives you traceability. It also makes it easier to explain why a control exists, why it is configured in a particular way, and what risk it is intended to reduce.

If you are already applying system requirements in a live environment, our Applying IEC 62443-3-3 system security requirements in practice article goes deeper into how those requirements can be turned into implementation choices and evidence.

Common mistakes when setting SL targets

The first common mistake is treating SL-T as a compliance label. Teams sometimes try to pick the highest level they can justify in a meeting, then discover later that the environment cannot support it. That creates friction, rework, and a false sense of security.

The second mistake is copying a target from another site or another business unit without reassessing the local risk. Two plants may use similar equipment, but their threat exposure, supplier model, maintenance windows, and production criticality can be very different.

A third mistake is setting one target for the whole OT estate. That is usually too blunt. A single target may be acceptable for a small, simple environment, but most organisations have a mix of criticality levels. A packaging line, a utilities segment, and a remote telemetry path may need different treatment.

A fourth mistake is ignoring operational constraints. If maintenance engineers need frequent access, if a vendor insists on a particular remote support method, or if a legacy controller cannot support modern authentication, the target must reflect those realities. Otherwise the organisation will quietly bypass the control later.

A practical method for SMEs to define SL-T

A focused workshop is often the best way to set targets. Keep it small enough to be useful, but include the people who understand the process and the technology. At minimum, bring together operations, engineering, security, and someone who understands supplier support arrangements.

Start with the process flow and the zone map. Identify the critical functions, the most likely threat paths, and the consequences of compromise or outage. Then agree the minimum level of resistance needed for each zone or conduit. Record the reasoning, not just the number.

Useful workshop outputs include a short list of assumptions, the business impact of failure, the threat scenarios considered, the target level for each zone, and any compensating controls needed because of technical constraints. Keep the language practical. If a control is there to reduce remote access abuse, say that directly.

Document review triggers as well. For example, the target should be revisited after a major process change, a new supplier connection, a significant incident, a network redesign, or the introduction of new remote support tooling. That keeps the target current rather than letting it become a stale design note.

Validating whether the target is achievable

Before you finalise the target, test it against reality. Ask whether the required controls can be implemented with the current equipment, whether they will break maintenance workflows, and whether suppliers can support them. This is where many otherwise sensible designs fail.

Technical feasibility matters. Some legacy OT devices cannot support strong authentication, encrypted management channels, or detailed logging. In those cases, you may need to protect the device through segmentation, jump hosts, protocol filtering, or strict administrative procedures rather than relying on the device itself.

Maintenance impact matters too. If the target requires controls that make patching, calibration, or fault-finding unworkable, the environment will drift away from the design. That is why the target should be validated by the people who actually maintain the system, not just by the security team.

Supplier dependency is another practical check. If a vendor needs access for support, make sure the access path, authentication method, logging, and approval process are compatible with the target. If they are not, the target may be technically sound but operationally unrealistic.

It is also worth aligning the target with your wider resilience work. If you are improving visibility and response across the environment, the target should support that direction rather than sit in isolation. Our centralised security visibility explained for SMEs article is a useful reminder that monitoring and architecture should reinforce each other.

How to use SL-T in a wider OT security programme

Once set, SL targets should influence the rest of the OT security programme. They are not a one-off document. They should feed segmentation design, remote access controls, hardening standards, logging priorities, and supplier assurance.

For segmentation, the target helps determine how strict the conduit controls need to be. For hardening, it helps decide which services, ports, and administrative paths should be removed or restricted. For monitoring, it helps prioritise the zones where anomalous behaviour would matter most.

SL targets are also useful for prioritising remediation. If you have a long list of OT improvements, start with the zones where the target is highest and the gap to current state is widest. That gives you a risk-based roadmap rather than a generic backlog.

For organisations that already use ISO 27001 or are building an ISMS, SL targets can also become part of the evidence base for risk treatment and control selection. They do not replace your ISMS, but they can make OT decisions more coherent and easier to explain internally.

In many cases, the best outcome is not a perfect target on day one. It is a clear, documented target that reflects current risk, a realistic implementation plan, and a review cycle that keeps the design honest as the environment changes.

If you are working through this for the first time, or if your OT environment has grown in an ad hoc way, a short advisory session can help you pressure-test the target against operational reality. Speak to a consultant if you would like support shaping an IEC 62443 approach that fits your environment.

Frequently asked questions

What is the difference between SL-T, SL-C, and SL-A?

SL-T is the target security level you want a zone, conduit, or system to achieve. SL-C is the capability or claimed level associated with a component or system design, while SL-A is the achieved level after implementation and verification. In practice, the target drives design and the achieved level shows what was actually delivered.

Can every OT system have the same security level target?

Usually not. Different zones often have different criticality, exposure, supplier dependencies, and maintenance constraints, so the target should vary where the risk differs. A single target may be too blunt for most OT estates unless the environment is very small and uniform.

How do you decide whether a zone needs a higher or lower security level target?

Start with the impact of compromise, the likelihood of attack paths, and the practicality of controls in that zone. Zones with direct process impact, remote access, or broad connectivity usually justify stronger targets than read-only or low-impact segments, provided the controls are supportable.