IEC 62443 is the standard most operators, integrators and regulators point to for securing industrial control systems, and the part that tells you how to assess risk is IEC 62443-3-2. It describes the workflow precisely, from defining the system to getting the asset owner's sign-off, with numbered requirements for each step. What it leaves to you is the judgement: where to draw the zones, how to rate a threat to a PLC that can't authenticate anyone, and what Security Level to aim for.
This guide makes those calls on one system, a drinking water treatment plant, so you can see each step's output rather than just its name. It also covers the problem nearly every brownfield assessment runs into: equipment that can't meet the Security Level you set for it, and how countermeasures on the conduit make up the difference.
The short version: define the system under consideration, including remote access and the paths in from the business network. Run a quick worst-case assessment, then partition the system into zones and conduits, keeping safety systems and remotely connected sites in zones of their own. For every zone that can't tolerate its worst case, identify threats per zone and conduit, rate them, and set a target Security Level (SL-T). Where legacy equipment can't reach that level, put compensating countermeasures on the conduits. Write it all into a cybersecurity requirements specification the asset owner approves.
What IEC 62443-3-2 asks for
IEC 62443-3-2, Security risk assessment for system design, sets out seven zone and conduit requirements (ZCRs). Each one produces something you can hand to the next step, and to an auditor:
| Step | What it does | What it produces |
|---|---|---|
| ZCR 1 | Identify the system under consideration (SuC) | The SuC boundary, its assets and every access point into it |
| ZCR 2 | Initial cybersecurity risk assessment | Worst-case consequences for the SuC as a whole |
| ZCR 3 | Partition into zones and conduits | A zone and conduit diagram, with each asset assigned to a zone |
| ZCR 4 | Compare initial risk with tolerable risk | The zones that need a detailed assessment |
| ZCR 5 | Detailed risk assessment per zone and conduit | Threats, likelihood and impact, SL-T, countermeasures and residual risk |
| ZCR 6 | Document requirements, assumptions and constraints | The cybersecurity requirements specification (CRS) |
| ZCR 7 | Asset owner approval | A signed-off assessment that owns the residual risk |
Two other parts of the series do a lot of the work. IEC 62443-3-3 lists the system security requirements (the SRs, such as SR 1.1 or SR 5.1) under seven foundational requirements, with stricter enhancements at each Security Level. IEC 62443-4-2 does the same for individual components. Step 5 uses both: the SL-T says which SRs a zone needs, and the components' capability says whether it can meet them.
The worked example: a drinking water treatment plant
Our plant treats water for a mid-sized town. A SCADA server polls a dosing PLC over Modbus/TCP and a remote pump station's RTU over DNP3, and operators change setpoints from an HMI. An engineering workstation programs the PLC and the independent safety instrumented system (SIS), which trips chemical dosing on dangerous conditions through a hardwired signal. Process data goes to a plant historian, which replicates one-way to a copy on the business network. The SCADA integrator supports the plant remotely through a VPN and a jump host, and, as in many real plants, the OT servers are joined to the corporate Active Directory.
Water is a good teaching case because the incidents are public. In February 2021, someone used remote access software at the Oldsmar, Florida plant to raise sodium hydroxide dosing more than a hundredfold before an operator reversed it. The federal advisory that followed described plant computers sharing one remote access password. (Officials later suggested the change may have been an employee's mistake, but the setup the advisory described is the risk either way.) In November 2023, an Iran-linked group defaced internet-exposed PLCs at US water utilities, including Aliquippa, Pennsylvania, using the default password. Both attack paths appear below.
Step 1: Define the system under consideration (ZCR 1)
Write down what's in scope, what's outside it, and every way in. For the plant, the SuC is the OT side: the DMZ, the SCADA and engineering hosts, the PLC, the SIS and the pump station RTU. The business network is outside, but the paths from it are not, so the historian replication, the AD trust and the vendor VPN are all listed as access points. Leaving them out is how ransomware on an office laptop ends up shutting a plant: Colonial Pipeline stopped its pipeline in 2021 because it couldn't be sure the infection hadn't crossed into OT, as our post on ransomware threat modeling describes.
A data flow diagram is a good way to record the SuC. Draw each asset, each flow between them, and a trust boundary around each network. Many teams start from the Purdue model's levels, from enterprise IT at levels 4 and 5 down to field devices at level 0, because that's how the plant is already cabled.
Step 2: Run the initial risk assessment (ZCR 2)
The initial assessment is deliberately coarse. Assume an attacker succeeds, and ask how bad the outcome could be. Your process hazard analysis (a HAZOP, if the plant has one) already answers most of this, because it lists what happens when a pump, valve or dosing loop misbehaves. For the plant, the worst cases are:
- Unsafe chemical dosing: chlorine or sodium hydroxide outside safe limits, reaching consumers. A public health consequence.
- Loss of treatment: the plant stops treating water, or keeps running without its safety protection.
- Loss of supply: the pump station stops, and part of the town loses water pressure.
None of these is tolerable for the plant as a whole, which is why the next step splits it up.
Step 3: Partition into zones and conduits (ZCR 3)
A zone is a group of assets that share the same security requirements. A conduit groups the communication channels between two zones, and is where you put controls. IEC 62443-3-2 gives specific partitioning rules, and three of them matter here: keep business assets apart from control assets, put safety-related assets in their own zone, and give devices connected over external networks their own zone. That's why the SIS and the pump station each get a zone, even though the Purdue model would put them at the same level as the dosing PLC.
Two details in the diagram are easy to get wrong. The enterprise network has no SL-T because it's outside the SuC, but its conduits into the DMZ are inside it. And the hardwired trip between the SIS and the PLC isn't a conduit at all. It's a wire that no network attack can reach, which is exactly why it's worth keeping.
Step 4: Compare against tolerable risk (ZCR 4)
The asset owner sets the tolerable risk, normally with the same corporate risk matrix used for safety and business risk. Our plant's rule is that no risk may score above 6 on a 5×5 risk matrix once controls are in place. Re-run the worst cases zone by zone: every zone from the DMZ down can contribute to unsafe dosing or loss of treatment, so all five go through the detailed assessment. On a larger site, this step is where you'd set aside the low-consequence zones, such as a laboratory network, and spend your effort elsewhere.
Step 5: Identify threats per zone and conduit (ZCR 5)
Work through each zone and each conduit and ask what could go wrong there. ATT&CK for ICS gives you the vocabulary for OT techniques, and STRIDE keeps each element's review systematic. Then build an attack tree for each worst case from step 2, so you can see which threats combine. The plant has two trees: change chemical dosing unsafely and stop treatment operations.
The dosing tree has an AND gate worth noticing. Getting in through a shared remote access password isn't enough on its own; the attacker also needs an HMI that accepts any setpoint without limits or confirmation. That's the Oldsmar path, and it means a setpoint limit enforced in the PLC would block it even if the password leaked. Ten threats come out of the two trees:
| Threat | Zone or conduit | Likelihood | Impact | Score |
|---|---|---|---|---|
| R1 Shared remote access password | C2, Z1 | 3 | 5 | 15 |
| R2 No setpoint limits on the HMI | Z2 | 3 | 5 | 15 |
| R3 Unauthenticated Modbus writes | C4, Z3 | 3 | 5 | 15 |
| R4 Ransomware spreads from IT | C1, C3 | 3 | 5 | 15 |
| R5 Shared AD trust into OT | Z1, Z2 | 3 | 4 | 12 |
| R6 Infected vendor laptop | Z2 | 3 | 4 | 12 |
| R7 Malicious PLC logic download | Z2, C4 | 2 | 5 | 10 |
| R8 Internet-exposed HMI | Z2 | 2 | 5 | 10 |
| R9 Malformed packets crash the PLC | Z3 | 2 | 4 | 8 |
| R10 Safety system reprogrammed | C5, Z4 | 1 | 5 | 5 |
These are unmitigated scores, rated as if only the controls you can verify today exist. Write down why each likelihood was chosen. "Modbus/TCP has no authentication, and any host on the control network can reach the PLC" is a reason another engineer can check; a bare "3" isn't.
Step 6: Set a target Security Level for each zone
A Security Level describes the attacker a zone must hold off, not a risk score:
- SL 1: casual or coincidental violation, such as a mistake or stray malware.
- SL 2: intentional violation using simple means, few resources, generic skills and low motivation.
- SL 3: intentional violation using sophisticated means, moderate resources and ICS-specific skills.
- SL 4: the same, with extended resources and high motivation, such as a state programme.
The plant sets SL-T 2 for the DMZ, supervisory control and the pump station: the attackers it realistically faces there are the opportunistic kind behind the 2023 PLC defacements. Basic control and the SIS get SL-T 3, because a compromise there causes physical harm directly, and the 2017 TRITON attack showed that ICS-specific attackers will go after safety systems. That's why R10 matters more than its score of 5 suggests. Its likelihood is low because reprogramming an SIS takes real skill, and that skill is exactly what SL 3 is meant to resist.
Every SL-T comes with a set of SRs from IEC 62443-3-3. For SL 3 in basic control, that includes communication integrity (SR 3.1) and authenticated access to the PLC (SR 1.1 and SR 1.2). The dosing PLC speaks Modbus/TCP, which supports neither, so its capability (SL-C) for those requirements falls well short of the target. That gap is normal in brownfield plants and the standard allows for it, which brings us to countermeasures.
Step 7: Choose countermeasures and re-rate residual risk
For each threat, pick countermeasures, name the SR each one addresses, and re-score. When a component can't meet an SR itself, a compensating countermeasure on the zone boundary or the conduit can cover it. The standard expects you to document each one and explain why it's sufficient.
| Threat | Countermeasure | IEC 62443-3-3 SR | Score before → after |
|---|---|---|---|
| R1 | Named accounts with MFA; vendor access enabled on request for a set window; sessions recorded | SR 1.1, SR 1.13 | 15 → 5 |
| R2 | High and low limits enforced in the PLC, not only the HMI; confirmation and alarm on large changes | SR 2.1 | 15 → 3 |
| R3 | Industrial firewall on C4 lets only the SCADA server talk Modbus to the PLC; PLC write protection; alerts on unexpected writes (compensating for the PLC's SL-C) | SR 5.1, SR 3.1 | 15 → 6 |
| R4 | Only the DMZ talks to both sides; no remote desktop or file sharing from IT to OT; offline, tested backups of OT servers and PLC logic | SR 5.1, SR 7.3 | 15 → 5 |
| R10 | SIS key switch held in run mode, with an alarm whenever it leaves run mode; SIS engineering only from a dedicated, offline-by-default workstation | SR 5.1, SR 3.2 | 5 → 5, accepted |
Look at R2. The PLC-side limit is a cheap change to the dosing logic, and it caps the impact of every path in the dosing tree, including R3 and R7 and paths nobody has thought of yet. That's why R3 can come down to 6 even though Modbus itself stays unauthenticated: an attacker who gets past the firewall can only move dosing within the safe range. R10 doesn't move, because its likelihood was already at the floor. What the countermeasures add is detection: if someone does take the SIS out of run mode, the control room knows within seconds rather than after the next trip test. The process safety lead signs it off as accepted residual risk.
Step 8: Write the requirements and get sign-off (ZCR 6 and 7)
The cybersecurity requirements specification is what an integrator builds to and what you check the finished system against. For each zone and conduit it records the SL-T, the countermeasures and their SRs, and the assumptions the assessment depends on. Typical assumptions for the plant are "the vendor's laptop may be compromised" and "the hardwired trip can't be changed remotely". It also records constraints: the PLC can only be patched in a planned outage, so R9 waits for the spring shutdown.
Then the asset owner approves it. That signature is the point of ZCR 7: residual risk only counts as accepted once someone with the authority to accept it has done so. Re-open the assessment when a zone or conduit changes, when a new vulnerability hits a component in it, or on a schedule. Our guide on when to re-threat model lists the usual triggers.
Where IEC 62443 assessments go wrong
- Purdue levels used as zones. Levels describe where equipment sits; zones group assets by security requirements. A safety system and a pump station 20 km away aren't the same zone just because both are at level 1.
- Remote access left off the diagram. The vendor VPN, the AD trust and the historian replication are the paths real intrusions use. If they aren't conduits, nobody rates them.
- SL-T copied across every zone. A blanket "SL 2 everywhere" skips the question the standard asks: which attacker does this zone have to hold off?
- No plan for the SL-C gap. If the PLC can't meet the SL-T, say so, and show which conduit countermeasure compensates and why that's enough.
- Scores with no reasoning. Every likelihood should say what access, skill and equipment the attack needs.
- No sign-off. An assessment the asset owner never approved leaves the residual risk owned by nobody.
Frequently asked questions
What is the difference between IEC 62443-3-2 and IEC 62443-3-3?
IEC 62443-3-2 is the risk assessment: it partitions the system into zones and conduits and sets a target Security Level for each. IEC 62443-3-3 is the catalogue of system security requirements, grouped under seven foundational requirements, that a zone must meet to reach that Security Level.
What do SL-T, SL-C and SL-A mean?
SL-T is the target Security Level a zone or conduit needs, set by the risk assessment. SL-C is the capability a component or system can reach when properly configured. SL-A is the level actually achieved in the running system. The assessment sets SL-T, product selection compares it with SL-C, and testing confirms SL-A.
Is the Purdue model part of IEC 62443?
No. The Purdue model is a reference architecture for industrial networks that predates IEC 62443. It's a useful starting point for drawing the system, but IEC 62443 zones are defined by shared security requirements, so a single Purdue level often splits into several zones.
Does IEC 62443 prescribe a risk scoring method?
No. IEC 62443-3-2 defines the steps and what each must produce, but it leaves the scoring method to the asset owner. Most organisations use the same likelihood and impact matrix they use for safety and business risk, so cyber risks can be compared with everything else.
Who performs the IEC 62443-3-2 risk assessment?
Usually the asset owner, often with the system integrator doing much of the work on a new project. Either way, the asset owner sets the tolerable risk and approves the result, because they're the one who carries the residual risk.
Running a utility or plant in the EU? Drinking water and waste water are sectors of high criticality under NIS2; see NIS2 and threat modeling. For how zones and conduits map to ThreatTree, see threat modeling for critical infrastructure.