IEC 62443 (OT/ICS Security)

Introduction: IEC 62443 for OT and Industrial Control System Security

IEC 62443 is the pre-eminent international series of standards for the cybersecurity of Industrial Automation and Control Systems (IACS), commonly referred to as Operational Technology (OT) or Industrial Control Systems (ICS). Originally developed by the ISA99 committee of the International Society of Automation (ISA) and subsequently adopted and expanded by the International Electrotechnical Commission (IEC), the series provides a structured, risk-based framework that spans people, processes and technology across the entire lifecycle of an industrial control environment. Unlike enterprise IT security frameworks, IEC 62443 is purpose-built for the constraints of the OT world: legacy equipment that cannot be patched at will, real-time deterministic control loops, safety-critical processes, decades-long asset lifespans, and the paramount priority of availability and safety over confidentiality.

This deep-dive is written for asset owners, system integrators, product suppliers and their auditors who need an auditor-grade understanding of how to scope, assess, implement and evidence conformity against IEC 62443. It walks through the full structure of the series, the roles it defines, the concepts of zones and conduits, Security Levels (SL), Foundational Requirements (FR), System Requirements (SR) and Requirement Enhancements (RE), and it provides a master assessment checklist enumerating every foundational requirement group with the specific artefacts an auditor should expect to see. Throughout, the emphasis is on defence-in-depth, risk-based security levels and demonstrable, evidence-backed conformity.

What is IEC 62443?

IEC 62443 is a multi-part series (not a single document) that collectively defines requirements and processes for implementing and maintaining electronically secure IACS. It addresses cybersecurity from four complementary perspectives, mapping to the four categories of the series: General concepts and terminology, Policies and Procedures for the asset owner's security programme, System-level technical and process requirements, and Component-level product development and technical requirements. The framework is deliberately role-aware: it recognises that security is a shared responsibility across the Asset Owner (the operator of the plant), the System Integrator (who designs and commissions the automation solution) and the Product Supplier (who manufactures the control components, devices and software).

At the heart of IEC 62443 sit several defining concepts. Defence-in-depth requires multiple, independent layers of protection so that the failure of one control does not lead to compromise of the whole system. Zones and Conduits provide a segmentation model that groups assets with common security requirements into zones, connected by controlled communication channels called conduits. Security Levels (SL 0 to SL 4) express the strength of protection required against increasingly capable adversaries, ranging from casual/incidental exposure (SL 1) up to a sophisticated, well-resourced, IACS-specific attacker (SL 4). Seven Foundational Requirements (FR) organise every technical requirement in the series into coherent security objectives. Together these concepts allow risk to be assessed, target security levels to be set per zone, and controls to be selected and verified in a consistent, auditable manner.

IEC 62443 is closely related to, but distinct from, the older ANSI/ISA-99 numbering and the NIST frameworks. It is horizontal (sector-agnostic) and is applied across power generation and distribution, water and wastewater, oil and gas, chemicals, pharmaceuticals, manufacturing, building automation, transport, and increasingly to medical devices and the broader Industrial Internet of Things (IIoT).

Who must comply with IEC 62443?

IEC 62443 is not, in most jurisdictions, a legally mandated standard in its own right; rather it is a widely adopted benchmark that is increasingly referenced by regulation, procurement contracts and sector authorities. Compliance may be voluntary (best practice), contractual (required by a customer or asset owner), or effectively mandatory where a regulator cites it. The series explicitly recognises three principal roles, each with distinct obligations.

Structure of the IEC 62443 series

The series is organised into four groups of documents. Part numbers follow the pattern 62443-X-Y where X denotes the group (1 General, 2 Policies and Procedures, 3 System, 4 Component) and Y the specific document. The table below summarises the principal published and in-development parts and the audience each addresses.

Two dimensions run vertically through the technical parts. The seven Foundational Requirements (FR1-FR7) group all technical controls, and the four Security Levels (SL 1-4) scale the rigour of those controls. In 62443-3-3 the requirements are expressed as System Requirements (SR) with optional Requirement Enhancements (RE); in 62443-4-2 the analogous component requirements are expressed as Component Requirements (CR) with type-specific variants for Embedded Devices (EDR), Host Devices (HDR), Network Devices (NDR) and Software Applications (SAR).

Master assessment checklist: the seven Foundational Requirements

This is the core of any IEC 62443 assessment. The 62443-3-3 (system) and 62443-4-2 (component) requirements are organised under seven Foundational Requirements. For each FR below, an auditor should verify that the target Security Level (SL-T) has been set for each zone, that the achieved capability (SL-C) of components and the deployed configuration (SL-A) meet or exceed it, and that objective evidence exists. Every FR group is enumerated below with the base System Requirements and, in the tables, what to verify and the typical evidence expected. Do not skip any FR.

FR1 - Identification and Authentication Control (IAC)

FR1 ensures that all human users, software processes and devices are reliably identified and authenticated before being granted access to the IACS. It covers SR 1.1 (human user identification and authentication), SR 1.2 (software process and device identification and authentication), SR 1.3 (account management), SR 1.4 (identifier management), SR 1.5 (authenticator management), SR 1.6 (wireless access management), SR 1.7 (strength of password-based authentication), SR 1.8 (public key infrastructure certificates), SR 1.9 (strength of public key authentication), SR 1.10 (authenticator feedback), SR 1.11 (unsuccessful login attempts), SR 1.12 (system use notification) and SR 1.13 (access via untrusted networks).

FR2 - Use Control (UC)

FR2 enforces that authenticated entities are permitted to perform only the actions for which they are authorised, and that those actions are constrained and logged. It comprises SR 2.1 (authorisation enforcement), SR 2.2 (wireless use control), SR 2.3 (use control for portable and mobile devices), SR 2.4 (mobile code), SR 2.5 (session lock), SR 2.6 (remote session termination), SR 2.7 (concurrent session control), SR 2.8 (auditable events), SR 2.9 (audit storage capacity), SR 2.10 (response to audit processing failures), SR 2.11 (timestamps), SR 2.12 (non-repudiation) and SR 2.13 (use of physical diagnostic and test interfaces).

FR3 - System Integrity (SI)

FR3 protects the integrity of the IACS against unauthorised manipulation of software, firmware, configuration and information, both at rest and in transit. It includes SR 3.1 (communication integrity), SR 3.2 (malicious code protection), SR 3.3 (security functionality verification), SR 3.4 (software and information integrity), SR 3.5 (input validation), SR 3.6 (deterministic output), SR 3.7 (error handling), SR 3.8 (session integrity) and SR 3.9 (protection of audit information).

FR4 - Data Confidentiality (DC)

FR4 ensures the confidentiality of information on communication channels and in data stores where required. In OT, confidentiality is often lower priority than availability and integrity, but it remains essential for credentials, keys, configuration and sensitive process data. It covers SR 4.1 (information confidentiality), SR 4.2 (information persistence) and SR 4.3 (use of cryptography).

FR5 - Restricted Data Flow (RDF)

FR5 is where the zones-and-conduits model is enforced technically: segmenting the IACS into zones and controlling all communication through defined conduits. It includes SR 5.1 (network segmentation), SR 5.2 (zone boundary protection), SR 5.3 (general-purpose person-to-person communication restrictions) and SR 5.4 (application partitioning).

FR6 - Timely Response to Events (TRE)

FR6 ensures the IACS supports monitoring, detection, and forensic capability so that security events can be detected and responded to in a timely manner. It covers SR 6.1 (audit log accessibility) and SR 6.2 (continuous monitoring).

FR7 - Resource Availability (RA)

FR7 protects the availability of the IACS against denial-of-service and resource exhaustion, and ensures resilience and recoverability - reflecting that availability and safety are the top priorities in OT. It comprises SR 7.1 (denial-of-service protection), SR 7.2 (resource management), SR 7.3 (control system backup), SR 7.4 (control system recovery and reconstitution), SR 7.5 (emergency power), SR 7.6 (network and security configuration settings), SR 7.7 (least functionality) and SR 7.8 (control system component inventory).

Programme and process requirements (62443-2-1 CSMS and 62443-2-4)

Beyond the seven technical FRs, an asset owner must demonstrate a Cyber Security Management System (CSMS) per 62443-2-1, and service providers must demonstrate the capabilities of 62443-2-4. These process areas are equally auditable.

Secure product development lifecycle (62443-4-1)

Product suppliers must operate a secure development lifecycle. 62443-4-1 defines eight practices that an auditor evaluates for maturity.

Scoping the assessment

Scoping is the decisive early activity because IEC 62443 is applied per system-under-consideration (SuC), not to an entire organisation at once. The scope must be defined precisely before any assessment or design work begins.

• Define the System-under-Consideration (SuC): the specific IACS, plant, line or facility being assessed, including its physical and logical boundaries.
• Identify the applicable role(s): are you assessing as asset owner (62443-2-1/3-2/3-3), integrator (62443-2-4/3-3) or product supplier (62443-4-1/4-2)?
• Establish the relevant parts of the series that apply to the role and lifecycle stage (design, procurement, operation, decommissioning).
• Enumerate all zones and conduits within the SuC and their interfaces to external systems (IT network, cloud, remote access, vendors).
• Identify the safety, availability and business-criticality of the processes, since these drive the target Security Level (SL-T).
• List all assets: controllers (PLC/DCS/RTU/SIS), HMIs, engineering workstations, historians, network devices, and any IIoT/edge devices.
• Determine the target SL per zone using 62443-3-2 risk assessment, and document assumptions, exclusions and interdependencies.
• Agree the assessment basis: capability (SL-C), target (SL-T) and achieved (SL-A) levels, and whether certification (e.g. ISASecure, IECEE CB) is sought.

Implementation approach (phased)

A pragmatic IEC 62443 programme follows the 62443-3-2 risk-assessment and design workflow, then implements and operationalises controls. The following phased approach aligns to that workflow and to the CSMS lifecycle.

Phase 1 - Initiation and high-level risk assessment

• Activities: secure management sponsorship; define the SuC and boundaries; build/validate the OT asset inventory; perform an initial high-level cyber risk assessment to determine whether detailed assessment is warranted.
• Deliverables: programme charter, SuC definition, asset register, initial (high-level) risk assessment report.

Phase 2 - Zone and conduit partitioning

• Activities: group assets into zones with common security requirements; identify all conduits between zones and to external systems; document data flows and trust boundaries.
• Deliverables: zone-and-conduit model and diagram, data-flow inventory, conduit register.

Phase 3 - Detailed risk assessment and target SL determination

• Activities: for each zone and conduit, assess threats, vulnerabilities and consequences; determine the target Security Level (SL-T 1-4); identify the gap versus current state.
• Deliverables: detailed risk assessment per zone/conduit, documented SL-T per zone, cybersecurity requirements specification (CRS), gap analysis.

Phase 4 - Design and countermeasure selection

• Activities: select technical and procedural countermeasures across the seven FRs to achieve SL-T; specify component SL-C requirements for procurement; design segmentation, secure remote access and monitoring.
• Deliverables: security design specification, procurement requirements (SL-C), architecture and network diagrams, control mapping to FRs.

Phase 5 - Implementation and integration

• Activities: deploy and configure countermeasures; harden components; implement segmentation, IAM/MFA, monitoring and backups; validate integrator capabilities per 62443-2-4.
• Deliverables: hardened configurations, deployed segmentation/monitoring, updated CSMS procedures, factory/site acceptance test (FAT/SAT) security records.

Phase 6 - Verification, validation and certification

• Activities: verify achieved SL (SL-A) against SL-T through testing, assessment and audit; remediate gaps; pursue certification if in scope (ISASecure SSA/CSA/SDLA, IECEE).
• Deliverables: verification/validation report, SL-A determination, gap-remediation log, certification evidence.

Phase 7 - Operate, maintain and improve

• Activities: operate the CSMS; patch management (62443-2-3); continuous monitoring and incident response; periodic re-assessment as the SuC and threat landscape change.
• Deliverables: operational security records, patch and vulnerability logs, monitoring/incident reports, management-review and continual-improvement records.

Security Levels and maturity model

IEC 62443 uses two distinct scales. Security Levels (SL 0-4) describe the strength of protection required or achieved against increasingly capable adversaries and apply to zones, systems and components. Maturity Levels (ML 1-4), drawn from CMMI and used in 62443-4-1 and 62443-2-4, describe the maturity of an organisation's processes. Both are summarised below.

For any zone the assessment distinguishes SL-T (target, from risk assessment), SL-C (capability of the components/system as designed or certified) and SL-A (achieved, as actually deployed and operated). A conformant design requires SL-C and SL-A to meet or exceed SL-T for every FR in every zone.

Assessment and audit approach

1. Confirm scope and role: agree the SuC, boundaries, the applicable parts of the series and whether the objective is a gap assessment, conformity assessment or formal certification.
2. Collect documentation: obtain the CSMS, risk assessments, zone/conduit model, network diagrams, asset inventory, policies, procedures and prior audit reports.
3. Review the zone-and-conduit model and target Security Levels: validate that SL-T is justified by the documented risk assessment (62443-3-2).
4. Assess technical controls against the seven FRs: for each zone verify SR/CR coverage and determine SL-C from component certifications and design.
5. Perform on-site and technical validation: inspect configurations, sample firewall rules, review logs, witness backups/restores and interview operators and engineers.
6. Determine achieved Security Level (SL-A): compare deployed and operated state against SL-T for every FR, recording conformities and non-conformities.
7. Evaluate process maturity (ML 1-4) for supplier/integrator practices under 62443-4-1 and 62443-2-4 where in scope.
8. Document findings: classify each gap by severity and affected FR/SR, and record objective evidence supporting each conclusion.
9. Produce the report and remediation plan: state SL-A vs SL-T per zone, prioritised remediation, owners and timelines.
10. Re-test and, where applicable, recommend for certification (ISASecure, IECEE) or schedule the periodic re-assessment cycle.

Evidence request list

The following categorised evidence list is what an auditor should request in advance and validate during the engagement.

• Governance and CSMS: security policy, CSMS scope and documentation, organisation chart/RACI, management-review minutes, risk-assessment methodology and registers.
• Architecture and scope: system-under-consideration definition, network and data-flow diagrams, zone-and-conduit register, target SL determination records.
• Asset management: OT asset inventory/CMDB, firmware and software version lists, automated discovery outputs, end-of-life register.
• Identity and access (FR1/FR2): account listings, IdP/AD exports, RBAC/least-privilege matrices, MFA configuration, joiner-mover-leaver and access-review records.
• System integrity and confidentiality (FR3/FR4): hardening standards, application allow-listing/AV coverage, signed-update evidence, encryption and key-management documentation, media-sanitisation records.
• Network and segmentation (FR5): firewall rule bases with justification, DMZ/data-diode designs, remote-access architecture, egress-filtering configuration.
• Monitoring and response (FR6): OT-IDS/SIEM deployment, logging policy, alert runbooks, incident register, IR plan and exercise records.
• Availability and recovery (FR7): backup schedules and logs, restore-test evidence, RTO/RPO definitions, UPS/emergency-power records, least-functionality configuration.
• Supply chain and products: 62443-4-1 SDL evidence, product certifications (SL-C), PSIRT/advisory process, integrator 62443-2-4 capability attestations, contracts and SLAs.
• Operations: patch-management records (62443-2-3), change-control logs, vulnerability-management reports, training and competency records, prior audit and penetration-test reports.

Roles and responsibilities

KPIs to track

• Percentage of zones with a documented target Security Level (SL-T) derived from formal risk assessment.
• Percentage of zones where achieved SL-A meets or exceeds SL-T across all seven FRs.
• OT asset inventory accuracy and coverage (percentage of assets discovered and version-tracked).
• Percentage of IACS components with default credentials changed and hardened to baseline.
• Mean time to detect (MTTD) and mean time to respond (MTTR) for OT security events.
• Patch/vulnerability remediation rate and mean time to remediate critical OT vulnerabilities.
• Percentage of remote-access sessions using MFA and passing through controlled conduits.
• Backup success rate and successful restore-test rate against defined RTO/RPO.
• Percentage of procured components carrying declared/certified SL-C meeting requirements.
• Number of open non-conformities by FR and their ageing against remediation SLAs.
• Security awareness/training completion rate for OT engineering and operations staff.
• Number of unauthorised conduits or unmanaged IT-OT crossings detected per period.

Readiness checklist

• System-under-Consideration and role (asset owner/integrator/supplier) are formally defined.
• A documented, management-approved CSMS (62443-2-1) is in place.
• A complete, maintained OT asset inventory exists with firmware/software versions.
• Zones and conduits are defined, diagrammed and registered for the whole SuC.
• A 62443-3-2 risk assessment has set a justified target SL for every zone.
• IT and OT networks are segmented; all conduits are documented and controlled.
• Identification, authentication and least-privilege access (FR1/FR2) are enforced, with MFA for remote access.
• System integrity controls (FR3): hardening, allow-listing/AV, signed updates and change control are operating.
• Restricted data flow (FR5): zone-boundary protection and egress filtering are in place.
• Continuous monitoring and an OT incident-response plan (FR6) are deployed and tested.
• Backups are performed and restores are periodically tested (FR7) against RTO/RPO.
• Procurement requires declared SL-C; integrators/vendors evidence 62443-2-4 / 62443-4-1 capability.
• Patch and vulnerability management (62443-2-3) processes are documented and operating.
• OT staff training, competency and awareness records are current.
• An internal audit / self-assessment has determined SL-A versus SL-T with a remediation plan.

Common gaps

• Flat or poorly segmented networks with direct IT-to-OT or internet connectivity and no defined conduits.
• Incomplete or outdated OT asset inventories, leaving unmanaged and unpatched devices in scope.
• Default or shared credentials on controllers, HMIs and network devices, and absence of MFA for remote access.
• Target Security Levels never formally determined, so controls are selected without a risk basis.
• Unmanaged remote access by vendors and maintenance providers through uncontrolled conduits.
• Little or no OT-specific monitoring; reliance on IT SIEM that does not understand industrial protocols.
• Backups that are not tested, not offline/immutable, and no rehearsed recovery/reconstitution procedure.
• Weak patch and vulnerability management due to fear of disrupting availability, leaving known CVEs unaddressed.
• Procurement that does not specify SL-C, resulting in components incapable of meeting the target SL.
• Cybersecurity treated as a one-off project rather than an operating CSMS with continual improvement.
• Poor separation of duties between engineering and operations roles, and excessive standing privilege.
• Cybersecurity controls implemented without coordinating with functional safety (IEC 61511), risking safety-integrity impact.

IEC 62443 mapped to other frameworks

Frequently asked questions

Need help with IEC 62443?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.