Framework

IEC 62443
industrial cybersecurity assessment, evidence, and remediation

IEC 62443 is the international standard for cybersecurity in industrial automation and control systems. Run IEC 62443 assessments across the asset owner, the system integrator, and the product supplier roles: scope zones and conduits, set target security levels, evidence the seven foundational requirements, track manual and authenticated test findings, and produce assessor-ready evidence packs from one workflow.

Get Started Free

No credit card required. Free plan available forever.

IEC 62443 in context: cybersecurity for industrial automation and control systems

IEC 62443 is the international standard family for cybersecurity in industrial automation and control systems (IACS). Published jointly by the International Electrotechnical Commission and the International Society of Automation (where it originated as the ISA-99 series), it is the reference standard for OT and ICS security across manufacturing, energy, water, pharmaceuticals, transport, and food and beverage. The family is structured around roles (asset owner, system integrator, product supplier), a zone-and-conduit model for scope, four Security Levels reflecting threat-actor capability, and seven foundational requirements that organise the technical control set.

The compliance trigger varies by region and by sector. EU operators of essential services increasingly cite IEC 62443 as the technical backbone for the obligations introduced by NIS 2. US critical-infrastructure operators frequently pair IEC 62443 with NIST SP 800-53 and the NIST Special Publication 800-82 OT guidance. Product certifications such as ISASecure CSA, ISASecure SDLA, EDSA, and TUV-style assessments anchor on the 62443-4 series. The common thread is that the standard is referenced as the operating language between the asset owner, the integrator, the supplier, and the assessor, regardless of which regulatory regime imposes the obligation.

Who is in scope for IEC 62443

Scope is set by the role rather than by the organisation. A single firm can be an asset owner for its own plant network, a system integrator for customer projects, and a product supplier for OEM components, with three different parts of the standard applying to three different programmes inside the same firm.

Asset owners running operational technology

Manufacturers, utilities, oil and gas operators, water and wastewater utilities, transport operators, mining operators, pharma manufacturers, and food and beverage producers operating SCADA, DCS, PLC, HMI, and historian estates. The asset owner programme is anchored by IEC 62443-2-1, with the operational policies and procedures that wrap the control system itself.

System integrators and OT engineering firms

Integrators delivering automation solutions, control systems, and industrial networks are assessed against IEC 62443-2-4. The standard sets the secure integration capabilities expected from the supplier (account management, hardening, patching support, backup and restore, network segmentation), and is the reference clients use during integrator selection and renewal.

Product suppliers and embedded device manufacturers

OEMs producing PLCs, RTUs, IEDs, gateways, HMIs, and embedded software for industrial use are assessed against the IEC 62443-4-1 secure development lifecycle and the IEC 62443-4-2 component requirements. ISASecure SDLA, CSA, and EDSA certifications all reference the 62443-4 series; CE-marked OT products under EU regulation increasingly reference the same requirements.

OT and ICS security consultancies

Consultancies running zone and conduit risk assessments, IEC 62443-3-2 cybersecurity risk assessments, gap assessments against the foundational requirements, manual penetration tests on IT-OT bridges, and red team exercises against industrial environments. The standard is the common reference between the consultancy, the asset owner, and the integrator when the engagement is scoped.

The IEC 62443 document family and which parts apply to which role

IEC 62443 is a family of standards rather than a single document. Each part covers a specific scope, audience, and assessment surface. Knowing which part applies to which role determines the assessment plan and the evidence pack a programme is expected to produce.

Part	Title	Coverage notes
IEC 62443-1-1	Concepts and models	Defines the core terminology used across the family: zones, conduits, the System Under Consideration, security levels, foundational requirements, and the role split between asset owner, integrator, and product supplier. Read first when building an internal training programme around the standard.
IEC 62443-2-1	Cybersecurity management for asset owners	The control set for the asset owner cybersecurity management system. Covers governance, policies and procedures, network segmentation, access control, system maintenance, and incident response from the operating-environment perspective. The asset owner programme starts here.
IEC 62443-2-3	Patch management	Process requirements for vendor-issued patch management between asset owners and product suppliers. Defines the patch announcement, applicability assessment, deployment, and verification workflow that feeds Foundational Requirement 6 (Timely Response to Events).
IEC 62443-2-4	Security programme requirements for service providers	The control set integrators and service providers are assessed against. Covers staffing, assurance, architecture, wireless, configuration, account, malware protection, patching, backup, monitoring, and event management capabilities. The standard buyers cite when running integrator selection and renewal.
IEC 62443-3-2	Security risk assessment for system design	The required process for partitioning the System Under Consideration into zones and conduits, performing initial cybersecurity risk assessment, identifying target security levels per zone, and producing the cybersecurity requirements specification that feeds detailed design.
IEC 62443-3-3	System security requirements and security levels	The system-level requirements that a control system must meet at each Security Level. Lists 51 system requirements (SRs) plus requirement enhancements, organised under the seven foundational requirements. The reference assessors use during gap analysis.
IEC 62443-4-1	Product supplier secure development lifecycle	Process requirements for secure product development. Covers security management, specification, design, implementation, verification and validation testing, defect handling, and end-of-life. ISASecure SDLA certification is anchored in this part.
IEC 62443-4-2	Technical security requirements for components	Component-level requirements for embedded devices, network devices, host devices, and software applications. Lists per-FR component requirements (CRs) at each Security Level. The reference for product hardening and component certification (CSA, EDSA, ISASecure CSA).

The seven foundational requirements (FRs)

The foundational requirements organise the technical control set across both the system level (62443-3-3) and the component level (62443-4-2). Every system requirement (SR) and every component requirement (CR) belongs to one of the seven FRs. Mapping every confirmed finding to the affected SR or CR and to the FR family produces a per-FR pass, partial, and fail picture the assessor can read in one pass.

FR 1: Identification and Authentication Control
Identify and authenticate human users, software processes, and devices accessing the control system. Covers account management, identifier management, authenticator management, password strength, public-key authentication, and authenticator transmission. Higher Security Levels add multi-factor authentication and replay-resistance requirements.
FR 2: Use Control
Enforce assigned privileges, separation of duties, session management, and the auditability of user actions. Covers authorisation enforcement, wireless access management, mobile code, session lock, remote session termination, and auditable events. Misalignment here is a frequent finding during 62443-3-3 gap assessments.
FR 3: System Integrity
Protect the integrity of the control system, the data, and the communications. Covers communication integrity, malicious code protection, security functionality verification, software and information integrity, input validation, error handling, session authenticity, and protection of audit information. Pair this with the 62443-4-1 secure development evidence at the supplier.
FR 4: Data Confidentiality
Protect the confidentiality of information at rest and in transit on the control system. Covers data confidentiality at rest, data confidentiality in transit, and the use of validated cryptographic algorithms and key management. Compensating controls are common where embedded device cryptography is constrained; document the rationale on the engagement record.
FR 5: Restricted Data Flow
Segment the control system into zones and conduits so data flow is restricted to permitted paths. Covers network segmentation, zone boundary protection, general purpose person-to-person communication restrictions, and application partitioning. The output of the 62443-3-2 zone and conduit assessment lands here directly.
FR 6: Timely Response to Events
Detect, analyse, and respond to security events. Covers audit log accessibility, continuous monitoring, and the patching process referenced from 62443-2-3. The same record that hosts findings, remediation actions, and re-test evidence supplies most of the FR 6 evidence at the next cycle.
FR 7: Resource Availability
Ensure the control system continues operating despite denial-of-service events, resource exhaustion, or backup-and-restore needs. Covers denial-of-service protection, resource management, control system backup, control system recovery, emergency power, network and security configuration restoration, least functionality, and the response to compromised plant infrastructure.

Security Levels: what SL-T 1, 2, 3, and 4 actually mean

IEC 62443 defines four Security Levels that reflect the capability of the threat actor the controls are expected to resist. SL-T is the target Security Level set per zone during 62443-3-2. SL-A is the achieved level after assessment. The gap between SL-T and SL-A drives the remediation plan and the compensating-control register.

SL 1: protect against casual or coincidental violation, with low-skill attackers, low motivation, no specific OT knowledge, and limited resources
SL 2: protect against intentional violation using simple means, with low-skill attackers, low motivation, generic OT knowledge, and low resources
SL 3: protect against intentional violation using sophisticated means, with moderate-skill attackers, moderate motivation, OT-specific knowledge, and moderate resources (the common SL-T for high-criticality zones in regulated industries)
SL 4: protect against intentional violation using sophisticated means with extended resources, addressing nation-state-level actors with high motivation, OT-specific knowledge, and extended resources

The assessment workflow in order

IEC 62443 does not prescribe a single assessment cadence; it prescribes a process that revisits zones, conduits, threat assumptions, and target Security Levels at a documented cadence and after material change. Running the work as a managed workflow from the start cuts the cycle time on every reassessment and removes the most common cause of assessor escalation, which is evidence scattered across drives, plant systems, and email.

Document the System Under Consideration: assets in scope, the operating environment, the safety boundary, and the data flows that cross it
Partition the SUC into zones and conduits per 62443-3-2 with rationale per zone (function, criticality, trust assumptions, conduit constraints)
Run the initial cybersecurity risk assessment per zone, identify the threats and consequences, and set the target Security Level (SL-T) per zone
Map current implementation against 62443-3-3 system requirements (or 62443-4-2 component requirements at the product level) and capture pass, partial, fail, and rationale per SR or CR
Run authenticated scans on permitted IT-side or DMZ assets, log manual findings against zone boundaries, and bring subcontractor and offline tester output into the same finding register via CSV import
Build the cybersecurity requirements specification (CRS) that feeds detailed design, capture compensating controls per gap, and record the achieved Security Level (SL-A) per zone
Track remediation per finding through change-window and outage-window constraints, retest verified closure, and refresh the evidence pack on the next cycle and after material change

Common assessment gaps that cost real time

The patterns below appear in most 62443-3-2 risk assessments and most 62443-3-3 gap analyses. Knowing where assessor escalations cluster makes the difference between an assessment that closes inside the change window and one that drags through plant operations and engineering.

Zone and conduit diagram exists but is out of date

The original 62443-3-2 risk assessment produced a clean diagram, but new SaaS connections, new wireless access points, new vendor remote access paths, and new IoT devices were added without the diagram being updated. The first assessor finding closes against the zone diagram itself, because every SR and CR evaluation depends on the zone boundary being correct. Treat the diagram as a live artefact tied to the asset register, not as an annual export.

SL-T set high without compensating controls for embedded device limitations

Asset owners frequently set SL-T at 3 across the control layer because that is the recommended floor for high-criticality zones, but the embedded devices in the zone cannot meet several SL 3 component requirements (cryptographic algorithm strength, audit log capacity, replay-resistance). The assessment record needs explicit compensating controls per requirement gap (network-level segmentation, monitoring at the conduit, vendor escalation on patching) so the SL-A reflects the actual achieved level rather than the aspiration.

Patch management treated as IT process, not 62443-2-3

Patches arrive from the OEM, sit in the IT change queue, and ship during the next IT maintenance window without an OT applicability assessment, an OT-specific deployment plan, or a verification record per device. The FR 6 evidence is missing the chain that 62443-2-3 specifies: patch announcement from the supplier, applicability assessment by the asset owner, deployment with the change window and the rollback plan, and verification per device. The assessor opens this every cycle when the chain is incomplete.

Findings tracked in IT-side ticket system and OT-side spreadsheet

OT findings live in a plant-specific spreadsheet, IT findings live in the corporate ticketing system, and the consolidated record at audit time is a pivot table with no audit trail. The 62443 evidence pack needs one register that ties every finding to the affected SR or CR, the FR family, the zone, the asset, the owner, and the closure record. Reconciling the two sources at audit time costs more than running the work as one register from the start.

Subcontractor reports treated as separate deliverables

Electrical, instrumentation, SCADA, and remote access vendors deliver findings as Word documents that go straight to a folder. The asset owner sees three views of the same gap, with three different IDs, three different severities, and no coordinated remediation plan. Bring subcontractor findings into the engagement register, deduplicate against the existing finding list, and consolidate the report so the asset owner has one record per gap.

Penetration testing and vulnerability assessment under IEC 62443

IEC 62443 references penetration testing and vulnerability assessment indirectly through Foundational Requirement 6 (Timely Response to Events) and the verification and validation practices in 62443-4-1. Active scanning against PLCs, RTUs, and historians is constrained and frequently prohibited in production OT environments. The practical scope for testing sits at the IT-OT bridge, the DMZ, the engineering workstations, the remote access portals, the vendor jump servers, and the corporate-IT segment that connects to the OT zones. The penetration testing workflow, the vulnerability assessment workflow, and the remediation tracking workflow are designed for this kind of programme: scope, log findings against zones and conduits, track remediation through change-window constraints, and re-test before closure. For IoT and embedded testing on adjacent assets, see the IoT penetration testing guide.

Evidence the assessor (and your customer) actually want

Programmes that pass review build the evidence pack as the work happens. Programmes that fail review assemble the pack the week before the assessment from a folder of PDFs and a plant operator's memory. The artefacts below are the ones the assessor expects to see on a 62443-3-3 system gap assessment, a 62443-2-4 integrator assessment, or a 62443-4-1 SDL audit.

System Under Consideration documentation including asset register, network diagram, zone and conduit diagram, and data flow diagram
62443-3-2 cybersecurity risk assessment record covering threat sources, consequences, likelihood, and SL-T per zone
Cybersecurity requirements specification feeding detailed design with traceable per-zone requirements
Per-SR and per-CR implementation status with pass, partial, fail, rationale, and supporting artefact reference
Patch management evidence per 62443-2-3 including patch announcement, applicability assessment, deployment record, and verification result
Authenticated scan output (where permitted on IT-side or DMZ assets), manual finding records, and offline tester reports merged into one register
Incident response records, tabletop exercises, and the FR 6 audit log evidence per zone
Compensating control register where embedded device limitations or change-window constraints prevent direct implementation, with the rationale and the review cadence
Re-test evidence per closed finding, including the original detection, the remediation action, and the verification artefact
Achieved Security Level (SL-A) per zone with the gap to SL-T, the remediation plan, and the next assessment date

Where SecPortal fits in the IEC 62443 workflow

SecPortal is the operating layer for the IEC 62443 programme: zone scoping, risk assessment, control mapping, scans where permitted, manual findings, remediation tracking, and assessor-ready evidence packs. Compliance tracking covers IEC 62443 alongside the other frameworks the same firm has to satisfy, including ISO 27001, NIS 2, NIST 800-53, and MITRE ATT&CK for ICS.

Compliance tracking that maps every finding to IEC 62443 system requirements (62443-3-3) and component requirements (62443-4-2) alongside the foundational requirements, and to ISO 27001, NIST 800-53, NERC CIP, and IEC 27019 for entities under multiple regimes
Engagement management for the 62443-3-2 risk assessment, the gap assessment against system requirements, the manual penetration test on IT-OT bridges, and the re-test cycle, with scope, status, evidence, and re-test all on one record
Findings management with CVSS 3.1 scoring, environmental context fields, 300+ remediation templates, and CSV import with custom column mapping for offline tester output, vendor scanner reports, and subcontractor deliverables
17-module authenticated scanning for permitted IT-side or DMZ assets and 16-module external scanning for the corporate-IT side and vendor remote access portals, so the boundary and the perimeter evidence sit on the same record as the OT-side findings
Continuous monitoring with scheduled scans (daily, weekly, monthly) so the cadence and trend evidence required by FR 6 (Timely Response to Events) is recorded automatically on permitted asset classes
AI report generation that turns findings, control mappings, and remediation actions into separate executive, technical, and operations-team narratives without a manual rewrite per audience
Branded client portal for the asset owner, the integrator, and the supplier so the engagement record is the working surface across plant operations, corporate security, and engineering

IEC 62443 is a multi-year programme rather than a one-off project. The first cycle establishes the System Under Consideration documentation, the zone and conduit diagram, the risk assessment, and the baseline SL-A per zone. Subsequent cycles tighten the evidence trail, close compensating-control gaps, and prepare the programme for recertification (where ISASecure CSA, SDLA, or third-party 62443-3-3 assessment is in scope). For consultancies delivering IEC 62443 work to multiple asset owners or integrators, the OT and ICS security consultancies workspace bundles that with branded client portals and AI report generation, so the deliverable looks as polished as the work behind it. For firms working further down the device side of the same standard (component certification under 62443-4-2, embedded firmware review, secure boot and update mechanism testing, radio analysis, and the mobile and cloud surfaces around the connected product), the SecPortal for IoT security consultancies page covers the engagement model that pairs IEC 62443 component-requirement tagging with OWASP IoT Top 10 mapping and retests across firmware versions.

For programmes that want continuous detection and trend evidence between manual tests on permitted asset classes, the continuous monitoring capability and the external scanning capability produce the cadence and coverage record that FR 6 expects to see on the IT-OT bridge and the DMZ.

Key control areas

SecPortal helps you track and manage compliance across these domains.

Roles: asset owner, integrator, product supplier (62443-2-1, 62443-2-4, 62443-4-1)

IEC 62443 assigns responsibilities by role rather than by organisation type. The asset owner runs the security programme for the operating environment under 62443-2-1. The system integrator delivers the automation solution under 62443-2-4 and is assessed against secure integration practices. The product supplier develops control system components under the secure development lifecycle of 62443-4-1, and ships components compliant with the technical requirements of 62443-4-2. Track the role on the engagement record so the assessment scope, the requirements, and the evidence pack reflect the responsibilities the contract actually assigns.

Zones, conduits, and the SUC (System Under Consideration) per 62443-3-2

The 62443-3-2 risk assessment process partitions the System Under Consideration into zones (logical groupings of assets with shared security requirements) connected by conduits (the data paths between zones). Document the SUC, the zone and conduit diagram, the data flows, the trust assumptions per conduit, and the threat model. The zone boundary is the primary unit of assessment, so the diagram, the rationale, and the boundary protections all sit on the assessment record from day one.

Target Security Levels (SL-T) and the seven foundational requirements

IEC 62443 defines four Security Levels (SL 1 to SL 4) reflecting the capability of the threat actor the controls are expected to resist. SL-T is the target level set per zone during 62443-3-2; SL-A is the achieved level after assessment. The seven foundational requirements (Identification and Authentication Control, Use Control, System Integrity, Data Confidentiality, Restricted Data Flow, Timely Response to Events, Resource Availability) carry per-FR system requirements at each SL. Capture the SL-T per zone, the SL-A achieved, and the gap on the engagement record.

System requirements per 62443-3-3 and component requirements per 62443-4-2

62443-3-3 lists the system-level security requirements (SRs and Requirement Enhancements) that a control system must meet at each Security Level. 62443-4-2 lists the corresponding component-level requirements (CRs) for embedded devices, network devices, host devices, and software applications. Map every confirmed finding to the affected SR or CR and to the FR family so the requirement-by-requirement pass, partial, and fail evidence is explicit at the next assessment cycle.

Secure development lifecycle for product suppliers (62443-4-1)

62443-4-1 defines the process requirements for a secure product development lifecycle: security management, specification of security requirements, secure design, secure implementation, security verification and validation testing, defect handling, and product end-of-life. Suppliers seeking IEC 62443-4-1 certification (commonly via ISASecure SDLA) need evidence per practice across the product programme. Track the SDL practice, the artefact, and the gap on the supplier engagement record so the certification evidence is a live audit trail rather than a year-end scramble.

Patch management, vulnerability handling, and timely response (FR 6)

Foundational Requirement 6 (Timely Response to Events) covers vulnerability handling, patch management, and incident response. The 62443-2-3 patch management process and the 62443-4-1 defect handling practice both feed this requirement. Tie scanner output (where authenticated scans are permitted in IT-side or DMZ assets) and manual finding evidence to the SR they cover, and capture the change window, the compensating control, and the verified closure record per finding for the assessor.

Risk assessment, evidence pack, and re-assessment cadence

IEC 62443 expects a risk-based assessment that revisits zones, conduits, threat assumptions, and SL-T at a documented cadence and after material change. Maintain the SUC documentation, the zone and conduit diagram, the threat assessment, the SL-T per zone, the assessment findings, the remediation plan, and the post-assessment SL-A as one evidence pack tied to the engagement record. The same record supports an internal review, a customer audit, and an ISASecure or TUV-style external assessment.

Related features

Compliance tracking without a full GRC platform

Vulnerability management software that tracks every finding

Orchestrate every security engagement from start to finish

AI-powered reports in seconds, not days

Test web apps behind the login

Monitor continuously catch regressions early

Your brand. Your portal. Your clients love it.

Run a defensible IEC 62443 programme without spreadsheet sprawl

Scope zones and conduits, set SL-T per zone, evidence the seven foundational requirements, track findings, and ship assessor-ready reports from one workflow. Start free.