IEC 62443 for Identity People: What It Asks You to Do

IEC 62443 is the international series of standards for securing industrial automation and control systems (IACS). For identity and access people, the parts that matter most are its first two foundational requirements: FR1, identification and authentication control, and FR2, use control. Together they say every human, process and device should be identified, authenticated in proportion to risk, and limited to what it’s authorized to do.

That sounds like IAM. It is, mostly. The difference is that 62443 is written for environments where availability and safety come first, and it’s built to let you meet the intent without breaking the process. This post walks through how the series is structured, what security levels mean, what FR1 and FR2 actually ask for, and how it lines up with NERC CIP if you’re in the electric sector.

How the IEC 62443 series is structured

The series is developed by the ISA99 committee at ISA and published by the IEC, which is why you’ll see it written as ISA/IEC 62443. It’s organized into four groups, each aimed at a different audience:

Group	Audience	Parts identity people should know
1-x General	Everyone	Concepts, terminology and models
2-x Policies and procedures	Asset owners and service providers	2-1: the asset owner’s security program. 2-4: requirements for service providers, such as integrators and maintenance providers
3-x System	Asset owners and system integrators	3-2: security risk assessment and zones and conduits. 3-3: system security requirements and security levels
4-x Component	Product suppliers	4-1: secure product development lifecycle. 4-2: technical security requirements for components

A useful way to read it: 2-1 is how the asset owner runs security, 3-2 is how you carve the system into zones, 3-3 is what each zone’s system must be able to do, and 4-1 and 4-2 are what you should expect from the vendors selling you the parts.

3-2: zones and conduits

3-2 has you group assets into zones that share security requirements, and define conduits, the communication paths between zones. You assess risk per zone and set a target security level for each one. It’s not the same as the Purdue model, though many sites draw their zones along Purdue lines. (I covered the Purdue model through an identity lens separately.)

For identity people, conduits matter as much as zones. A conduit is where you decide who and what may cross, and how they prove it. The remote access path from the enterprise into a control zone is a conduit, and in my view it’s the most important one in the plant.

3-3 and 4-2: the requirements themselves

3-3 lists system requirements (SRs) organized under seven foundational requirements, with requirement enhancements (REs) that kick in at higher security levels. 4-2 mirrors that structure as component requirements (CRs) for individual products. If you’re writing a procurement spec for an HMI or a controller, 4-2 is where you point the vendor.

IEC 62443 security levels SL1–SL4

Security levels describe how capable an attacker the system is meant to resist:

Level	Protects against
SL1	Casual or coincidental violation, like an operator mistake
SL2	Intentional violation using simple means, low resources, generic skills and low motivation
SL3	Intentional violation using sophisticated means, moderate resources, IACS-specific skills and moderate motivation
SL4	Intentional violation using sophisticated means, extended resources, IACS-specific skills and high motivation

You’ll also see three flavors: SL-T (target, what the zone needs based on risk), SL-C (capability, what a system or component can deliver when properly configured), and SL-A (achieved, what’s actually in place). Most of the real work in an assessment lives in the gap between SL-T and SL-A.

Security levels are set per foundational requirement, not as one number for the whole zone. A zone can need SL3 for identification and authentication and SL2 for data confidentiality. That’s a feature: it lets you put identity rigor where the risk actually is.

Where it tends to go wrong: The common overshoot is setting SL3 or SL4 across every zone because it sounds responsible, then discovering the installed systems deliver SL1 or SL2 and the gap can’t be funded. The common undershoot is treating the remote access conduit like the rest of the zone, when it’s the path an attacker is most likely to use. My rule of thumb: let the risk assessment set SL-T per zone and per FR, and expect conduits to the outside to need the highest identity targets.

FR1: identification and authentication control

The seven foundational requirements are identification and authentication control (FR1), use control (FR2), system integrity (FR3), data confidentiality (FR4), restricted data flow (FR5), timely response to events (FR6) and resource availability (FR7). Identity people will spend most of their time in the first two.

FR1 asks the system to identify and authenticate everything that tries to access it. In 3-3 it breaks down into system requirements including:

SR	What it asks for
1.1 Human user identification and authentication	Identify and authenticate human users. Enhancements add unique identification, then multifactor authentication for untrusted networks (SL3) and for all networks (SL4)
1.2 Software process and device identification and authentication	Identify and authenticate processes and devices, not just people
1.3 Account management	Support creating, activating, modifying, disabling and removing accounts
1.4 Identifier management	Manage identifiers by user, group, role or interface
1.5 Authenticator management	Initial authenticator content, changing defaults, protecting authenticators
1.6 Wireless access management	Identify and authenticate users on wireless networks
1.7 Strength of password-based authentication	Configurable password strength
1.8 Public key infrastructure certificates	Operate PKI according to accepted practices
1.9 Strength of public key authentication	Validate certificates properly, including revocation
1.10 Authenticator feedback	Obscure authenticator feedback during login
1.11 Unsuccessful login attempts	Limit consecutive failed attempts
1.12 System use notification	Display a use notification before login
1.13 Access via untrusted networks	Monitor and control access from untrusted networks

A few things stand out to me.

Non-human identity is in scope from the start. SR 1.2 puts processes and devices alongside humans. That covers the service accounts, OPC connections and controller-to-server traffic that IT identity programs tend to discover late. On the certificate side, SR 1.8 and 1.9 make PKI part of the identity conversation, and it’s one of the reasons I argue IT and OT PKI should be designed separately.

MFA is tied to security level and network trust. 3-3 doesn’t demand MFA at every console. It asks for it on untrusted networks at SL3 and everywhere at SL4. That aligns with putting strong authentication at the conduit, such as the remote access path, rather than on the HMI.

The standard knows about operational reality. 62443 is built around the idea that security measures shouldn’t compromise the essential functions of the system, and allows compensating countermeasures where a requirement can’t be met directly. Lockout on failed logins is the classic example: on a critical operator station, you may alert instead of locking. That’s not a loophole, it’s the design.

In practice: Take a legacy HMI that supports only one shared local account, so it can’t meet the unique identification SR 1.1 asks for from SL2 up. A reasonable compensating set: no direct remote path into that zone, individually authenticated MFA at the jump host for any remote session, badge-controlled access to the control room, and shift logs that tie the shared account to a named operator. I’d document it against the specific SR, with an owner and a review date.

FR2: use control

FR1 proves who you are. FR2 decides what you can do once you’re in. The system requirements include:

• SR 2.1 Authorization enforcement: enforce authorizations for all users, with enhancements for mapping permissions to roles, supervisor override and dual approval.
• SR 2.2–2.4: use control for wireless, portable and mobile devices, and mobile code.
• SR 2.5 Session lock and SR 2.6 Remote session termination.
• SR 2.7 Concurrent session control.
• SR 2.8–2.11: auditable events, audit storage capacity, response to audit processing failures, and timestamps.
• SR 2.12 Non-repudiation: being able to tie an action to the human who took it.

Read as an identity person, FR2 is least privilege plus accountability. Role-based permissions, session control for remote access, dual approval for high-consequence changes, and audit trails good enough to reconstruct who did what. If you’ve built privileged access management, most of this will feel familiar. A brokered remote access tool with approvals, session recording and the ability to terminate a session maps cleanly onto SR 2.1, 2.6, 2.8 and 2.12.

Non-repudiation is where shared accounts hurt. If the HMI is logged in as “Operator,” the system can’t tell you which operator acted. That’s sometimes operationally necessary, but you then need something else, like shift logs, physical access records or a camera, to close the gap.

How IEC 62443 maps to NERC CIP

If you work with North American electric utilities, NERC CIP is mandatory and auditable, where 62443 is voluntary unless a contract or regulator says otherwise. The two overlap heavily on identity. CIP requirements apply based on whether BES Cyber Systems are rated high, medium or low impact, so check applicability before assuming any of the below applies to a given asset.

NERC CIP standard	Identity-relevant requirements	Closest 62443 match
CIP-004 Personnel and training	An access management program: authorizing electronic and physical access, periodically verifying that access is still appropriate, and revoking access promptly when people leave or change roles	2-1 security program; FR1 account management (SR 1.3); FR2 authorization (SR 2.1)
CIP-005 Electronic security perimeters	Interactive Remote Access through an Intermediate System, encryption to that Intermediate System, MFA for remote sessions, and the ability to see and disable active vendor remote access	3-2 zones and conduits; SR 1.1 MFA for untrusted networks; SR 1.13 access via untrusted networks; SR 2.6 remote session termination
CIP-007 Systems security management	System access control: enforcing authentication, inventorying default and generic accounts, knowing who can use shared accounts, changing default passwords, password parameters, and limiting or alerting on failed attempts	SR 1.3–1.5 account, identifier and authenticator management; SR 1.7 password strength; SR 1.11 unsuccessful login attempts

The pattern is the same in both: an intermediate, authenticated, recorded path for remote access, a clear inventory of accounts including the shared ones, and evidence that access is reviewed and removed. If you’re building one program to satisfy both, I’d design to 62443’s structure and map evidence to CIP, because CIP auditors will want specific evidence on specific timelines.

My advice: If you’re building one program for both, keep one control set and one evidence store, and tag each piece of evidence with the CIP requirement and the 62443 SR it supports. The access review, the remote access log and the shared-account inventory are the same records either way. What usually breaks is timing: CIP has fixed review and revocation windows, so let those set the calendar and have the 62443 assessment read from the same records.

Where to start

IEC 62443 doesn’t ask identity teams to do anything exotic. It asks for unique identification where it’s possible, authentication matched to risk, authorization by role, control over remote sessions, and audit trails that tie actions to people. What makes it different from an IT framework is that it expects you to put those controls where they won’t hurt the process, and to document compensating measures where a system can’t comply.

If I were starting from scratch, I’d do it in this order. Define your zones and conduits under 3-2. Set target security levels for FR1 and FR2 per zone. Lock down the remote access conduit first, with brokered sessions, MFA and recording. Inventory accounts, including the shared and non-human ones. Then use 4-2 in procurement so the next generation of equipment can meet the requirements natively, and zero standing privileges becomes a realistic goal rather than a slide.

More on identity in industrial environments lives in the OT security hub.