IEC 62443 — Industrial cybersecurity
Understand the roles, zones, conduits, security levels and secure product lifecycle used to protect industrial automation and control systems.
After this module, you should be able to:
- Describe the IEC 62443 family and stakeholder roles
- Use zones and conduits to structure risk analysis
- Distinguish system and component security requirements
- Connect secure development with operational defence
Study guide · Updated · About 8 minutes reading + 20–30 minutes practice
Before you start: Read TEA-110 and TEA-207. Understand the difference between a product supplier and an installed-system operator.
Industrial cybersecurity is a shared system responsibility.
The IEC 62443 series addresses cybersecurity for industrial automation and control systems across asset owners, service providers, system integrators and product suppliers. Different parts cover policy, system requirements, secure development and component capabilities.
Zones group assets with common security needs; conduits control communications between zones. Security levels express required resistance against classes of attacker capability. A component capability does not by itself establish the achieved security of the installed system.
Translate the framework into controlled engineering work.
| Area | Question | Typical evidence |
|---|---|---|
| Risk and policy | What assets, threats, consequences and governance apply? | Cybersecurity management and risk records |
| Zones and conduits | Which assets share needs and how may information cross boundaries? | Security architecture |
| System requirements | What foundational controls and target levels are needed? | System security requirements |
| Product development | How are threats, defects, updates and disclosure managed? | Secure development lifecycle evidence |
| Operations | How are access, monitoring, backups and patching sustained? | Operational procedures and records |
Apply the current controlled source
This module is an orientation. Confirm the applicable edition, amendments, adopted regional version, contractual commitments and sector-specific interpretations before defining compliance.
Use a risk-based application sequence.
- 1. Identify the industrial function, consequence, assets and responsible organisations
- 2. Partition assets into zones and define necessary conduits
- 3. Assess risk and set target security requirements and levels
- 4. Allocate controls to products, system configuration and operational procedures
- 5. Verify the integrated system, including remote access and degraded operation
- 6. Maintain vulnerability monitoring, patch qualification and incident response
Worked application: remote maintenance gateway
The gateway sits in a conduit between an enterprise network and a control zone. Requirements cover mutual authentication, least privilege, session control, logging and safe loss of connectivity. The product supplier provides secure update capability; the integrator configures it; the asset owner governs accounts and monitors use.
Build evidence that explains the reasoning.
Roles, lifecycle, risk decisions and governance.
Assets, boundaries and permitted communications.
System, component and operational controls.
Threats, coding, verification, vulnerabilities and updates.
Configured identities, access paths and failure behaviour.
Accounts, monitoring, patches and incident response.
Common failure patterns
Assets are listed without architecture or trust boundaries.
A level is quoted without target context and system allocation.
Asset-owner and integrator responsibilities are omitted.
Monitoring, testing, deployment and recovery are undefined.
Choose the relevant parts and responsible roles
IEC 62443 is a family for industrial automation and control-system cybersecurity. Its coverage spans asset owners, service providers, system design and product development. Part 4-1 concerns secure product-development processes; Part 4-2 concerns technical component requirements. System risk assessment and system requirements are addressed elsewhere in the family, including Parts 3-2 and 3-3.
Start by deciding what is being assessed: an embedded component, the supplier’s development lifecycle or an installed automation system. A product claim cannot establish the security of an installation whose network, accounts and maintenance practices differ from the assumed environment.
Agree responsibilities in the supply chain. The supplier may provide secure update capability and hardening instructions; the operator may need to manage accounts, configuration and deployment. An assumption that the other party handles a control should become an explicit, accepted obligation.
Connect zones and conduits to enforceable boundaries
A zone groups assets with common security requirements, while a conduit represents controlled communication between zones. A diagram is useful only if the physical and logical architecture enforces its intended restrictions. A maintenance laptop connected around the firewall can invalidate the picture.
Define allowed information flows, identities, services and failure behaviour. Include management access, time services, backups and update distribution. Examine what happens when a shared network is unavailable or a less-trusted device sends excessive valid traffic.
Security levels need context: target, capability and achieved properties are not interchangeable labels. Do not treat a security level as a functional-safety SIL. Link the security objectives and assessment to the relevant requirements, environment and evidence.
| Scope | Example supplier or operator evidence |
|---|---|
| Product lifecycle | Threat analysis, secure design, verification and vulnerability handling. |
| Component capability | Identity, access, integrity, communication and availability behaviour. |
| Installed system | Zones, conduits, configuration and allowed information flows. |
| Operation | Account management, monitoring, patching and recovery procedures. |
Verify the product in its assumed operating environment
Turn product security assumptions into integration checks. If a component depends on an external identity service, defined network isolation or restricted physical access, verify the dependency and describe the response when it is unavailable. Essential local control may need to continue under a specified degraded mode.
Exercise abuse and recovery cases alongside nominal security tests. Check malformed input, resource exhaustion, expired credentials and interrupted updates. Report the exact firmware, configuration and surrounding controls so an integrator can judge whether the result applies to the intended installation.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Assess a gateway marketed as a secure component
A gateway has a supplier security certificate, but a plant installs it with a shared administrator account and unrestricted maintenance access across several production cells.
- Distinguish the component evidence from installed-system security.
- Identify integration assumptions and operator controls to review.
- Define a focused verification sequence for the actual deployment.
Show the worked answer
Review the certificate’s scope, version and conditions before relying on it. Component capabilities do not establish that the installed configuration uses them correctly or that the wider system has suitable boundaries. Examine identity, privileges, maintenance paths, allowed traffic and recovery responsibilities.
Verify that access is attributable and restricted, that cross-cell flows match the approved design and that maintenance cannot bypass required controls. Test loss of supporting services and representative abusive traffic while observing essential operation. Record gaps against the selected system requirements and resolve them with supplier, integrator and asset-owner participation.
Review criteria
- Certificate scope and conditions are examined.
- Shared responsibility is explicit.
- Verification uses the actual installation and operating needs.
Check your understanding
Does a component certificate establish system security?
No. Integration, configuration, surrounding controls and operational responsibilities must also be assessed.
Is an IEC 62443 security level equivalent to SIL?
No. They concern different frameworks and properties; neither should be used as a substitute for the other.
Further learning
- ISA / IEC 62443 seriesOfficial ISA overview of the industrial cybersecurity standards family.
- TEA-110 · Secure embedded developmentThreat modelling, trusted foundations and update strategy.
Use the standard to strengthen decisions, not decorate them.
Make scope, tailoring, responsibilities, technical reasoning and objective evidence explicit—and always work from the current authorised text.