Securing Industrial Control Systems with IEC 62443

A processing plant that has done this work looks boring from the network's point of view, and that's the whole point. The historian collects from the control network but never talks back to it. An engineer pushing a recipe change does it from a hardened workstation inside the control zone, not from a laptop that also reads email. The corporate ERP system pulls production totals through a single, inspected path, and nothing on the plant floor accepts a connection that originated on the internet. A PLC running a clarifier or a reflux loop sees only the traffic it was designed to see. When something does go wrong, you know which zone it happened in, and the blast radius stops at that zone's boundary.

That end state is what the ISA/IEC 62443 series of standards is built to produce. It isn't a product you buy. It's a way of cutting the plant into defensible pieces and proving each piece meets a security target you chose on purpose. This post walks the mechanism from the reference model down to the boundary devices, in the order you'd actually build it, and flags the step where most rollouts quietly fail.

Start with the reference model, not the firewall

Before you draw a single rule, you need a map of how a plant is layered. The map almost everyone uses comes from the Purdue model of control, which the U.S. ICS-CERT (now part of CISA) describes in its Defense in Depth recommended practice (September 2016) as the widely accepted SP-99 model from the International Society of Automation. It stacks the plant into levels: field devices and sensors at the bottom (Level 0), the controllers that drive them (Level 1), supervisory HMI and SCADA (Level 2), site operations and the process historian (Level 3), then the corporate IT systems above (Levels 4 and 5).

The reason this matters isn't academic. Each level has a different tolerance for risk and a wildly different tolerance for disruption. NIST spells out the difference plainly in SP 800-82 Revision 2 (May 2015): in a typical IT system, data confidentiality and integrity are the primary concerns, but for an industrial control system, human safety and fault tolerance to prevent loss of life, regulatory compliance, and loss of equipment or product are the primary concerns. Read that twice. The priority order that IT security spent thirty years optimizing is inverted on the plant floor. A patch that reboots a server is a Tuesday in IT. The same reboot on a Level 1 controller mid-batch is a safety event.

So the model gives you two things at once: a shared vocabulary for where an asset lives, and a built-in argument for why the control network can't simply inherit corporate IT's defaults. Get the map right and the rest of the design has somewhere to hang.

Why control networks can't inherit IT defaults

It's worth being concrete about the differences, because the whole architecture follows from them. NIST's guide lays several out side by side. Timing: ICS are generally time-critical, and some require reliable, deterministic responses, while high throughput is usually not essential. Availability: many industrial processes are continuous, unexpected outages are not acceptable, and outages have to be planned and scheduled days or weeks in advance. That single fact rules out a lot of IT habits. As NIST puts it, typical strategies such as rebooting a component are usually not acceptable, because of the impact on availability and reliability.

Then there's age. NIST notes that typical IT components have a lifetime of around 3 to 5 years, while deployed ICS technology often runs 10 to 15 years and sometimes longer. So the controller you're securing may predate the threat you're securing it against, may run a proprietary protocol, and may have no patch path at all. There's a historical reason these gaps exist: many ICS components used to sit in physically secured areas, disconnected from IT networks, running proprietary protocols on specialized hardware. Low-cost IP devices have replaced a lot of that, and NIST is direct that this convergence increases the possibility of cybersecurity vulnerabilities and incidents. You inherited connectivity the original designers never assumed. The standard exists to put the guardrails back.

Cut the plant into zones, then connect them with conduits

The core idea in 62443 is that you group assets that share the same security needs into a zone, and you treat every communication path between zones as a conduit that you define, control, and monitor on purpose. ICS-CERT calls this an emerging industry strategy that uses "zones and conduits" to secure the communication pathways between trusted environments. A zone might be a single clarifier skid, a whole packaging line, the safety instrumented system, or the historian. The grouping is yours to decide, but the discipline is fixed: if two assets sit in different zones, the only way data moves between them is through a named conduit.

How do you decide where the lines go? You run a risk assessment. The relevant part of the standard, ANSI/ISA-62443-3-2 (2020), defines the method: identify the system under consideration, partition it into zones and conduits, assess the risk to each, and assign a target security level that the design has to meet. This is the step that turns a wiring diagram into a security architecture. A zone that contains the burner management system carries different consequences than a zone holding a spare-parts kiosk, and the assessment is where that difference gets written down. It also gives you a paper trail an auditor or an insurer can follow, which matters more every year.

A few rules of thumb hold up well in our work instrumenting plants. Keep the safety instrumented system in its own zone, isolated from the basic process control system, so a compromise of one doesn't walk straight into the other. Don't let a zone span a trust boundary (a single zone that straddles both the historian and a vendor's remote-access jump host is really two zones pretending to be one). Group by consequence, not by convenience: two pumps on the same switch can still belong in different zones if losing one shuts a line and losing the other doesn't. And size zones to how you'd actually contain an incident at 3 a.m., not to how the org chart is drawn.

Set a target security level for each zone

Once the zones exist, each one gets a target. 62443 defines four security levels, and they're framed by the kind of attacker you're defending against, not by a checklist of products. ANSI/ISA-62443-3-3 (2013), the part that covers system security requirements and security levels, lays them out: SL 1 protects against casual or coincidental violation; SL 2 against an intentional attacker using simple means and low resources; SL 3 against one using sophisticated means with moderate resources and control-system-specific knowledge; SL 4 against a determined adversary with extended resources and high motivation.

That framing is more useful than it first looks, because it forces an honest question for each zone: who actually wants to break this, and how hard will they work? A bottling line's data historian probably warrants SL 2. A safety system whose failure could injure operators warrants SL 3, and you design it for an attacker who knows ICS protocols cold. Aiming everything at SL 4 sounds responsible and usually isn't; it loads cost and operational friction onto zones that don't carry the consequence to justify it, and budget that goes to over-hardening a kiosk is budget that didn't harden the safety system. The same standard breaks the target down across seven foundational requirements, so a "security level" is really a vector, not a single dial:

Notice FR 7. Availability is a security requirement here, on equal footing with confidentiality, which is exactly the inversion NIST flagged. A control on FR 4 that encrypts a Modbus link but adds latency the loop can't tolerate has failed FR 7, and on the plant floor that's a worse outcome, not a better one. The security level you assign per requirement is where you encode those trade-offs instead of pretending they don't exist. A zone can sit at SL 3 for restricted data flow and SL 1 for data confidentiality, and writing it that way is more honest than a single number that hides the real design.

Build the boundary: DMZ, firewalls, and one-way paths

With targets set, you build the conduits that enforce them. The single most consequential boundary is between the corporate network and the control network, and NIST's guidance is specific about it. SP 800-82 recommends a demilitarized zone (DMZ) network architecture with firewalls to prevent network traffic from passing directly between the corporate and ICS networks, plus separate authentication mechanisms and credentials for users on each side. No flow goes corporate-to-control without landing in the DMZ first and being inspected.

In practice that means the historian, patch and antivirus servers, and any remote-access jump host live in the DMZ, not on the control network and not on the corporate LAN. Plant data flows up to the DMZ; corporate users read it there. Where the consequence is high enough, you stop relying on a firewall's rules altogether and use a data diode, a one-way gateway that physically can't carry a return packet, so a historian feed can leave the control zone with no possible inbound path. ICS-CERT lists data diodes alongside firewalls and DMZs as standard tools for exactly this job.

Remote access is the conduit that deserves the most paranoia, because it's the one a vendor will ask you to weaken. The pattern that holds: terminate every external session in the DMZ at a jump host, require separate credentials and multi-factor there, allow only the specific protocols the session needs, and log it. A standing VPN straight onto the control network for a vendor's convenience is a conduit you've handed to someone else to secure for you. Don't.

Inside the plant, the conduits between process zones get the same treatment at smaller scale: firewalls with default-deny rulesets, so a conduit carries only the specific protocols and endpoints it was designed for and nothing else. If you segment with VLANs, secure them explicitly. ICS-CERT warns that default and standard network configurations are not inherently secure and that VLAN-hopping exploits can give an adversary a path you didn't intend, so a VLAN tag is a convenience, not a security boundary on its own.

Done right, this is what defense in depth means in an ICS: layered mechanisms so the failure of any one doesn't open the whole plant. ICS-CERT frames the payoff bluntly: applying defense in depth raises the cost of an intrusion while improving both the odds of detecting it and your ability to defend against it. You're not trying to be impenetrable. You're trying to make an attacker spend time and make noise, both of which you can act on.

Where most rollouts go wrong

Here's the step that sinks more programs than any missing firewall: treating the architecture as a one-time project and treating "patched" as a state you reach. Two failure patterns show up again and again.

The first is the flat network that looks segmented on paper. A team draws clean zones, buys the firewalls, and then leaves a forgotten engineering laptop dual-homed across the control and corporate networks, or a contractor's modem hanging off a PLC for "support." The architecture is only as good as its weakest conduit, and an undocumented path is a conduit you didn't secure. Stuxnet, discovered in 2010, made this lesson permanent: it crossed air gaps on infected USB drives and propagated across internal networks to reach Siemens S7 controllers running Step 7, no internet required. An air gap is a control you have to maintain, not a fact about your plant.

The second is assuming you can patch your way to safety. You often can't, at least not on the IT cadence. A Level 1 controller can't reboot mid-process, the vendor may not have validated the patch against your firmware, and the maintenance window might be months out. The standard's own structure expects this: ANSI/ISA-62443-4-2 (2018) sets technical security requirements for the components themselves, and where you can't remediate a known vulnerability, you compensate. That's tighter segmentation around the exposed asset, application allow-listing on the host, narrower access, and more monitoring of the conduit that reaches it. The unpatched PLC doesn't have to be the open door if the path to it is watched and starved.

Both failures share a root cause: the security stopped being a living process. Which brings us to the part of the standard that isn't about boxes at all.

Wrap the technology in a program

62443 is deliberately split between the people running the plant, the system integrators, and the product vendors, because security that depends on a single hero engineer doesn't survive that engineer changing jobs. The series assigns the asset owner a security program (the 2-1 part), holds product suppliers to a secure development lifecycle in ANSI/ISA-62443-4-1 (2018), and sets service-provider requirements in ANSI/ISA-62443-2-4 (2018). The point is that responsibility is shared and explicit: you can't outsource your way to a secure plant, and you can't build one without holding your vendors to a standard. When you buy a new skid, ask the supplier which security level its components were built to and whether they followed 4-1. The answer tells you how much compensating work falls on you.

The threat environment is the reason this can't lapse. ENISA, the EU Agency for Cybersecurity, named ransomware the prime threat of its reporting period in its 2021 threat report (the ninth annual edition, published October 2021), and treated supply-chain compromise as serious enough to warrant a dedicated report. Ransomware that starts in corporate IT will look for any conduit into operations, which is precisely why the DMZ boundary and separate credentials earn their keep. And the threat isn't only opportunistic. The FBI's March 2022 industry notification on the TRITON malware is the clearest warning a process engineer can read: in 2017 an attacker reached the safety instrumented system at a petrochemical facility and installed malware targeting Schneider Electric Triconex safety controllers, work the U.S. government later attributed to a Russian government research institute. The plant tripped to a safe state because the safety logic caught an anomaly, which is the only reason this is a case study and not a casualty report. That's also the clearest argument for keeping the safety system in its own zone: it was the last line that held.

So the program is the part that keeps the architecture honest between audits: reviewing the zone model when the plant changes, re-running the risk assessment when you add a line, watching the conduits, and rehearsing what you do when a zone lights up. This is the kind of continuous instrumentation and monitoring our team builds into deployments, so the security model has live data behind it rather than a binder on a shelf. Detection (FR 6) is only real if someone is actually reading the telemetry and knows what normal looks like on each conduit. And here the inversion that makes ICS security hard also helps you: because control traffic is repetitive and deterministic in a way office traffic never is, a conduit that suddenly carries a new protocol or talks to a new endpoint is a signal you can act on, not noise to wade through. The predictability you have to protect is also the thing that makes anomalies stand out.

A sane order of operations

If you're starting from a plant that grew organically (most have), the sequence matters more than the speed. A staged path that holds up:

1. Inventory first. You can't zone what you can't see. List every controller, HMI, historian, and remote connection, including the undocumented ones. The forgotten modem is usually found here.
2. Map to the Purdue levels. Place each asset on the reference model so the trust boundaries become obvious.
3. Partition into zones and conduits, and run the 62443-3-2 risk assessment to assign a target security level per zone.
4. Build the corporate-to-control boundary first. The DMZ, firewalls, and separate credentials between IT and OT buy the most risk reduction for the least disruption.
5. Harden inside the zones with default-deny conduits, host controls, and compensating controls around assets you can't patch.
6. Stand up monitoring and response so FR 6 is real, then keep the whole thing under a documented program.

None of these steps is exotic. The hard part is doing them in order and not declaring victory after step four. If you want help instrumenting and monitoring the result rather than just drawing it, that's the work we do in our industrial deployment and monitoring services.

The standard won't make your plant unbreakable, and anyone selling that is selling the wrong thing. What it gives you is a plant where an intrusion is bounded, visible, and survivable, where the safety system stays separate from everything trying to reach it, and where you can answer the question every operator eventually faces at the worst possible hour: if this zone is compromised, what exactly can it touch? Build it so the answer is short.