IEC 62443 Readiness Guide
Prepare engineering, project, and assurance teams for practical IEC 62443 discussions across system scope, security levels, segmentation, risk assessment, and project verification.
- SuC boundary evidence
- zones and conduits workshops
- SL-T discussions
- FAT/SAT verification
Overview
What IEC 62443 readiness needs before detailed assessment starts.
Who this guide is for
For engineering, OT cybersecurity, project, assurance, vendor, and integrator teams.
Why IEC 62443 readiness matters
Reduces late rework by clarifying scope, evidence, and verification early.
01
Define
Confirm the SuC, owners, interfaces, and evidence baseline.
02
Structure
Map zones, conduits, communication paths, and trust boundaries.
03
Assess
Connect security levels and risk scenarios to operational context.
04
Verify
Plan FAT, SAT, handover, residual risk, and close-out evidence.
The IEC 62443 series is divided into several areas.
| Area | What it covers | Why it matters |
|---|---|---|
| General | Terms, concepts, and models | Creates a shared language for IT, OT, engineering, and assurance teams |
| Policies and procedures | Cybersecurity management and governance | Supports organisational security processes and responsibilities |
| System | Risk assessment, system requirements, security levels, zones, and conduits | Most relevant to project architecture and system design |
| Component | Product and device security requirements | Useful for assessing PLCs, HMIs, switches, software, and embedded devices |
- IEC 62443-3-2 for risk assessment, SuC definition, zones, conduits, and security levels
- IEC 62443-3-3 for system security requirements and foundational requirements
- IEC 62443-4-2 for component security requirements
- IEC 62443-2-4 for service provider and integrator requirements
The System under Consideration, often shortened to SuC, defines the boundary of the system being assessed.
This is one of the most important preparation steps.
A weak SuC definition leads to unclear risk assessment, unclear security levels, and poor evidence.
- control panels
- PLCs and safety PLCs
- HMIs and operator stations
- SCADA servers and clients
- engineering workstations
- historians and reporting systems
- industrial switches and routers
- firewalls and remote access equipment
- vendor equipment connected to the control system
- links to corporate IT, cloud platforms, or third-party networks
- interfaces to other control systems or packages
- backup, recovery, and maintenance infrastructure
- What system is being assessed?
- Where does the system boundary start and end?
- Which assets are inside the scope?
- Which assets are outside the scope?
- Which systems does it communicate with?
- Who owns the system?
- Who maintains it?
- Who has remote or local access?
- What drawings, schedules, and records support the boundary definition?
- network architecture drawings
- control system architecture drawings
- panel layouts
- asset registers
- IP address schedules
- switch schedules
- firewall rule sets
- remote access procedures
- vendor package interface details
- system functional design specifications
- backup and recovery procedures
IEC 62443 uses zones and conduits to structure security architecture.
A zone is a group of assets with similar security requirements.
- safety instrumented system zone
- basic process control system zone
- SCADA zone
- engineering workstation zone
- historian zone
- industrial DMZ
- vendor package zone
- corporate IT zone
Assets in the same zone should normally have similar risk, function, ownership, and security requirements.
A conduit is a controlled communication path between zones.
- firewall connection between SCADA and corporate IT
- remote access path through a jump host
- data transfer from a control system to a historian
- vendor support connection
- interface between package PLCs and the main control system
- connection between safety and non-safety systems
- understand trust boundaries
- reduce unnecessary connectivity
- define firewall and access control requirements
- identify high-risk interfaces
- support risk-based segmentation
- provide a clear basis for testing and verification
- current or proposed network diagrams
- asset list grouped by function
- communication matrix
- protocol list
- firewall rule export or proposed rule table
- remote access path description
- vendor connection details
- interface list between control system packages
- trust boundary assumptions
IEC 62443 uses Security Levels to describe the level of protection required or achieved.
Security Level discussions should be based on risk, consequence, threat exposure, and operational context.
They should not be selected casually or copied between projects without justification.
| Term | Meaning |
|---|---|
| SL-T | Target Security Level. The desired security level for the system, zone, or conduit |
| SL-A | Achieved Security Level. The level actually implemented and verified |
| SL-C | Capability Security Level. The level a product or system is capable of supporting |
| Level | General meaning |
|---|---|
| SL 1 | Protection against casual or accidental misuse |
| SL 2 | Protection against intentional misuse using simple means |
| SL 3 | Protection against intentional misuse using more specialised skills and resources |
| SL 4 | Protection against highly capable attackers with significant resources |
- What would happen if this system was unavailable?
- What would happen if the system was manipulated?
- What would happen if data from the system was exposed?
- Is the system safety-related?
- Is the system connected to corporate IT?
- Is remote access provided?
- Are third-party vendors involved?
- Is the system part of critical infrastructure?
- What is the expected threat environment?
- What level of security can the selected products actually support?
An SL-T target is only useful if it can be designed, implemented, tested, and evidenced.
- product limitations
- legacy equipment
- operational constraints
- maintenance requirements
- cost and programme impact
- available evidence
- testing capability
IEC 62443-3-3 defines seven foundational requirements.
These provide a useful structure for reviewing security controls.
| Foundational Requirement | Practical meaning |
|---|---|
| FR1 Identification and authentication control | Confirming who or what is accessing the system |
| FR2 Use control | Controlling what authorised users and systems can do |
| FR3 System integrity | Protecting systems from unauthorised change or corruption |
| FR4 Data confidentiality | Protecting sensitive data from unauthorised disclosure |
| FR5 Restricted data flow | Controlling communication paths and segmentation |
| FR6 Timely response to events | Detecting, logging, and responding to cybersecurity events |
| FR7 Resource availability | Maintaining system availability and resilience |
- design review questions
- vendor questionnaires
- procurement requirements
- FAT cybersecurity checks
- SAT cybersecurity checks
- evidence matrices
- gap assessments
- hardening reviews
IEC 62443 risk assessment should be practical, evidence-based, and tied to the defined SuC.
A typical process includes:
- 1define the SuC
- 2identify assets
- 3identify threats
- 4identify vulnerabilities
- 5assess likelihood
- 6assess consequence
- 7evaluate risk
- 8define risk treatment
- 9agree security requirements
- 10verify implemented controls
- asset inventory
- network drawings
- system architecture
- data flow diagrams
- operational context
- remote access details
- user and role information
- backup and recovery arrangements
- patching and antivirus approach
- known vulnerabilities
- previous audit findings
- incident history
- safety and operational consequence information
- clear scope statement
- list of assessed assets and interfaces
- risk scenarios
- risk ratings
- recommended mitigations
- assigned actions
- owners and due dates
- link to security levels or security requirements
- evidence required for closure
Risk assessment should not end as a static document. It should drive design changes, implementation work, and verification.
IEC 62443 should be introduced early in the project lifecycle.
Late cybersecurity review often causes avoidable rework.
- define high-level SuC scope
- identify major interfaces
- identify remote access assumptions
- define initial zones and conduits
- identify applicable standards and client requirements
- include cybersecurity in procurement strategy
- develop network architecture
- define firewall and routing requirements
- agree user and role model
- define backup and recovery arrangements
- specify logging and monitoring requirements
- review vendor package security
- map requirements to evidence
- harden devices and operating systems
- configure accounts and permissions
- configure firewalls and switches
- apply secure remote access controls
- document backups
- record software and firmware versions
- prepare test procedures
- asset list accuracy
- user account configuration
- password and authentication settings
- firewall rules
- network segmentation
- disabled unused services
- backup and restore process
- antivirus or allowlisting status
- event logging
- remote access controls
- security-relevant alarms
- configuration records
- installed system matches approved design
- site network connections match agreed architecture
- remote access is controlled and documented
- backups are completed and recoverable
- account ownership is transferred correctly
- residual risks are recorded
- cybersecurity actions are closed or formally accepted
- operations team receives required documentation
IEC 62443 readiness depends heavily on evidence.
The project team should avoid relying on verbal confirmation where objective records are available.
| Evidence area | Example records |
|---|---|
| Scope | SuC definition, architecture drawings, interface list |
| Assets | asset register, IP schedule, software list, firmware list |
| Segmentation | zones and conduits diagram, firewall rules, switch config |
| Access control | user list, role matrix, account ownership record |
| Remote access | remote access procedure, jump host configuration, approval records |
| Hardening | hardening checklist, disabled services list, baseline configuration |
| Backup and recovery | backup schedule, restore test evidence, recovery procedure |
| Monitoring | log source list, alarm/event records, monitoring configuration |
| Vulnerability management | patch records, vulnerability review, exception register |
| Testing | FAT/SAT test sheets, punch list, action tracker |
| Handover | final documentation pack, residual risk register, acceptance record |
These issues are common because many industrial systems were designed for reliability and availability before cybersecurity was treated as a core engineering requirement.
- unclear SuC boundary
- incomplete asset register
- poor separation between IT and OT networks
- flat control system network
- unmanaged remote access
- shared local administrator accounts
- weak password management
- incomplete backup evidence
- no restore test evidence
- undocumented vendor connections
- outdated drawings
- unclear firewall ownership
- limited logging
- missing patch and vulnerability process
- cybersecurity not included in FAT/SAT
- no formal residual risk acceptance
Use this checklist before an IEC 62443 workshop, design review, or cybersecurity assessment.
- SuC boundary is defined
- system owner is identified
- maintenance owner is identified
- vendor responsibilities are understood
- third-party interfaces are listed
- network architecture drawing is available
- control system architecture drawing is available
- zones and conduits are drafted
- trust boundaries are understood
- remote access routes are identified
- asset register is available
- IP address schedule is available
- software and firmware versions are recorded
- critical assets are identified
- obsolete or unsupported assets are flagged
- user roles are defined
- privileged accounts are listed
- shared accounts are identified
- vendor accounts are controlled
- account ownership is documented
- firewall rules are documented
- unused services are disabled where practicable
- hardening requirements are defined
- patching approach is documented
- antivirus or allowlisting approach is documented
- backup procedure is documented
- restore testing is evidenced
- incident response contacts are known
- recovery priorities are understood
- residual risks are recorded
- FAT cybersecurity checks are included
- SAT cybersecurity checks are included
- evidence requirements are agreed
- action tracker is maintained
- handover pack requirements are defined
A realistic IEC 62443 readiness roadmap may look like this:
- 1define the SuC
- 2gather architecture and asset evidence
- 3identify zones, conduits, and trust boundaries
- 4review remote access and third-party interfaces
- 5perform risk assessment
- 6agree SL-T expectations
- 7map requirements to design controls
- 8implement hardening, segmentation, access control, and backup controls
- 9verify controls during FAT and SAT
- 10close or accept residual risks
- 11maintain records through operation and future change
IEC 62443 readiness is mainly about clarity, evidence, and risk-based engineering.
- what system is in scope
- which assets and interfaces matter
- how the system is segmented
- what security level is being targeted
- what controls are required
- how those controls will be verified
- what evidence proves the system has been implemented as intended
The earlier this work starts, the easier it is to avoid late rework and produce a defensible cybersecurity assurance pack.
Related services and problems
Continue through related service, problem and resource pages for the same OT cybersecurity topic.
Discuss practical OT cybersecurity evidence
Use a technical discovery call to frame the system boundary, known constraints and the evidence needed before sharing sensitive site details.