The CISO Guide to IEC 62443 Compliance in 2026

Most CISOs meet IEC 62443 the same way: a customer questionnaire arrives asking whether your plants are "62443 compliant," and the honest answer turns out to be complicated. There is no single certificate that makes an organization compliant with IEC 62443. The standard is a series, not a checkbox, and it splits its requirements across three very different roles. Understanding that split is the difference between a program that survives an audit and one that produces a binder nobody trusts.

This guide covers what the series actually asks of an asset owner, where compliance programs consistently break down, and what changed in the regulatory landscape heading into 2026.

The Series, Not the Standard

IEC 62443 is organized into four groups, and the numbering tells you who each part is written for.

The 62443-1-x parts are general: terminology, concepts, and models. The 62443-2-x parts cover policies and procedures, and they are aimed squarely at asset owners. The 62443-3-x parts describe system level design and requirements. The 62443-4-x parts govern products, and they are written for suppliers.

For a CISO at an operating company, four parts carry most of the weight:

• 62443-2-1 defines the security program requirements for an IACS asset owner, the governance layer that everything else hangs from.
• 62443-2-4 specifies requirements for IACS service providers, which is the part you cite when you assess integrators and maintenance vendors.
• 62443-3-2 covers security risk assessment for system design, and it is where zones and conduits are defined.
• 62443-3-3 lists the system security requirements and security levels.

The 4-1 and 4-2 parts, secure development lifecycle and component requirements, belong to your vendors. You do not implement them. You procure against them, which is a meaningfully different exercise and one that belongs in contract language rather than in your control matrix.

Zones and Conduits Are the Real Work

Part 3-2 is the piece most programs underestimate. It asks you to partition the system under consideration into zones, groupings of assets that share security requirements, and conduits, the communication paths between them. Then it asks you to perform a detailed risk assessment per zone and assign each one a target security level.

The exercise sounds like a diagramming task. It is not. It fails for a reason that has nothing to do with the standard: you cannot partition assets you cannot see. Nearly every OT environment contains devices that never appear in the CMDB. Contractor laptops on the process VLAN. A cellular gateway an integrator installed for remote support in 2019. Historian replication that crosses a zone boundary nobody documented. A serial to Ethernet converter bridging a segment that the network diagram shows as isolated.

If your zone model is built from drawings rather than observed traffic, the assessment inherits every error in those drawings. The first real deliverable of a 62443 program is not a policy. It is an inventory grounded in what devices actually do on the wire, including the flows that cross your assumed boundaries.

Security Levels: Target, Capability, Achieved

Part 3-3 defines security levels from SL 0 through SL 4, scaled by the sophistication of the adversary you intend to withstand. SL 1 covers casual or coincidental violation. SL 2 covers intentional violation using simple means and low resources. SL 3 adds sophisticated means and moderate resources with IACS specific skills. SL 4 assumes extended resources and a determined adversary.

Three variants matter, and mixing them up is the most common technical error in these programs:

• SL-T is the target level you assign to a zone based on risk.
• SL-C is the capability level a component or system can provide.
• SL-A is the level actually achieved once everything is deployed and configured.

The gap between SL-C and SL-A is where programs quietly fail. A PLC certified to SL-C 2 delivers SL-A 0 if the security features shipped disabled, the default credentials were never rotated, or the engineering workstation that programs it sits in a zone with weaker controls. Certification travels with the product. Achieved security travels with your configuration.

The other frequent mistake is assigning SL-T 2 uniformly across every zone because it feels like a defensible middle. A safety instrumented system and a break room badge reader do not carry the same consequence profile. Uniform targets are a signal to an assessor that the risk assessment was performed backwards, starting from the desired answer.

The Seven Foundational Requirements

Everything in 3-3 rolls up to seven foundational requirements: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability.

The first four map reasonably well onto controls an IT security team already runs, with the usual OT caveats around legacy protocols that were never designed to authenticate anything. Modbus, DNP3 in its base form, and most fieldbus protocols carry no authentication whatsoever. You do not fix that at the protocol layer. You compensate at the zone and conduit layer, and you document the compensation.

The last three are where asset owners struggle in assessment, because all three demand continuous evidence rather than a configuration snapshot:

Restricted data flow (FR5) asks you to prove that your zone boundaries hold. A firewall rule set proves intent. It does not prove that traffic is not crossing through a path the firewall never sees, which is exactly what an undocumented wireless bridge or a dual homed workstation creates.

Timely response to events (FR6) asks you to demonstrate that anomalies are detected and acted on within a defined window. An assessor who asks how you would know that an engineering workstation began speaking Modbus function code 90 to a controller it has never addressed is asking an FR6 question. "We would review the logs" is not an answer.

Resource availability (FR7) asks you to show the system degrades gracefully under stress. In OT this includes the failure mode most IT teams never consider: your own security tooling. An active scan that knocks a legacy PLC offline is a self inflicted FR7 finding, which is one reason passive collection is the default starting posture in production process networks.

What Changed Going Into 2026

Three shifts have moved 62443 from a voluntary framework to something with commercial and regulatory teeth.

Part 2-1 was rewritten. The 2024 edition replaced the long standing 2010 version and restructured the security program requirements substantially, aligning them more closely with the maturity and risk language used elsewhere in the series. Programs built against the older edition need a gap review, not a reprint.

NIS2 raised the floor in Europe. The directive brought manufacturing, food production, waste management, and other previously exempt sectors into scope, with incident notification measured in hours and personal liability attached to senior management. NIS2 does not mandate 62443 by name, but it demands risk based technical measures for exactly the environments the series was written for, and 62443 is the most defensible way to show your work.

The Cyber Resilience Act shifted pressure onto suppliers. The CRA places security obligations on products with digital elements sold into the EU, with reporting duties arriving before the full requirements do. For asset owners this changes procurement more than operations: your vendors now have a regulatory reason to produce SBOMs, vulnerability disclosure processes, and 4-1 aligned development evidence. Ask for it in the RFP, while you still have leverage.

Build the Evidence Base First

The sequencing that works is the opposite of the one most programs choose. Policy first feels orderly and produces nothing an assessor can test.

Start instead with observation. Put a passive collection point at the aggregation switches where your process traffic converges, using SPAN or mirror ports so nothing is injected into the control network, and let it run. Full packet inspection on those mirrored segments tells you what each device is, which protocol dialects it speaks, and which peers it actually talks to. Flow telemetry from sFlow or NetFlow adds breadth across the switches you have not tapped, which is useful for finding the conduits nobody drew.

Within weeks that gives you three things the standard needs and spreadsheets cannot supply: a device inventory grounded in behavior rather than recollection, an observed communication matrix that either confirms or demolishes your intended zone model, and a baseline of normal that turns FR6 from an aspiration into a measurable control. Deviation from that baseline is the detection signal. It is also, conveniently, the audit artifact.

Only then does the paperwork become cheap. The zone model reflects reality. The SL-T assignments have a factual basis. The compensating controls address gaps you can point at.

The Practical Path

For an asset owner starting from a customer questionnaire, a workable first year looks like this: establish behavioral visibility across your highest consequence sites, use the observed traffic to draw the real zone and conduit model, run 3-2 risk assessments per zone with differentiated targets, measure SL-A against those targets and record the deltas honestly, then write the 2-1 program documentation around what you have actually built.

Compliance frameworks describe outcomes. IEC 62443 is unusually good at describing OT outcomes specifically, which is why it has outlasted most of its competition. But the series assumes you know what is on your network and how it behaves. In most industrial environments that assumption is the gap, and every finding downstream traces back to it. Close that first and the rest of the program becomes documentation rather than discovery.