ISA/IEC 62443 Guide: Zones, Conduits and Security Levels in Practice

Share

Written by Mark Fermor. ISA/IEC 62443 is the international standard series for the security of industrial automation and control systems. This guide is written for asset owners who need to use it, rather than for certification bodies who audit against it.

How the series is structured

62443 is not a single document. It is a series, organised into four groups, and knowing which group you are reading prevents most of the confusion around it.

• General (62443-1-x). Concepts, terminology and models. The vocabulary the rest of the series depends on.
• Policies and procedures (62443-2-x). Requirements for the asset owner's security programme, and for service providers. 62443-2-1 covers the security management system; 62443-2-4 covers requirements for IACS service providers, which is the part to cite in supplier contracts.
• System (62443-3-x). 62443-3-2 covers security risk assessment and system design, and is where zones, conduits and target Security Levels are established. 62443-3-3 defines system security requirements and Security Levels.
• Component (62443-4-x). 62443-4-1 covers the secure product development lifecycle; 62443-4-2 covers technical security requirements for components. These are supplier-facing, and useful for procurement questions.

A crucial structural point: the series divides responsibility between asset owners, system integrators and product suppliers. A vendor claiming their product "is 62443 compliant" is usually referring to 62443-4-1 or 4-2. That is a real and useful claim, but it does not make your installation compliant, because your obligations sit in the 2-x and 3-x documents.

Zones and conduits

The central design idea in 62443 is that you group assets into zones that share security requirements, and you define every permitted communication path between zones as a conduit with its own requirements.

Two properties make this more rigorous than drawing boxes on a network diagram:

• Zones are defined by security requirement, not by geography or subnet. Two devices in the same cabinet may belong in different zones if they carry different consequence. Conversely, a zone may span sites.
• Every conduit is explicit and justified. If a path is not defined as a conduit, it should not exist. That reverses the usual default, in which paths accumulate for legitimate operational reasons and are never revisited.

62443-3-2 sets out the workflow: identify the system under consideration, perform an initial risk assessment, partition into zones and conduits, perform a detailed risk assessment for each, assign a target Security Level, document the requirements, and then design.

Security Levels: what they actually mean

Security Levels in 62443 are defined by the capability of the adversary a zone or conduit is expected to withstand, not by how much technology has been deployed.

• SL 0. No specific requirements.
• SL 1. Protection against casual or coincidental violation.
• SL 2. Protection against intentional violation using simple means, with low resources, generic skills and low motivation.
• SL 3. Protection against intentional violation using sophisticated means, with moderate resources, IACS-specific skills and moderate motivation.
• SL 4. Protection against intentional violation using sophisticated means, with extended resources, IACS-specific skills and high motivation.

The standard also distinguishes SL-T (the target level, set by risk assessment), SL-C (the capability a component or system can provide), and SL-A (the level actually achieved as installed and operated). The gap between SL-C and SL-A is where most real-world risk lives: capable equipment, configured or operated in a way that does not deliver the target.

Setting SL-T at 3 for a zone is a significant commitment. It implies an adversary with industrial control system expertise and moderate resources, which raises questions about remote access, supply chain, firmware provenance and recovery that SL 2 arrangements typically do not answer.

62443 and the Purdue Model

These two are complementary and frequently conflated. The Purdue Enterprise Reference Architecture is a functional reference model that describes where systems sit in layers, from field devices up to enterprise IT. It is not a security standard and it prescribes nothing.

62443 supplies the security constructs Purdue lacks. Purdue tells you a historian sits at Level 3 and an enterprise reporting service at Level 4. Zones and conduits tell you which security domains exist, what may cross between them, in which direction, using which protocol, under whose authority, and to what Security Level. In practice, a Purdue-style level diagram is a useful starting sketch, and zone and conduit definitions are the design artefact you actually operate against.

NIST SP 800-82 Revision 3 is worth reading alongside both. It is guidance rather than a certifiable standard, and it presents a Purdue-style architecture with a demilitarised zone as one example while referencing 62443 zones and conduits.

Where 62443 programmes commonly go wrong

1. Zoning by network topology. Reusing existing VLANs as zones bakes in the architecture you were trying to assess.
2. Undocumented conduits. Engineering laptops, vendor connections, wireless links, cellular modems on skid equipment and cloud telemetry from smart devices are the paths that never appear on the diagram.
3. Assigning target Security Levels uniformly. SL 3 everywhere is not conservative, it is unaffordable and therefore unimplemented.
4. Confusing capability with achievement. Buying SL-C 3 components does not deliver SL-A 3.
5. Ignoring 62443-2-4 in procurement. Integrators and maintainers hold privileged access, and their obligations must be contractual.
6. Treating recovery as out of scope. If a zone is compromised, the question of where the known-good configurations, project files and firmware images live becomes the whole recovery timeline.

Foundational requirements worth reading closely

62443-3-3 organises system requirements under seven foundational requirements: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. For asset owners with an ageing estate, restricted data flow and resource availability tend to drive the most architectural change, because they are the requirements least likely to be satisfiable at the endpoint and most likely to require boundary design.

Where physical controls contribute

Restricted data flow is the requirement family where physical measures deserve explicit consideration. A conduit that is only required occasionally, for maintenance, data extraction or recovery, does not necessarily need to exist as a standing connection. Whether that is appropriate is a safety, availability and process question first, and never a security preference.

Firevault works on two specific questions raised by that analysis. Control by Firevault is a suite of nine purpose-built tools and techniques that give an organisation physical control over the paths into and across its estate, applied through Blueprints that treat a specific risk. Where a conduit is periodic or exceptional, that allows the state of the path itself to be governed and evidenced, alongside rather than instead of firewalling, authentication, protocol restriction and monitoring. Offline Secure Storage® addresses the recovery side, holding known-good configurations, engineering files and project data on storage that is physically disconnected when not in use, so that a recovery copy does not share a reachable failure domain with the zone it may be required to restore.

Neither is a route to a Security Level. Security Levels are achieved by a documented risk assessment, a designed set of zones and conduits, and demonstrable operation.

Frequently asked questions

Can an organisation be certified to 62443?

Certification schemes exist for products, for development processes under 62443-4-1, and for asset owner security programmes under 62443-2-1. There is no single certificate covering an entire operating site.

Is 62443 only for manufacturing?

No. It applies to industrial automation and control systems generally, including utilities, transport, buildings and process industries.

Does 62443 replace the Purdue Model?

They answer different questions. Purdue describes functional layers; 62443 defines security domains, permitted communication and required rigour.

Do we need SL 3?

Only where the risk assessment justifies an adversary with IACS-specific skills and moderate resources. Set target levels per zone, and be prepared to fund what you set.

How Firevault would handle this

A recovery copy an attacker cannot reach

Offline Secure Storage® keeps a clean copy of your data on hardware that is physically disconnected, so backup and recovery do not depend on systems an intruder can touch.