IEC 62443 Security Levels: What They Mean and How to Achieve Them

This page is part of the IEC 62443 compliance hub.

Security levels are one of the most important and most misunderstood concepts in IEC 62443. They define the degree of protection a system or component is designed to provide, the threat capability it is designed to resist, and the depth of evidence required to support a credible compliance claim.

Getting security levels right is not a theoretical exercise. The security level you are targeting determines which requirements apply, how deeply you need to test, and what your evidence package needs to contain. Get it wrong and your compliance programme is either under-scoped and vulnerable or over-engineered and unnecessarily expensive.

This guide explains what IEC 62443 security levels mean, how they work at both the system and component level, and how ProtoCrawler generates the empirical evidence needed to support security level claims in OT and industrial environments.

What Are IEC 62443 Security Levels?

Security levels in IEC 62443 are a measurement scale that defines the degree of protection a system, zone or component is designed to provide against cyber attack. They serve two purposes simultaneously.

First, they define a target. A system designer or asset owner specifies a target security level for each zone in their IACS environment based on a risk assessment. That target level determines which security requirements must be met and which controls must be in place.

Second, they define a capability. A component vendor claims a capability security level for their product based on the technical security requirements it meets. That claimed level tells buyers what level of protection the component is capable of providing when correctly deployed.

The gap between target and capability is what compliance programmes are designed to close. Testing generates the empirical evidence that a claimed security level is real rather than aspirational.

---

The Four Security Levels Defined

IEC 62443 defines four security levels, each characterised by the threat actor capability it is designed to resist.

Security Level 1 addresses protection against casual or unintentional violations. The threat at SL 1 is not a deliberate adversary but an accidental or uninformed actor, such as an employee who misconfigures a device or inadvertently introduces malware through removable media. SL 1 represents the minimum baseline security capability for any component or zone in an IACS environment.

Security Level 2 addresses protection against intentional violation using simple means with low resources and generic skills. The threat at SL 2 is a motivated adversary using widely available tools and techniques without specialised knowledge of the target system. SL 2 is the level most commonly required for components and systems deployed in operational critical infrastructure across UK regulated sectors.

Security Level 3 addresses protection against intentional violation using sophisticated means with moderate resources and IACS-specific skills. The threat at SL 3 is a capable, targeted adversary with knowledge of industrial systems and the resources to conduct a sustained attack. SL 3 is relevant for critical national infrastructure environments where the consequences of a successful attack are severe.

Security Level 4 addresses protection against intentional violation using sophisticated means with extended resources, IACS-specific skills and high motivation. The threat at SL 4 is a well-resourced, state-sponsored adversary conducting a targeted attack on a high-value system. Very few commercial components are assessed at SL 4 and it applies only to the most sensitive environments.

---

Target Security Level vs Capability Security Level

IEC 62443 distinguishes between two applications of the security level concept that are often conflated.

A Target Security Level is the level of protection that an asset owner or system designer determines is required for a zone or system, based on a risk assessment. It is a design requirement. The target SL for a zone defines which IEC 62443-3-3 system requirements apply and what depth of control and testing evidence is needed.

A Capability Security Level is the level of protection that a component has been assessed to actually provide. It is a product characteristic. A vendor claims a capability SL for their product based on the Component Requirements in IEC 62443-4-2 that the product meets and the testing evidence that supports those claims.

The relationship between the two is straightforward in principle. Components deployed in a zone must have a capability security level that meets or exceeds the target security level of that zone. In practice, asset owners need to verify capability claims, which means reviewing the testing evidence that vendors provide to support them.

This is why vendor-supplied protocol testing evidence matters to asset owners and system integrators. It is the mechanism by which capability security level claims are verified rather than simply accepted.

---

Security Levels at System vs Component Level

Security levels apply at two distinct levels within the IEC 62443 framework and the requirements they drive are different at each level.

At the system level, security levels are applied to zones defined during the IEC 62443-3-2 risk assessment. Each zone is assigned a target security level based on the criticality of the assets it contains and the consequences of a security failure. The system security requirements in IEC 62443-3-3 then define what controls and evidence are required to achieve that target level across the zone as a whole.

At the component level, security levels are applied to individual devices and software components. IEC 62443-4-2 defines the Component Requirements that a device must meet at each security level. A component’s capability security level is determined by which of these requirements it has been tested against and found to meet.

The connection between the two levels is critical for system design. A zone targeting SL 2 must be composed of components with SL 2 capability. A component with only SL 1 capability cannot be used to meet SL 2 zone requirements without additional compensating controls at the system level.

For a detailed breakdown of how component-level security levels work within IEC 62443-4-2, see the IEC 62443-4-2 guide.

---

How Security Levels Are Determined

For system designers and asset owners, target security levels are determined through the risk assessment process defined in IEC 62443-3-2. The assessment identifies IACS assets, defines zones and conduits, evaluates threats and vulnerabilities, and determines the security level needed to reduce risk to an acceptable level for each zone.

Several factors influence the target security level for a zone. The criticality of the assets it contains and the physical or operational consequences of a compromise are the primary drivers. The connectivity of the zone to other networks, including corporate IT networks and the internet, affects the threat profile. Regulatory requirements and customer contractual obligations may also specify minimum security levels.

In practice, most UK operational technology environments targeting IEC 62443 compliance establish SL 2 as the baseline target for operational zones containing control system assets. Higher criticality zones, particularly those where a security failure could have safety implications, may target SL 3.

For product vendors, the capability security level to target is typically driven by the market they serve. Products sold into UK critical infrastructure sectors need to credibly demonstrate SL 2 capability as a minimum. Products sold into higher criticality applications may need to demonstrate SL 3.

---

What Testing Each Security Level Requires

The security level being claimed directly determines the depth and breadth of testing evidence required. This is one of the most practical consequences of the security level framework and one of the most important considerations when scoping a testing programme.

At SL 1, demonstrating that a component or system handles standard error conditions correctly and meets baseline security requirements is typically sufficient. Basic robustness testing and functional security testing against the applicable Component Requirements satisfies the evidence expectation at this level.

At SL 2, the evidence expectation increases substantially. Systematic testing against a broad range of malformed and unexpected inputs is required. Assessors expect evidence that devices maintain availability and reject malformed inputs under sustained adverse conditions, not just under standard error scenarios. Protocol fuzz testing across the full range of protocol fields and message types is the primary method for generating this evidence.

At SL 3, the evidence expectation extends further. Testing must address sophisticated, multi-step attack scenarios as well as basic robustness. Penetration testing by an independent organisation becomes mandatory under IEC 62443-4-1 SVV-4. The scope of protocol testing must cover not just the primary control protocols but all communication interfaces including management plane protocols.

At SL 4, the testing requirements are the most demanding and typically involve highly specialised assessment activities. Commercial component certification at SL 4 is rare.

For most UK organisations, the transition from SL 1 to SL 2 evidence requirements is the most significant step. It is the point at which systematic protocol fuzz testing becomes essential rather than optional.

---

Common Mistakes with Security Levels

Claiming a security level without adequate evidence is the most common and most consequential mistake. Assessors and certification bodies are increasingly rigorous about the distinction between a security level that has been tested and evidenced and one that has been stated without supporting proof. A compliance programme built on undocumented or untested security level claims will not survive scrutiny.

Applying the same security level to all zones without risk-based differentiation wastes resources and obscures real risk. Not every zone in an IACS environment requires the same level of protection. Applying SL 3 controls to a low-criticality monitoring zone is as problematic as applying SL 1 controls to a high-criticality control zone. The risk assessment process exists precisely to drive differentiated security level targets.

Confusing target security level with achieved security level is a related mistake. A zone or component may be designed to target SL 2 without yet having the testing evidence to support an SL 2 capability claim. The gap between target and demonstrated capability is a compliance gap that needs to be actively managed.

Treating security levels as static once set ignores the dynamic nature of the threat landscape and the IACS environment. As systems evolve, new components are added and threat profiles change, security level targets and the evidence supporting them need to be reviewed and updated.

---

What Evidence Supports a Security Level Claim

A credible security level claim requires evidence across several dimensions that together demonstrate the level of protection is real and sustained.

Risk assessment records documenting how the target security level was determined, including the threat analysis, vulnerability assessment and consequence evaluation that drove the decision.

Testing records demonstrating that components and systems have been tested against the requirements applicable at the claimed security level. For SL 2 and above, this means structured protocol robustness testing records showing the scope of testing, the inputs applied and the device responses observed.

Findings management records showing that vulnerabilities identified during testing were scored, prioritised, remediated and verified. A security level claim is not undermined by the existence of findings. It is undermined by findings that were not addressed or were not documented.

Regression testing records demonstrating that the security level evidence remains valid as the system or component evolves. IEC 62443-4-1 requires that testing is repeated when products change. Asset owners need equivalent assurance that system-level evidence remains current.

Component capability evidence from vendors, showing that components deployed in each zone meet or exceed the zone’s target security level. This is the point at which vendor-supplied protocol testing evidence becomes directly relevant to asset owner compliance.

---

How ProtoCrawler Supports Security Level Compliance

ProtoCrawler is designed to generate the protocol testing evidence that security level compliance requires, calibrated to the security level being claimed.

For SL 2 compliance, ProtoCrawler generates systematic protocol fuzz testing across the full range of protocol fields and message types, producing scored evidence that devices maintain availability and reject malformed inputs under adverse conditions. This addresses the core robustness and input validation requirements at SL 2 directly.

For SL 3 compliance, ProtoCrawler’s test depth and coverage can be extended to address more sophisticated attack scenarios, covering management plane protocols alongside primary control protocols and producing the broader evidence base that SL 3 claims require.

ProtoCrawler’s scoring matrix, developed from years of industrial testing experience, prioritises findings by risk level and maps them to the specific IEC 62443 requirements they address. This makes it straightforward to demonstrate which security level requirements have been tested and what the outcomes were.

Its reusable test configurations support the regression testing obligation that runs through the security level framework. When a component or system changes, ProtoCrawler re-executes the relevant test set and produces a directly comparable output, allowing security level evidence to be maintained efficiently across the product and system lifecycle.

For the full list of industrial protocols supported, see the protocol models page. For a broader view of what a complete IEC 62443 compliance testing programme involves, see the IEC 62443 compliance testing guide.

---

Ready to generate the protocol testing evidence your security level claims require? Book a demo to see how ProtoCrawler supports IEC 62443 security level compliance in OT and industrial environments.

Explore the full IEC 62443 compliance hub for the complete set of guides covering certification, component requirements and protocol security testing.