IEC 62443 Meets Article 21: The Exact Control Mapping OT Teams Miss Before a NIS2 Audit

A NIS2 supervisory audit of an industrial facility typically starts with one question: “Show us your cybersecurity risk-management measures for your OT environment.” For most security teams, the answer is a folder of generic IT policies with the word “OT” appended to the title. That answer fails on the first follow-up.

Article 21 of the NIS2 Directive requires essential and important entities to implement “appropriate and proportionate” measures—but it says nothing about PLCs, SCADA servers, or legacy industrial protocols. That specification gap is exactly where IEC 62443 operates.

IEC 62443, the international standard for industrial automation and control system security, maps cleanly onto Article 21’s ten requirements—but only if you know which part of the standard addresses which clause. Most guidance articles say “IEC 62443 supports NIS2 compliance” and stop there. This guide goes further: it shows the exact sub-series-to-clause mapping, identifies where the frameworks diverge and why, and explains how IEC 62443’s Security Level framework documents the proportionality decision your national competent authority will examine. It also addresses which entities face binding CIR 2024/2690 technical requirements and which face only the Article 21 baseline.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Two Frameworks, One Compliance Objective

NIS2 is the legislative obligation. IEC 62443 is the technical implementation methodology. Understanding both roles prevents the most common mistake in OT compliance: treating them as interchangeable.

Article 21 sets the obligation: essential and important entities must take “appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems.” The directive lists ten requirement categories—Art.21(2)(a) through (j)—but intentionally leaves technical implementation unspecified. That is by design: a water utility faces different threats than a cloud platform, and a prescriptive technical specification would either under-protect some sectors or impose disproportionate burdens on others.

IEC 62443 fills that gap for industrial and operational technology environments. Developed jointly by the International Electrotechnical Commission and the International Society of Automation, the standard was built for OT realities: control systems that cannot absorb patch reboots, PLCs running proprietary protocols without modern authentication, and networks where a latency spike can halt a physical production line.

The four series that make up IEC 62443 map onto stakeholder roles:

• IEC 62443-1.x — Vocabulary, models, and general concepts
• IEC 62443-2.x — Policies and procedures for asset owners and service providers
• IEC 62443-3.x — System-level requirements and risk assessment
• IEC 62443-4.x — Component and product security requirements

ENISA’s Technical Implementation Guidance (June 2025) explicitly lists IEC 62443 alongside ISO 27001 and NIST CSF 2.0 as a recognised framework for implementing NIS2 risk-management measures [7]. That recognition matters: an NCA auditor reviewing your OT security programme can assess it against a documented standard rather than demanding bespoke justification for every control decision.

NIS2 does not mandate IEC 62443 certification. It mandates meeting the Article 21(2) requirements at a level “appropriate and proportionate” to your risk profile. IEC 62443 provides the documented methodology to demonstrate you have done exactly that.

The Complete IEC 62443 to Article 21 Control Map

The table below gives the precise sub-series-to-clause mapping. Where IEC 62443 provides partial coverage, the gap is named explicitly—because those gaps are where supplementary documentation is required before an audit.

Art.21 Clause	IEC 62443 Part(s)	Coverage	Notes
Art.21(1) proportionality	62443-2-1 CSMS + SL-T	Strong	CSMS defines risk-proportionate scope; SL-T documents the proportionality decision per zone
Art.21(2)(a) risk analysis	62443-3-2	Strong	Zone-based risk assessment; SL-T assignment per zone
Art.21(2)(b) incident handling	62443-2-1 §4.3.4.5	Partial	OT incident detection and response; Art.23 notification timelines require a supplementary process
Art.21(2)(c) BCP/DR/crisis	62443-2-1	Partial	CSMS covers BCP concepts; backup schedules, RTOs, and crisis communication need standalone documentation
Art.21(2)(d) supply chain	62443-2-4 + 62443-4-1/4-2	Strong	Integrator security programme + product secure development lifecycle
Art.21(2)(e) secure development	62443-4-1	Strong	Secure product development lifecycle for OT component manufacturers
Art.21(2)(f) effectiveness	62443-2-1 Continuous Improvement	Partial	CSMS audit cycle satisfies intent; formal KPI-based effectiveness methodology is an additional requirement
Art.21(2)(g) hygiene/training	62443-2-1 Personnel Security	Strong	OT-specific security awareness and training requirements
Art.21(2)(h) cryptography	62443-3-3 SR 4.x	Partial	OT encryption standard specified; brownfield legacy protocols require compensating controls documentation
Art.21(2)(i) access control	62443-3-3 FR1/FR2	Strong	Role-based access, least-privilege, and asset management for ICS environments
Art.21(2)(j) MFA	62443-3-3 SR 1.1, SR 1.2, SR 1.7	Strong	MFA for remote OT access documented under SR 1.7 [10]

Three “Partial” items require explicit attention before an audit.

Art.21(2)(c) BCP and DR: IEC 62443-2-1’s CSMS covers business continuity concepts but does not specify backup schedules, recovery time objectives, or crisis communication protocols. These require standalone documentation—aligning with the full manufacturing business continuity requirements Art.21(2)(c) demands.

Art.21(2)(f) effectiveness assessment: The CSMS audit cycle in IEC 62443-2-1 satisfies the spirit of this clause, but an NIS2 audit expects a formal methodology with specific KPIs that can be trended over time. The standard’s review process does not fully specify this.

Art.21(2)(h) cryptography: OT environments commonly run protocols—Modbus, Profibus, DNP3—that predate encryption entirely. IEC 62443-3-3 specifies data confidentiality requirements, but applying them to brownfield installations may be disproportionate. SANS Institute notes that OT encryption offers “a lower return on investment due to differing risk surfaces” compared to IT [11]. Where encryption is not feasible, compensating controls—network isolation, monitoring, physical access restriction—must be documented as the proportionate alternative under Art.21(1).

IEC 62443-2-1: The Audit-Ready CSMS Your NCA Will Expect

The Cybersecurity Management System defined in IEC 62443-2-1 is the structural match for Article 21(1)’s proportionality requirement. It is also the section most OT teams either implement superficially or skip entirely.

Article 21(1) requires measures based on: state-of-the-art standards, implementation costs, the entity’s exposure to risk, the entity’s size, and the likelihood and severity of incidents. IEC 62443-2-1’s CSMS operationalises this through a Plan-Do-Check-Act cycle applied to a formally defined System Under Consideration (SuC).

The CSMS defines ten functional domains [9]:

1. CSMS Governance — formal policies signed by management, scope and roles defined
2. Risk Management — OT-specific risk assessment methodology
3. Asset Management — inventory of all ICS components with criticality classification
4. Security Policies — access control, change management, and maintenance protocols
5. Personnel Security — OT-specific awareness training, vetting, and onboarding/offboarding
6. Access Control — authentication mechanisms and least-privilege implementation
7. Vulnerability Management — vendor advisory monitoring and OT patch-testing procedures
8. Network Security — segmentation, firewall configuration, and zone monitoring
9. Incident Response — OT detection, escalation, forensics, and recovery
10. Continuous Improvement — audits, reassessments, and lessons-learned integration

What makes the CSMS the audit-ready artefact is its scope documentation. The SuC explicitly defines which assets and processes are within the programme, what threats are considered realistic, and—critically—what security level the entity is targeting and why. An NCA conducting a supervisory review can engage with a CSMS immediately: it answers the proportionality question in documentary form.

In practice: if your CSMS scope document states that the combustion control zone in a waste-to-energy plant targets SL-T 2 because the assessed threat actor profile is opportunistic attackers rather than nation-state actors, and the consequence of compromise is process disruption rather than direct physical harm, that is a defensible Article 21(1) proportionality justification. A first-cycle NIS2 supervisory review will accept it.

What does not survive review: a generic IT ISMS rebranded as an OT programme, or a paper policy without zone-level risk assignments. For entities that have completed NIS2 manufacturing compliance groundwork at the governance level, the CSMS provides the OT-specific technical extension those programmes typically lack.

Zone and Conduit Architecture: How Network Segmentation Satisfies Article 21(2)(e)

Article 21(2)(e) requires “security in the acquisition, development and maintenance of network and information systems.” For OT environments, the network architecture is the primary implementation surface for this obligation—and IEC 62443-3-2’s zone and conduit model provides the framework [8].

A security zone is a group of assets with shared security requirements and a common security level target. A conduit is the controlled communication path between zones, with documented rules governing what data can cross and under what conditions.

A Purdue-derived zoning structure covers most NIS2-regulated industrial sites:

Zone	Typical Assets	Minimum SL-T
Enterprise / IT	ERP, historian, business applications	SL-T 1–2
Control (SCADA/DCS)	SCADA servers, engineering workstations	SL-T 2–3
Field / Process	PLCs, sensors, actuators, field instruments	SL-T 2–3
Safety (SIS)	Safety Instrumented Systems	SL-T 3
Industrial DMZ	Historian bridge, remote access jump server	SL-T 2

For entities also subject to CIR 2024/2690—specifically industrial managed service providers and MSSPs operating OT infrastructure for clients—the zone and conduit documentation directly satisfies CIR Annex §6.7 (network security: firewalls, VPN, time-limited access) and §6.8 (network segmentation) [2]. For manufacturing entities subject only to Article 21, the model satisfies Art.21(2)(e) and demonstrates state-of-the-art practice under Art.21(1).

Seven foundational requirements apply within each zone per IEC 62443-3-3 [8]: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. Each maps to a verifiable technical control an NCA would examine in a technical audit.

The industrial DMZ deserves particular attention: it is the conduit for all external vendor access, remote monitoring, and historian data transfer. A poorly documented or misconfigured DMZ is the entry point for the majority of OT incidents. The 2022 KA-SAT attack—where a management network VPN misconfiguration allowed attackers to brick approximately 5,800 Enercon wind turbine remote modems—illustrates what an undocumented conduit leaves exposed. Zone and conduit documentation turns this attack surface into a named, risk-assessed, and monitored boundary.

IEC 62443-2-4 and the Article 21(2)(d) Supplier Gap

Article 21(2)(d) requires entities to address “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” Article 21(3) adds that entities must consider “the vulnerabilities specific to each direct supplier” and their “secure development procedures.”

In an OT environment, the most consequential direct supplier is usually not a cloud vendor: it is the OT system integrator who holds engineering-level access to PLCs and SCADA configuration. That relationship is where IEC 62443-2-4 applies.

IEC 62443-2-4 specifies security programme requirements for IACS service providers. Requiring an integrator to comply with IEC 62443-2-4 documents that:

• The integrator has a formal security programme for OT services delivered to your environment
• Remote access is governed: time-limited sessions, MFA, and session recording per SR 1.7 in IEC 62443-3-3 [10]
• Subcontracting is disclosed and subject to equivalent security requirements
• Vulnerability notification timelines are contractually committed

This structured assessment is precisely what Article 21(2)(d) requires and what most supply chain security programmes for industrial entities currently lack [4][6].

The DEKRA supply chain hierarchy [6] maps the full three-tier structure for OT:

1. Asset owner (your facility) — governed by IEC 62443-2-1 (CSMS)
2. System integrator (deploys and maintains your OT) — governed by IEC 62443-2-4 (security programme requirements)
3. Component manufacturer (builds your PLC/HMI/sensor) — governed by IEC 62443-4-1 (secure development lifecycle) + IEC 62443-4-2 (component security requirements)

Each tier produces documentary evidence for the Art.21(2)(d) and Art.21(3) audit trail. Without this structure, the audit question “demonstrate that you have assessed the security-related aspects of each direct supplier” cannot be answered with specific evidence. With it, you point to your integrator contract, the IEC 62443-2-4 requirements section, and the periodic review cadence—then to component certification records for high-criticality assets.

The Art.21(3) requirement to consider supplier-specific vulnerabilities is satisfied by this structure: the integrator’s IEC 62443-2-4 programme documents which tools, remote access methods, and sub-contractors it uses in your environment. Those specifics are the “vulnerabilities specific to each direct supplier” the directive requires you to consider.

Penalty Exposure: Which Industrial Entities Must Meet CIR 2024/2690 vs Article 21 Alone

Article 21(5) authorised the Commission to issue binding implementing acts specifying technical requirements for particular entity types. The resulting Commission Implementing Regulation (EU) 2024/2690—which entered into force 7 January 2025—sets binding technical requirements for a defined list of entities [2]. Industrial organisations need to know precisely where they sit.

CIR 2024/2690 applies to: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, online marketplace providers, online search engine providers, social networking platforms, and trust service providers [2].

Manufacturing entities, energy operators, water utilities, and most Annex I critical infrastructure entities are not directly subject to CIR 2024/2690. They face Article 21 obligations with the “appropriate and proportionate” standard as the compliance threshold.

There is a significant overlap category: industrial managed service providers and OT-specialist MSSPs—entities whose core business is managing third-party OT environments as a service. These entities appear in CIR scope as managed service providers and simultaneously operate physical OT infrastructure for clients. They ARE subject to CIR 2024/2690 and must satisfy its Annex requirements, including:

• CIR Annex §5: supply chain security policy with a maintained supplier directory and contractual security clauses
• CIR Annex §6.7: network security—firewalls, VPN, time-limited connection access [2]
• CIR Annex §6.8: network segmentation [2]
• CIR Annex §6.9: malware detection and prevention [3]

For industrial MSPs in CIR scope: IEC 62443 zone and conduit architecture directly satisfies CIR §6.7 and §6.8. Requiring IEC 62443-2-4 from OT sub-contractors satisfies CIR §5. The frameworks are complementary, not duplicative.

Practical test: if your organisation is engaged by third parties to manage their OT infrastructure as a service, you are in CIR scope. If your OT infrastructure is operated by your own staff for your own operations, Article 21 alone applies—with IEC 62443 as the appropriate implementation framework.

The penalty for non-compliance with Article 21 reaches €10M or 2% of global annual turnover for essential entities, and €7M or 1.4% for important entities, whichever is higher, under Article 34(4) and Article 34(5) of the directive [1].

Matching Security Levels to NIS2 Entity Classification

Article 21(1) requires measures proportionate to “the likelihood and severity of incidents, including their societal and economic impact.” IEC 62443’s security level framework operationalises this judgment zone by zone.

The four security levels [8]:

• SL 1: Protection against casual or coincidental violation
• SL 2: Protection against intentional attack using simple means and low resources
• SL 3: Protection against intentional attack using sophisticated means and moderate resources
• SL 4: Protection against intentional attack using sophisticated means and extended resources (state-level actors)

NIS2 Classification	Zone	SL-T Recommendation	Rationale
Essential entity	Safety Instrumented Systems	SL-T 3	Physical harm consequence; sophisticated threat actors realistic in critical sectors
Essential entity	Primary SCADA / control	SL-T 2–3	Process disruption carries significant societal impact; SL-T 3 for cross-border critical infrastructure
Essential entity	Engineering workstations	SL-T 2	High-value target connected to both control and enterprise networks
Important entity	SCADA / control	SL-T 2	Intentional attack with simple means is realistic; limited societal impact
Important entity	Field instruments	SL-T 1–2	Physical access typically required for attack; lower network exposure

SL-T and SL-A serve different purposes. SL-T is the target you justify: document which threat actors are realistic for this zone, what the consequence of compromise would be, and why this level represents “appropriate and proportionate” measures under Art.21(1). SL-A is what you have achieved: assessed against your current controls. If SL-A falls below SL-T, document the gap and a remediation roadmap. The gap is not a compliance failure—an undocumented gap is.

For entities uncertain whether they are essential or important, the essential vs important classification determines both supervisory intensity and the applicable penalty tier—and should precede SL-T assignment.

Brownfield OT assets that achieve only SL-A 1 today are not an automatic compliance failure, provided the CSMS scope document acknowledges the gap, names compensating controls—physical access restriction, network isolation from enterprise zones, continuous monitoring—and includes a remediation roadmap with realistic timelines. That documented package is the Art.21(1) proportionality case.

Frequently Asked Questions

Does NIS2 require IEC 62443 certification?

No. Article 21 does not name IEC 62443 or require certification against it. It mandates “appropriate and proportionate” measures addressing the ten Art.21(2) categories. IEC 62443 certification—particularly IEC 62443-2-1 CSMS certification and IEC 62443-4-2 component certification—demonstrates a recognised methodology was applied, which strengthens audit defensibility. ENISA’s Technical Implementation Guidance (June 2025) lists IEC 62443 as a suitable framework [7], but it is not the only path to compliance.

Can a manufacturing entity use ISO 27001 alone for NIS2 OT compliance?

ISO 27001 covers the IT security management system but lacks OT-specific mechanisms: no zone and conduit model, no Security Level framework, no provisions for legacy ICS components. An ISO 27001 ISMS extended to OT scope can satisfy NIS2 at the governance and policy level. Technical controls for field-level assets—access control to PLCs, network segmentation between control and enterprise zones, vendor remote access governance—typically require IEC 62443-3-3 and IEC 62443-2-4 alongside it. The recommended approach for mixed IT/OT environments is ISO 27001 for the ISMS foundation plus IEC 62443 for OT-specific controls.

What does CIR 2024/2690 mean for industrial managed service providers?

Industrial MSPs operating OT environments for clients fall under CIR 2024/2690 as managed service providers and must satisfy its 13 Annex sections as binding technical requirements. CIR §5 (supply chain security) and §6.7/6.8 (network security and segmentation) are directly satisfied by requiring IEC 62443-2-4 from OT sub-contractors and deploying zone and conduit architecture in client environments [2][3]. The CIR also adds §6.9 malware detection requirements that apply to the managed environments.

How do I document proportionality under Article 21(1) for OT?

Document three artefacts: (1) the System Under Consideration—which assets and processes are in scope; (2) the SL-T for each zone with written justification identifying the realistic threat actor profile and consequence of zone compromise; and (3) the gap between SL-T and SL-A (achieved) with a remediation roadmap. This three-part package is what NCA supervisory reviews and third-party audits examine first. Without zone-level SL documentation, “proportionate measures” is an unsubstantiated claim.

What is the minimum security level for NIS2 essential entities?

IEC 62443 does not set absolute minimums for NIS2 compliance—SL-T assignment is based on your own risk assessment per IEC 62443-3-2. In practice, essential entities in critical sectors should target a minimum of SL-T 2 for all controlled zones, with SL-T 3 for safety instrumented systems and zones where physical harm or large-scale societal impact is a realistic consequence of compromise. SL-T 1 is generally not proportionate for any zone in an entity classified as essential under NIS2. For the NIS2 manufacturing checklist mapped to Article 21 controls, see our sector-specific guide.

Sources

[1] “Article 21 — Cybersecurity Risk-Management Measures” — NIS2 Directive (EU) 2022/2555, nis2resources.eu [linked inline]

[2] “Commission Implementing Regulation (EU) 2024/2690” — EUR-Lex (Official Journal of the EU)

[3] “CIR 2024/2690 — NIS2 Technical Measures” — nisd2.eu

[4] “Achieving NIS2 Compliance via the IEC 62443 Framework” — Shieldworkz

[5] “Leverage IEC 62443 for EU NIS2 Directive Compliance” — DNV

[6] “NIS2 and IEC 62443” — DEKRA

[7] “NIS2 Technical Implementation Guidance” — ENISA (June 2025) [linked inline]

[8] “IEC 62443 Explained for Industrial and Energy Operators” — Wirtek

[9] “IEC 62443-2-1 Requirements Checklist” — SCADAprotocols

[10] “How to Achieve NIS2 Compliance for OT Remote Access” — HMS Networks

[11] “NIS2 Compliance for OT: Strategic Implementation of ICS Controls” — SANS Institute