site-logo
site-logo
site-logo
Hero BG

IEC 62443 - Practical guide for OT/ICS & IIoT security  

Table of contents 

What is IEC 62443 - at a glance 

Why IEC 62443 matters for OT, ICS and IIoT  

Structure: the four parts of the 62443 family  

Security Levels & Foundational Requirements - how to think about them 

Who’s in scope (essential vs important entities, the size-cap, cross-border reach) 

Recent and important updates you need to know (2023-2025) 

Who’s in scope (essential vs important entities, the size-cap, cross-border reach) 

Practical roadmap: how to implement 62443  

Who’s in scope (essential vs important entities, the size-cap, cross-border reach) 

Typical pitfalls, misinterpretations & how to avoid them 

Who’s in scope (essential vs important entities, the size-cap, cross-border reach) 

Shieldworkz IEC 62443 service portfolio - mapped to the standard parts 

Who’s in scope (essential vs important entities, the size-cap, cross-border reach) 

Outcomes, commercial value and KPIs  

Who’s in scope (essential vs important entities, the size-cap, cross-border reach) 

Checklist: a tactical “first 90 days” plan for asset owners 

Who’s in scope (essential vs important entities, the size-cap, cross-border reach) 

Next steps - get a free discovery call / demo with Shieldworkz 

Who’s in scope (essential vs important entities, the size-cap, cross-border reach) 

FAQ, short answers to common questions 

Who’s in scope (essential vs important entities, the size-cap, cross-border reach) 

1. What is IEC 62443 - at a glance 

IEC 62443 (often referred to as ISA/IEC 62443) is a modular, lifecycle-focused family of international standards created to secure industrial automation and control systems (IACS). It covers governance (security programs), system-level design (zones & conduits, risk-based SL targets), product/component requirements (secure development), and verification/conformance. Rather than prescribing one single technology, 62443 gives teams a repeatable engineering and management model to reduce operational risk and protect safety, availability and integrity in OT environments. 

OT Security, or operational technology security, is the practice of protecting critical infrastructure and industrial systems from cyber threats. These systems, which include everything from power grids and water treatment facilities to manufacturing plants and transportation networks, are the backbone of modern society. Unlike traditional IT systems, OT systems are designed to control physical processes and often operate in real-time, making them both unique and highly vulnerable to cyberattacks.

2. Why IEC 62443 matters for OT, ICS and IIoT - risk and business drivers 

Industrial environments are not “IT networks with fancy PLCs” - they are safety-critical, long-lived engineering ecosystems with constraints (legacy controllers, deterministic communications, strict uptime and change-control). Attacks on industrial systems produce physical consequences: production loss, environmental damage, regulatory fines and safety incidents. 

Operational resilience: reduce unplanned downtime and protect safety systems. 

Regulatory & customer confidence: many regulators, owners and supply chains expect 62443 alignment. 

Procurement & vendor assurance: reuse a single framework for evaluating OT products & integrators. 

Risk-based investment: 62443 maps risks to specific technical requirements and helps prioritize spend. 

IEC 62443 matters to OT/ICS
Shieldworkz IEC 62443
OT Systems is Critical

3. Structure - the four parts of the 62443 family 

62443 is intentionally modular so different stakeholders can work in parallel. 

Part 1 - General (Concepts & Models) 
Defines terminology, the seven foundational requirements (FRs), and the high-level models used across the series (e.g., zones & conduits). This is where you learn the language of 62443 so teams talk the same way. 

Part 2 - Policies & Procedures (Asset-owner and service provider CSMS) 
Focuses on governance. It prescribes the Cybersecurity Management System (CSMS) for asset owners and the process requirements for service providers. Part 2-1 (asset owner security program) and Part 2-4 (service provider requirements) are cornerstones for programmatic compliance. Recent editions of Part 2 documents have tightened expectations for governance, supply-chain and lifecycle activities.  

Part 3 - System requirements (Risk assessment, zone/conduit design, SL targets) 
Part 3-2 defines how to perform a risk assessment, partition systems into zones/conduits and set target security levels (SL-T) for each zone. Part 3-3 provides detailed system security requirements that map to the seven foundational requirements. 

Part 4 - Component & Product requirements (Secure SDLC & technical controls) 
Part 4-1 defines secure development lifecycle (SDL) practices for product vendors; 4-2 specifies the technical security requirements for components (device/firmware/software). Third-party conformity programs (e.g., ISASecure CSA) provide practical, testable routes to prove a product meets 4-2 requirements. 

OT Systems is Critical

4. Security Levels & Foundational Requirements - how to think about them 

IEC 62443 introduces the concept of Security Levels (SL) which help you translate risk into engineering targets. 

Security Levels (SL 0 → SL 4)

There are five defined SLs (SL-0 through SL-4). Each SL indicates the capability of the adversary the system must defend against - expressed by means, resources, skills and motivation. Practically, SLs act as allocation targets: the higher the SL, the stronger the technical controls required. When used correctly, SL selection is a consequence-and-impact driven decision, not just a “who is the attacker” exercise.

The seven Foundational Requirements (FRs) 
Across parts of the standard, 62443 groups technical controls under seven FRs: 

Identification & Authentication Control 

Use Control (authorization) 

System Integrity 

Data Confidentiality 

Restricted Data Flow (segmentation) 

Timely Response to Events (monitoring & IR) 

Resource Availability (resilience & redundancy) 

These FRs are the building blocks for technical requirements at component and system level. Your target SL dictates how each FR is realized in controls, verification and operational processes. 

OT Systems is Critical

5. Recent and important updates you need to know 

62443 is actively maintained - the committee publishes updates and new editions that change programmatic and technical expectations. A few practical, recent highlights: 

IEC/ISA 62443 designated a “horizontal” standard (Nov 2021): This formal IEC designation widened 62443’s role as a core, technology-independent cybersecurity reference across industries. That decision made 62443 a preferred baseline for many sector-specific standards and regulators.  

Part 2-1 updated in 2024 (IEC 62443-2-1:2024): The asset-owner security program requirements were revised and reissued to better align CSMS expectations with modern supply chain and organizational controls. The 2024 edition is the current baseline for asset owners designing a CSMS. 

Part 2 (service provider) consolidated/updated (2023): IEC 62443-2:2023 consolidates and clarifies security program requirements applicable to service providers - an important update that raises expectations for contractors, integrators and support vendors. 

Product assurance and third-party testing (ISASecure & CSA): Product-level certification pathways such as ISASecure’s Common Security Assessment (CSA) map directly to 4-2 requirements - enabling procurement teams to request certified products and reduce verification cycles.  

What this means for you: Standards are evolving to require stronger governance and vendor assurance. If you implemented 62443 five years ago, you need to re-baseline governance, vendor contracts and product procurement checklists today. 

OT Systems is Critical

6. Practical roadmap - how to implement IEC 62443 

Below is a pragmatic, executable program for asset owners and operators. Each phase has clear deliverables that are useful for procurement and for a third-party partner like Shieldworkz. 

Phase 0 - Executive alignment (0-2 weeks) 
Objective: secure sponsorship, assign roles, define scope. 
Outputs: executive brief, charter, project sponsors, initial risk tolerance statement, prioritized asset list. 

Phase 1 - Discovery & gap assessment (2-6 weeks) 
Objective: baseline maturity vs 62443 (controls, policies, network maps). 
Outputs: asset inventory, network/segment map (logical + physical), control maturity matrix (fast scorecard), prioritized gap register mapped to 62443 parts and SLs. 

Phase 2 - CSMS design & policy (4-8 weeks) 
Objective: build the program that will stay in place for years; map to 62443-2-1. 
Outputs: CSMS blueprint, governance & roles, vendor assurance policy, secure remote access policy, patch management policy (aligned to 62443-2-3 guidance). 

Phase 3 - Risk assessment, zoning & target SL assignment (3-8 weeks) 
Objective: partition your system into zones and conduits and assign SL-T targets. 
Outputs: Zones & conduits diagram, SL-T matrix per zone/conduit, prioritized mitigation roadmap tied to business consequences. 

Note: choose SL targets based on consequences (safety, production, long-lead assets), not just attacker sophistication. 

Phase 4 - Technical design & remediation (variable) 
Objective: implement controls to achieve SL-T (network segmentation, device hardening, authentication, monitoring). 
Outputs: segmentation rules, firewall policies, identity & access implementation, secure configuration baseline for devices, secure network architecture.

Phase 5 - Verification, product assurance & secure SDLC (ongoing) 
Objective: ensure controls meet the technical requirements (3-3 / 4-2) via testing and supplier evidence. 
Outputs: test plans, compliance evidence, vendor product assurance reports (e.g., ISASecure CSA), secure-development evidence from suppliers (4-1).

Phase 6 - Operate, monitor & continually improve (continuous) 
Objective: run the CSMS, monitor for deviations, conduct periodic assessments and re-assign SLs as needed. 
Outputs: continuous monitoring, incident response playbooks, annual CSMS review, supplier re-assessments. 

Shieldworkz IEC 62443
OT Systems is Critical

3. Structure - the four parts of the 62443 family 

62443 is intentionally modular so different stakeholders can work in parallel. 

Part 1 - General (Concepts & Models) 
Defines terminology, the seven foundational requirements (FRs), and the high-level models used across the series (e.g., zones & conduits). This is where you learn the language of 62443 so teams talk the same way. 

Part 2 - Policies & Procedures (Asset-owner and service provider CSMS) 
Focuses on governance. It prescribes the Cybersecurity Management System (CSMS) for asset owners and the process requirements for service providers. Part 2-1 (asset owner security program) and Part 2-4 (service provider requirements) are cornerstones for programmatic compliance. Recent editions of Part 2 documents have tightened expectations for governance, supply-chain and lifecycle activities.  

Part 3 - System requirements (Risk assessment, zone/conduit design, SL targets) 
Part 3-2 defines how to perform a risk assessment, partition systems into zones/conduits and set target security levels (SL-T) for each zone. Part 3-3 provides detailed system security requirements that map to the seven foundational requirements. 

Part 4 - Component & Product requirements (Secure SDLC & technical controls) 
Part 4-1 defines secure development lifecycle (SDL) practices for product vendors; 4-2 specifies the technical security requirements for components (device/firmware/software). Third-party conformity programs (e.g., ISASecure CSA) provide practical, testable routes to prove a product meets 4-2 requirements. 

OT Systems is Critical

4. Security Levels & Foundational Requirements - how to think about them 

IEC 62443 introduces the concept of Security Levels (SL) which help you translate risk into engineering targets. 

Security Levels (SL 0 → SL 4)

There are five defined SLs (SL-0 through SL-4). Each SL indicates the capability of the adversary the system must defend against - expressed by means, resources, skills and motivation. Practically, SLs act as allocation targets: the higher the SL, the stronger the technical controls required. When used correctly, SL selection is a consequence-and-impact driven decision, not just a “who is the attacker” exercise.

The seven Foundational Requirements (FRs) 
Across parts of the standard, 62443 groups technical controls under seven FRs: 

Identification & Authentication Control 

Use Control (authorization) 

System Integrity 

Data Confidentiality 

Restricted Data Flow (segmentation) 

Timely Response to Events (monitoring & IR) 

Resource Availability (resilience & redundancy) 

These FRs are the building blocks for technical requirements at component and system level. Your target SL dictates how each FR is realized in controls, verification and operational processes. 

OT Systems is Critical

5. Recent and important updates you need to know 

62443 is actively maintained - the committee publishes updates and new editions that change programmatic and technical expectations. A few practical, recent highlights: 

IEC/ISA 62443 designated a “horizontal” standard (Nov 2021): This formal IEC designation widened 62443’s role as a core, technology-independent cybersecurity reference across industries. That decision made 62443 a preferred baseline for many sector-specific standards and regulators.  

Part 2-1 updated in 2024 (IEC 62443-2-1:2024): The asset-owner security program requirements were revised and reissued to better align CSMS expectations with modern supply chain and organizational controls. The 2024 edition is the current baseline for asset owners designing a CSMS. 

Part 2 (service provider) consolidated/updated (2023): IEC 62443-2:2023 consolidates and clarifies security program requirements applicable to service providers - an important update that raises expectations for contractors, integrators and support vendors. 

Product assurance and third-party testing (ISASecure & CSA): Product-level certification pathways such as ISASecure’s Common Security Assessment (CSA) map directly to 4-2 requirements - enabling procurement teams to request certified products and reduce verification cycles.  

What this means for you: Standards are evolving to require stronger governance and vendor assurance. If you implemented 62443 five years ago, you need to re-baseline governance, vendor contracts and product procurement checklists today. 

OT Systems is Critical

6. Practical roadmap - how to implement IEC 62443 

Below is a pragmatic, executable program for asset owners and operators. Each phase has clear deliverables that are useful for procurement and for a third-party partner like Shieldworkz. 

Phase 0 - Executive alignment (0-2 weeks) 
Objective: secure sponsorship, assign roles, define scope. 
Outputs: executive brief, charter, project sponsors, initial risk tolerance statement, prioritized asset list. 

Phase 1 - Discovery & gap assessment (2-6 weeks) 
Objective: baseline maturity vs 62443 (controls, policies, network maps). 
Outputs: asset inventory, network/segment map (logical + physical), control maturity matrix (fast scorecard), prioritized gap register mapped to 62443 parts and SLs. 

Phase 2 - CSMS design & policy (4-8 weeks) 
Objective: build the program that will stay in place for years; map to 62443-2-1. 
Outputs: CSMS blueprint, governance & roles, vendor assurance policy, secure remote access policy, patch management policy (aligned to 62443-2-3 guidance). 

Phase 3 - Risk assessment, zoning & target SL assignment (3-8 weeks) 
Objective: partition your system into zones and conduits and assign SL-T targets. 
Outputs: Zones & conduits diagram, SL-T matrix per zone/conduit, prioritized mitigation roadmap tied to business consequences. 

Note: choose SL targets based on consequences (safety, production, long-lead assets), not just attacker sophistication. 

Phase 4 - Technical design & remediation (variable) 
Objective: implement controls to achieve SL-T (network segmentation, device hardening, authentication, monitoring). 
Outputs: segmentation rules, firewall policies, identity & access implementation, secure configuration baseline for devices, secure network architecture.

Phase 5 - Verification, product assurance & secure SDLC (ongoing) 
Objective: ensure controls meet the technical requirements (3-3 / 4-2) via testing and supplier evidence. 
Outputs: test plans, compliance evidence, vendor product assurance reports (e.g., ISASecure CSA), secure-development evidence from suppliers (4-1).

Phase 6 - Operate, monitor & continually improve (continuous) 
Objective: run the CSMS, monitor for deviations, conduct periodic assessments and re-assign SLs as needed. 
Outputs: continuous monitoring, incident response playbooks, annual CSMS review, supplier re-assessments. 

7. Typical pitfalls, misinterpretations & how Shieldworkz avoids them 

Selecting SLs by attacker profile alone. 

Problem: teams pick SL based on “who might attack” and forget to evaluate consequences. 

Fix: Shieldworkz uses a consequence-first assessment and maps controls against business impact. 

Treating 62443 as only a technical checklist. 

Problem: skipping CSMS design leads to poor sustainment.

Fix: We always build the governance and evidence fabric to keep controls effective for years.

Over-segmentation or under-segmentation.

Problem: either introduces operational pain or leaves lateral pathways for attackers.

Fix: zone/conduit design workshops with operations to balance safety and security. 

Blind reliance on vendor claims.

Problem: vendor marketing ≠ testable compliance. 

Fix: require test evidence (ISASecure, third-party test reports), and run independent verification.

Trying to “bolt on” modern security to legacy PLCs.

Problem: brittle solutions create outages

Fix: defensive compensating controls, micro-segmentation, and change-control that prioritizes safety.

OT Systems is Critical

8. Shieldworkz IEC 62443 services - mapped to the standard parts 

Shieldworkz offers a modular, delivery-grade set of services aligned directly to IEC 62443 so you can pick what you need or opt for full program delivery. 

Governance & Strategy (Part 2 - CSMS) 

62443-2-1 gap assessment and CSMS build (policy, roles, KPIs). 

Vendor & third-party security program templates (procurement clauses mapped to 62443-2-4).  

Risk & Architecture (Part 3 - system design) 

Zone & conduit workshop + SL-T assignment. 

Risk assessment / threat modelling aligned to 62443-3-2 and 3-3. 

Network segmentation engineering and firewall rule build. 

Product & Development Assurance (Part 4 - components) 

Secure development lifecycle (SDL) process adoption for in-house devices (4-1). 

Product evaluation & ISASecure mapping / readiness (support to obtain 4-2 evidence or CSA).  

Verification & Operations 

Technical verification tests (vulnerability scanning tailored to ICS, protocol checks). 

Continuous monitoring (OT aware EDR/NDR tuning), detection rules, SIEM/OT integration. 

Incident response playbooks & tabletop exercises focused on safety & process. 

Managed Services & Ongoing Compliance 

Managed detection & response for OT with SL-based playbooks. 

Continuous compliance reporting: deliver evidence packages aligned to 62443 audits and procurement requests. 

OT Systems is Critical

9. Outcomes, commercial value and KPIs - how to measure success 

When a 62443 program is executed correctly the measurable benefits are real and tangible. 

Operational KPIs 

Mean time to detect (MTTD) OT incidents - target: decrease by 50% in first year. 

Mean time to contain (MTTC) - measurable reduction via playbooks and segmentation. 

Number of successful patch deployments for critical IACS components - increase %. 

Business KPIs 

Reduction in unplanned downtime minutes - translate to $ saved per incident. 

Procurement cycle time - shorter when vendor evidence (e.g., ISASecure) is available.  

Compliance KPIs 

Percentage of zones with SL-T assigned and controls implemented. 

Number of non-conformities raised in internal 62443 audits (trend down). 

OT Systems is Critical

10. Tactical checklist - first 90 days (for asset owners) 

Week 0-2 

Appoint CSMS sponsor & clarify budget. 

Identify initial scope (one plant, one region) for a pilot. 

Week 2-6 

Run a rapid discovery: asset inventory, network map, control owner list. 

Perform a lightweight 62443 gap assessment (prelim scorecard). 

Week 6-10 

Conduct an SL-targeting workshop for high-risk zones (safety & production critical). 

Create a prioritized remediation backlog with quick wins (authentication, segmentation, remote access controls). 

Week 10-12 

Deploy monitoring for the pilot zone and run a tabletop incident exercise. 

Prepare procurement language for vendors: require secure SDLC evidence and product test reports. 

OT Systems is Critical

11. Why Shieldworkz - what makes our approach different 

Shieldworkz provides OT-native cybersecurity that protects operations without disrupting PLC timing or safety, combining OT engineering and security expertise with standards-first, risk-led practices and compliance support and resilience. 

Rapid 62443 Readiness Assessment (2-4 weeks): discovery, scorecard, remediation plan.

Pilot - Zone & Conduit hardening (8-12 weeks): segmentation, authentication, monitoring.

CSMS Build & Governance (12-20 weeks): documentation, supplier policy, verification. 

Product Assurance & Procurement (ongoing): vendor audits and ISASecure readiness. 

Request a demo

If you’re responsible for OT/ICS security, compliance, or procurement in Energy, Oil & Gas, Manufacturing, Pharma, Transportation or Water - book a free demo with Shieldworkz. We will provide a concise, custom 90-day roadmap that maps directly to IEC 62443 requirements and your business priorities. 

Request a Consultation

By submitting, I consent to receive communications from Shieldworkz, its subsidiaries, partners, and affiliates.

CTA section

Get in Touch with Shieldworkz

Submit your inquiry via our secure online form, and a member of our team will respond within 24 hours.
Faq Background
Pattern BG

Frequently Asked Questions

Q: How long does a typical 62443 program take?

A focused pilot (single plant) can show measurable improvements in 3-6 months; enterprise CSMS maturity is a 12-24 month program depending on scope and legacy complexity.

Q: Are 62443 and ISO 27001 compatible?

Q: Do my vendors need to be “62443 certified”?

Q: Should we aim for SL-3 or SL-4?