IEC 62443: which part applies to you

Four groups, three audiences

The ISA99 committee, whose work the IEC publishes as the 62443 series, organises it into four categories: General, Policies and Procedures, System and Component. The categories are not difficulty levels. They correspond to who is responsible for what.

If you are the asset owner

ANSI/ISA-62443-2-1 sets out the security programme requirements for the organisation that operates the industrial automation and control system. It is the closest thing in the series to an ISO/IEC 27001 for a plant: governance, roles, risk management, incident response, patch handling and the operating disciplines behind them. 62443-2-5 is the implementation guidance that sits alongside it.

The asset owner also owns the decision that everything else hangs from, even when an integrator does the work: partitioning the system into zones and conduits and setting the target security level for each. That is 62443-3-2, and it is the part most operators should read first.

Zones, conduits and target security levels

IEC 62443-3-2:2020 “Security risk assessment for system design” establishes requirements for defining a system under consideration, “partitioning the SUC into zones and conduits”, “assessing risk for each zone and conduit”, “establishing the target security level (SL-T) for each zone and conduit”, and “documenting the security requirements”.

A zone is a grouping of assets that share security requirements. A conduit is the communication path between zones, and it is a first-class object with its own risk assessment and its own target level. That framing is more useful than a Purdue diagram for two reasons. It forces you to name the paths, including the vendor tunnel and the maintenance laptop, and it lets two zones at the same Purdue level carry different requirements because their consequences differ.

The target security level, SL-T, is what the zone needs. The complementary idea in the system and component parts is the capability security level, SL-C: what a control system or a component can actually deliver. IEC 62443-3-3 defines system requirements against control system capability levels, SL-C(control system), and describes how stakeholders derive SL-T(control system) for specific assets using defined zones and conduits. Where SL-T exceeds SL-C, the gap is closed by compensating controls in the architecture, which is exactly the conversation an assessment should be feeding.

If you integrate or maintain

ANSI/ISA-62443-2-4 specifies security programme requirements for IACS service providers: the integrators, maintainers and managed-service firms that build and support the system. It covers how the provider works, from staffing and change control to how they connect remotely and what they leave behind after a commissioning visit.

For an operator, 2-4 is the most useful procurement lever in the series. It converts “are you secure?” into a set of answerable questions about the provider’s own practices, and it applies whether or not the products they install are certified. It also pairs naturally with the NIS2 supply-chain measure, which requires entities to take into account the cybersecurity practices of their direct suppliers and service providers, including their secure development procedures.

If you build the products

ANSI/ISA-62443-4-1 covers the secure product development lifecycle: threat modelling, secure design, implementation practices, verification and the handling of vulnerabilities after release. IEC 62443-4-2 is the technical counterpart, providing “detailed technical control system component requirements (CRs) associated with the seven foundational requirements (FRs)” and defining component capability levels, SL-C(component).

The seven foundational requirements

Everything technical in the series maps back to seven headings, and the order tells you something about the discipline.

• FR 1 – Identification and authentication control (IAC). Knowing who or what is talking. Below the demilitarised zone this is frequently unachievable at the device level.
• FR 2 – Use control (UC). Enforcing what an authenticated party is allowed to do, including on engineering functions.
• FR 3 – System integrity (SI). That the logic, firmware and configuration are what they are supposed to be.
• FR 4 – Data confidentiality (DC). Fourth of seven, and rarely the reason anyone commissions an assessment.
• FR 5 – Restricted data flow (RDF). Zones and conduits, enforced rather than drawn.
• FR 6 – Timely response to events (TRE). Detection and the ability to act on it while it still matters.
• FR 7 – Resource availability (RA). Availability as a first-class security requirement, not a competing concern.

An IT reader should stop at FR 4 and FR 7. In the classic confidentiality, integrity and availability ordering, availability is the afterthought. Here it is a foundational requirement of the same standing as the others, and confidentiality sits below system integrity. That single reordering explains most of the friction between IT security teams and control engineers.

How a security assessment feeds the standard

A well-scoped OT assessment produces exactly the inputs that 62443-3-2 asks for, which is a good reason to commission the assessment before the compliance project rather than after it.

Related documents worth knowing

ISA-TR84.00.09, Cybersecurity Related to the Functional Safety Lifecycle, is the bridge between the security and safety worlds. NIST summarises it as guidance “for integrating the cybersecurity life cycle with the safety life cycle as they relate to Safety Controls, Alarms, and Interlocks (SCAI), inclusive of safety instrumented systems (SISs)”. If your rules of engagement exclude the safety instrumented system from network testing, which they should, this is where the alternative treatment lives.

Cyber-Informed Engineering, developed by the US Department of Energy and Idaho National Laboratory, comes at the problem from the other end. NIST describes Consequence-driven Cyber-Informed Engineering as “a rigorous process for applying CIE’s core principles to a specific organization, facility, or mission by identifying their most critical functions and methods, as well as the means by which an adversary would likely use to manipulate or compromise them”, with an emphasis on “engineering out” risk rather than adding controls on top of it. For a plant that cannot be taken down for testing, engineering the consequence away is often the better investment.

A reading order that works

• Read 62443-3-2 first, even if an integrator will do the work. It is short and it defines the vocabulary everyone else will use.
• Draw the zones and conduits from an observed inventory, not from the drawing you already have.
• Set SL-T per zone from process consequence, and be prepared to justify a low level where the consequence is genuinely low.
• Then pick up your role’s programme part: 2-1 for asset owners, 2-4 for service providers, 4-1 and 4-2 for product suppliers.
• Use 62443-2-4 as procurement language with integrators, and CRA support-period expectations as procurement language with manufacturers.

For what an assessment can safely produce on a running plant, see what can safely be tested on a live OT network. For the legal obligation that usually funds the work, see NIS2 and OT security testing. The Purdue rack on the home page shows how the levels and the methods line up.