Most OT security programs that stall on IEC 62443 stall at the same spot: somebody has to write a number next to each zone, and nobody is sure what that number should be. 

The usual outcome is one of two bad ones. Either every zone gets SL2 because it feels safe and nobody will argue with it, or the safety system and the plant-wide historian both get SL3 because "critical infrastructure" sounds like it demands it. Both are guesses. Neither survives a budget review, and neither tells your engineers which controls to actually buy. 

This guide is for CISOs, OT security leads and plant architects who need to defend a target security level (SL-T) to their own board and their own auditors. It explains what SL1 to SL4 really measure, walks through the risk-based method the standard prescribes, shows a worked zone-by-zone example, and covers the mistakes we see most often. It also pulls together what has changed recently in the IEC 62443 series and in the EU rules that now lean on it, because those changes affect how much weight your security level decisions carry. 

What IEC 62443 security levels actually measure 

A security level is a statement about the attacker a zone or conduit is built to withstand. It is not a maturity score, a compliance grade, or a measure of how much you spent. 

IEC 62443-3-3 defines four levels, plus a zero for "no special protection required." What separates them is the attacker's means, resources, skills and motivation, not a named adversary. The actor labels you see in vendor tables (hacktivist, nation state) are shorthand for those four variables. 

Two details matter in practice. First, the jump from SL2 to SL3 is the jump from generic attackers to ones who understand industrial protocols and process logic. That is the line where commodity ransomware stops being the whole threat model. Second, SL4 assumes an adversary willing to spend almost any amount to reach a specific target. Very few facilities genuinely face that, and the controls required are expensive to run. 

Target, capability and achieved: three numbers, not one 

The standard separates three ideas that people routinely blur together. 

• SL-T (target): the level a zone or conduit must reach. The asset owner sets it through risk assessment. 

• SL-C (capability): what a component or system can deliver when configured correctly. Suppliers document this. 

• SL-A (achieved): what the deployed zone actually delivers today, after configuration, integration and operations are taken into account. 

The working goal is SL-A at or above SL-T. The gap between those two numbers is your remediation backlog, and a gap caused by an SL-C shortfall (an old controller that cannot authenticate users, say) is a very different problem from one caused by poor configuration. 

A security level is a vector, not a single digit 

This is the part that most introductory articles skip. Each zone's level is really a vector of seven values, one per foundational requirement (FR): 

1. FR1: Identification and authentication control 

2. FR2: Use control 

3. FR3: System integrity 

4. FR4: Data confidentiality 

5. FR5: Restricted data flow 

6. FR6: Timely response to events 

7. FR7: Resource availability 

So a zone can be SL-T = (3, 3, 3, 1, 3, 2, 3). A closed process network with no confidentiality requirement can sit at SL1 for FR4 while needing SL3 for integrity and availability. Writing a single "SL3" on the diagram is a shorthand, and it hides decisions you should be making deliberately. 

What has changed recently in the IEC 62443 series 

The core security level definitions have not moved: IEC 62443-3-3 is still the 2013 edition and 62443-4-2 is still the 2019 edition. What has changed is the regulatory weight behind them and the surrounding documents, especially in Europe. 

What this means for how you set target levels 

• Your SL-T decisions are becoming audit evidence. NIS2 expects risk-based security measures, and the revised 62443-2-1 maps directly to it. A documented, reasoned SL-T per zone is a stronger answer than a blanket "we follow 62443." 

• 3-3 remains the system-level reference, but its regulatory status in the CRA is unclear. European commentators expect the product-side presumption of conformity to come mainly through other harmonized standards, with 62443 as the technical base. Asset owners should keep using 3-3 for zones and conduits regardless (IBF Solutions). 

• Procurement is where this lands first. Write SL-C evidence against IEC 62443-4-2 and a secure development lifecycle against 4-1 into purchase specifications for anything that will sit in a zone with SL-T 2 or higher. 

• Check the dates yourself before relying on them. The CRA standardization timetable was still moving when this was written. The reporting obligations from 11 September 2026 and full application from 11 December 2027 are the fixed points. 

Zones and conduits come first, because the level attaches to them 

You cannot pick a security level for "the plant." The standard assigns a level to each zone and each conduit, so the quality of your zoning decides the quality of every number that follows. 

A zone is a group of assets that share the same security requirements. Teams usually draw the boundaries by physical location, criticality, operational function, or the organization and people with access. A conduit is the grouped communication path between two zones. Each one carries its own SL-T, and the conduit's boundary controls (firewalls, data diodes, protocol gateways) are where much of the restricted data flow requirement gets enforced. 

Three practical rules keep zoning honest: 

• A zone is only as strong as its weakest member. Every asset inside it must collectively meet the zone's level. One unpatched engineering workstation in an SL3 zone makes the zone SL-A lower than SL3, whatever the controllers can do. 

• Zone size is a cost decision. Make a zone too large and the most demanding asset drags the whole group up to its level. Make zones too small and you drown in conduits to document and monitor. Aim for groups with genuinely shared consequence and exposure. 

• Some things deserve their own zone almost always: safety instrumented systems, vendor and third-party remote access, the DMZ between IT and OT, and any segment holding engineering workstations with write access to controllers. 

The Purdue model is a handy starting sketch for where zones fall, but it is not a rule of the standard. Modern plants with cloud connectors, wireless sensors and remote maintenance rarely fit neatly into five levels, and your zone model should follow how the process and the network actually behave. 

One more point that is easy to miss: zones do not need to share a level. The ISA guidance is explicit that standardizing a single level across a whole plant is tempting but not advisable. Going to SL1 everywhere leaves critical zones exposed, and going to SL3 or SL4 everywhere pays a very high price for protection many zones do not need (Automation World). 

How to pick the target security level for each zone 

The method comes from IEC 62443-3-2, and it is simpler than its reputation: describe what could go wrong, rate how bad it is, and let that drive the level. Here is the sequence the standard lays out, with the practical notes that make it usable. 

1. Define the system under consideration. Set the perimeter and list every access point into it, including vendor tunnels, USB paths and cellular modems that someone installed years ago. 

2. Run an initial risk assessment. Assume attacks succeed and ask what the worst realistic consequence would be for each major process area, before any countermeasures. Rate the consequence across safety and environment, operations, financial impact and regulatory exposure. 

3. Partition into zones and conduits. Group assets with shared consequence and exposure, then identify the conduits between groups. 

4. Compare initial risk with tolerable risk. Areas whose worst case is already tolerable need little further analysis. Areas that exceed your tolerance move on to the detailed stage. 

5. Run a detailed risk assessment per zone and conduit. Identify threats, vulnerabilities and existing countermeasures. Estimate likelihood and consequence, derive the unmitigated risk, and set the SL-T. The standard allows the SL-T to be a single value or a vector, then asks you to compare the result against tolerable risk again (ISA). 

6. Document the requirements and get asset owner approval. The SL-T becomes a written requirement that engineers, integrators and suppliers can design against. 

Turning a risk result into SL1, SL2, SL3 or SL4 

The standard does not hand you a universal lookup table, and the mapping differs from one organization to the next. Practitioners do share two guardrails: any zone with a high risk rating should not be left at SL1 or SL2, and a low-risk zone should not be given SL3 or SL4. The scale of the consequence should drive the choice, and the test is whether the controls at that level would bring the risk down to something you can tolerate (Control Engineering). 

When teams ask for something more concrete, we use a two-question grid. First, how bad is the worst realistic outcome if the zone is compromised? Second, who could plausibly attack it and how exposed is it? The grid below is an illustration to calibrate against your own tolerability criteria, not a figure from the standard. 

A worked example 

Take a hypothetical specialty chemicals plant. The zoning and levels below show the reasoning, not a prescription for your site. 

Notice what the table does that a flat "SL3 plant" never could. The warehouse stays cheap, the DMZ gets disciplined, and the safety zone gets the strongest protection exactly where the consequence is worst. 

Sanity checks before you sign off 

• Can the level actually be reached? If a zone's SL-T cannot be met with the equipment inside it, you have three options: replace the component, add compensating controls such as isolation or protocol filtering, or reconsider the target and record why. 

• Does the conduit match the zones it touches? In practice, the boundary controls on a conduit need to support the highest SL-T among the zones they protect. A strong zone behind a weak conduit is not a strong zone. 

• Is the target tied to a date? SL-T is not a one-time decision. Threats, consequences and technology change, so the standard expects you to revisit it periodically and after significant changes to the environment. 

SL1 to SL4 side by side: what each level means in practice 

Most industrial organizations settle on SL2 as the baseline and lift selected high-consequence zones to SL3, while SL4 is rare outside nuclear, defense and certain national infrastructure (Opsio). The table translates each level into what it tends to look like on the ground. 

The decision that matters most is SL2 versus SL3 

SL1 is rarely controversial and SL4 is rarely justified, so the real debate is at the middle. The boundary between them is the question of attacker knowledge. At SL2 you defend against someone using generic tools and general IT skills. At SL3 you defend against someone who understands industrial protocols, your control logic and your process, and who is willing to spend time on it. 

Three questions help settle it: 

• Would a successful attack plausibly cause harm beyond lost production, such as safety, environmental or regulatory consequences? 

• Is there credible reason for a skilled attacker to pick your sector or your site, because of what you make, who you supply or what you control? 

• Does the zone sit on a path an attacker would have to cross to reach something more critical? 

Two yes answers usually point to SL3. A single yes is worth a closer look at which of the seven foundational requirements actually carry the risk, because you may only need SL3 for two or three of them. 

SL1 is not "no security" 

SL1 still means protection against accidental harm, which is the most common cause of OT incidents. A misconfigured laptop, a mistyped setpoint or a contractor plugging into the wrong port is a real threat. If a zone is assigned SL1, the documented separation and access rules still have to exist and still have to be followed. 

Setting the level per foundational requirement 

Once a zone has a headline level, the cheaper and more defensible move is to tune it requirement by requirement. IEC 62443-3-3 groups its roughly fifty system requirements under seven foundational requirements, and assigns each requirement and its enhancements to the levels where they apply. A zone's level is therefore the vector described earlier, not one digit (IEC SyC Smart Energy). 

The table shows the question to ask for each requirement when you decide whether it should sit above or below the zone's headline level. 

There is also a link worth knowing between the standard's parts. Part 3-3 sets requirements for a system, while Part 4-2 sets requirements for individual components, and both are organized around the same seven requirements. A system gets its capability from how conformant components are combined and configured. That is why asking suppliers for a documented component capability level, and not just a general claim of "62443 alignment," shortens your gap analysis considerably (WZ-IT). 

Seven mistakes that undermine a security level decision 

1. One level for the whole site. It is the easiest thing to write down and the hardest to defend. Either you overspend on low-risk areas or you under-protect the zones that matter. 

2. Choosing the level from the headline threat instead of the consequence. Fear of a nation-state attacker produces SL4 everywhere. The standard asks what a compromise of this zone would cost and whether the controls at that level would reduce the risk to tolerable, which usually gives a more modest and more useful answer. 

3. Treating capability as achievement. Buying SL3-capable devices does not make a zone SL3. Configuration, integration, patching and operating discipline all feed SL-A, and a single weak asset can pull the whole zone down. 

4. Drawing zones the way IT draws VLANs. Zones should reflect shared consequence and exposure. A zone defined by which switch a device plugs into rarely matches how an incident would spread. 

5. Forgetting the conduits. Remote access paths, jump hosts and supplier connections are where many real intrusions begin. Give each conduit its own target and make sure it matches the most demanding zone it protects. 

6. Setting it once and filing it. Threats, consequences and technology shift. A target with no review date and no trigger events, such as a new remote access path or a process change, quietly goes stale. 

7. Never connecting the number to procurement and operations. An SL-T that stays in a risk workbook changes nothing. It should appear in purchase specifications, integrator statements of work, and the acceptance tests you run before a zone goes live. 

From target to achieved: closing the gap 

Choosing SL-T is the start of the work. The value comes from measuring SL-A against it and closing the difference in a sequence your budget can survive. 

1. Baseline SL-A per zone and per requirement. Inventory the assets, then assess each zone against the requirements of its target. Record the result as a vector so you can see which of the seven requirements are short. 

2. Separate capability gaps from configuration gaps. A device that cannot authenticate users has a capability problem. A device that can, but has a default password, has a configuration problem. The first needs a design decision and the second needs a work order. 

3. Choose a treatment for each capability gap. Replace the component, wrap it in compensating controls such as isolation, protocol filtering or a monitored gateway, or revisit the target with a recorded justification. Legacy equipment in brownfield plants usually lands in the middle option. 

4. Sequence by risk reduction per unit of effort. Conduits and remote access commonly deliver the biggest gains first, because they reduce exposure for many zones at once. 

5. Validate with testing and evidence. Confirm the controls work as intended and keep the documentation that shows it. For regulated environments this evidence is what auditors and insurers will ask for. 

6. Reassess on a schedule and on triggers. Set a review cycle, and also re-open the target after major changes: new connectivity, a changed process, a significant incident or a shift in the threat picture. 

Who owns which part 

The standard splits responsibility across three roles, and a good SL program names an owner for each. 

• Asset owners run the risk assessment, set the SL-T and sustain the operating program, using Part 2-1 for the security management program and Part 3-2 for the assessment. 

• System integrators design and deliver systems whose capability meets or exceeds the target, and they work under the service provider requirements in Part 2-4. 

• Product suppliers build components under the secure development lifecycle in Part 4-1 and document component capability under Part 4-2. 

Third-party certification is available for suppliers and integrators through accredited bodies and schemes such as ISASecure and the IECEE conformity assessment route It is a useful input to your SL-C evidence, but it never replaces your own assessment of what is achieved in your plant. 

Frequently asked questions about IEC 62443 security levels 

What are the four IEC 62443 security levels? SL1 protects against accidental violations. SL2 protects against intentional violations using simple means and low motivation. SL3 protects against sophisticated attackers with IACS-specific knowledge and moderate resources. SL4 protects against highly motivated attackers with extensive resources. SL0 means no special protection is required. 

What is the difference between SL-T, SL-C and SL-A? SL-T is the level a zone or conduit should reach, set through risk assessment. SL-C is what a component or system can deliver. SL-A is what the deployed zone actually delivers. The goal is SL-A at or above SL-T. 

Which security level do most plants need? Many industrial organizations adopt SL2 as a baseline and raise selected high-consequence zones to SL3. The right answer for your site comes from the zone-level risk assessment, not from a default. 

Can a zone have different levels for different requirements? Yes. A security level is a vector of seven values, one for each foundational requirement, so a zone can be higher on integrity than on confidentiality. 

Is SL4 ever necessary? Occasionally, for zones where compromise could threaten life at scale or national function, such as parts of nuclear, defense and some national infrastructure. For most facilities it is expensive to run and out of proportion to the realistic threat. 

Which IEC 62443 part tells me how to set the target? Part 3-2, security risk assessment and system design, defines the zone and conduit process and the SL-T determination. Part 3-3 defines what each level requires at system level, and Part 4-2 does the same for components. 

Has IEC 62443-3-3 been revised? The 2013 edition remains the current one. Recent activity has focused on amendments to Parts 4-1 and 4-2 for the EU Cyber Resilience Act, and on the 2024 revision of Part 2-1. 

Is IEC 62443 mandatory? The standard is voluntary in itself. Regulators and customers increasingly reference it, and European guidance for NIS2 points to it alongside other frameworks, while the Cyber Resilience Act leans on it for product-side requirements. In practice, expect it to appear in contracts and audits. 

How often should target security levels be reviewed? On a regular cycle that your risk policy sets, and whenever something material changes: new connectivity, a process change, a major incident or a shift in the threat picture. 

Turning security levels into a working OT security program with Shieldworkz 

Setting a defensible target level for every zone is a team effort between operations, engineering and security, and it is easier with a partner who works across all three. Shieldworkz is an end-to-end industrial OT cybersecurity company, covering SCADA, OT and IoT environments with products, services and solutions that fit together rather than a single point tool. 

If you are starting a 62443 program, or inheriting one that stalled at the spreadsheet stage, these are the places a Shieldworkz team can help: 

• Zone and conduit modelling workshops that produce a diagram your plant engineers recognize 

• Risk-based SL-T assessments per zone and per foundational requirement, documented so they stand up in an audit 

• Gap analysis of SL-A against SL-T, including treatment options for legacy equipment 

• Supplier and procurement language tied to component capability evidence 

• Ongoing monitoring and patch management support so achieved levels do not drift 

Ready to put a number next to every zone and be able to defend it? Talk to the Shieldworkz team about a zone and security level assessment for your site.