IEC 62443: Product and Component Security for Industrial Systems
IEC 62443 is a family of standards for industrial automation and control system (IACS) security. For this handbook, the most relevant parts are the product-development and component-security expectations that affect connected products, industrial controllers, gateways, firmware, components, update mechanisms, vulnerability handling, and lifecycle support.
Use this page when industrial, OT, automation, embedded, or connected-product assurance is the reason for action.
This page focuses on handbook-relevant implications of IEC 62443, especially IEC 62443-4-1 and IEC 62443-4-2. It does not summarise the whole IEC 62443 family, and it is not a certification guide.
This page is based on the IEC 62443-4-1:2018 and IEC 62443-4-2:2019 publication pages listed below. It was last reviewed against the linked official IEC sources on 2026-07-01. It interprets supply chain security implications for this handbook and is not a complete IEC 62443 implementation or certification guide.
Official references
Use the official IEC sources for publication scope, edition, corrigenda, and purchasing information.
- IEC 62443-4-1:2018, Secure product development lifecycle requirements.
- IEC 62443-4-2:2019, Technical security requirements for IACS components.
- IEC 62443 series overview, for broader IEC context.
Who should care
This page is relevant to:
- Manufacturers and product-security teams building connected industrial, automation, OT, embedded, or control-system products.
- Suppliers providing components, firmware, software, modules, gateways, update services, or maintenance services for industrial systems.
- Buyers, asset owners, integrators, and operators asking for product and component assurance evidence.
- Implementers translating lifecycle, component-security, patching, and vulnerability expectations into mechanisms and records.
Scope and supply chain relevance
IEC 62443 can shape supply chain security work when industrial or connected products need evidence of secure product development, component security capability, vulnerability handling, patch management, end-of-life handling, or responsibility boundaries between supplier, integrator, and user.
For this handbook, IEC 62443-relevant supply chain work usually centers on secure product development lifecycle evidence, component security requirements, product and component acceptance, defect and vulnerability handling, patch management, support and end-of-life planning, and evidence ownership across suppliers and integrators.
IEC 62443-4-1 is primarily about the developer and maintainer's secure product development lifecycle. Integrator, operator, and asset-owner responsibilities may arise through other parts of the IEC 62443 family, contracts, system design, or customer assurance expectations.
For supply chain security, scope questions usually become evidence questions:
- Which product, component, firmware version, release, or service is being assessed?
- Which IEC 62443 part or requirement is being used as the driver?
- What secure development, component-security, patch, vulnerability, acceptance, or lifecycle evidence needs to be retained?
This page does not decide IEC 62443 scope or certification status. It highlights the product and component assurance work that IEC 62443 can drive.
Relationship to other standards and drivers
IEC 62443 is industrial-product and system-security-led. It can provide product-development, component-security, patching, vulnerability, and lifecycle vocabulary for connected products used in industrial and operational environments.
It may interact with:
- EU Cyber Resilience Act, where products with digital elements need secure development, vulnerability handling, update, support, and technical documentation evidence.
- NIST SSDF, where secure software or firmware development practices need reviewable evidence.
- NIST SP 800-161, where supplier, component, and acquisition risks need a C-SCRM operating model.
- Technology Options for identity, attestation, transparency artifacts, signing, update, recovery, exchange, and retention mechanisms.
Threats and failure modes addressed
IEC 62443-relevant practices can help reduce supply chain failures such as:
- insecure product development practices create vulnerabilities before release
- component security capabilities are assumed but not evidenced
- industrial products are accepted without product, firmware, or component trust evidence
- patch and update responsibilities are unclear
- defect or vulnerability handling does not connect to affected products
- end-of-life or support limits are not visible to buyers or operators
- integrator, supplier, and user responsibilities are unclear
- component or firmware provenance is not retained for later audit or incident response
IEC 62443 areas mapped to supply chain controls and evidence
| IEC 62443-related area | Supply chain threat or failure mode | Practices & controls | Evidence to retain or request |
|---|---|---|---|
| Secure product development lifecycle IEC 62443-4-1 | Vulnerabilities are introduced through weak requirements, design, implementation, verification, or release governance. | Secure development and release governance, supplier input review, release approval. | Secure development lifecycle records, security requirements, design review records, verification and validation records, release approvals. |
| Patch management and end-of-life IEC 62443-4-1 | Products remain in use without clear patch, update, support, or end-of-life commitments. | Secure update and lifecycle monitoring, support-period tracking, customer notification. | Patch policy, update records, support and end-of-life statements, maintenance plans, customer notifications. |
| Component security requirements IEC 62443-4-2 | Components are accepted without evidence of expected identity, capability, configuration, or support state. | Product acceptance, component trust checks, acceptance criteria, lifecycle baseline. | Component evidence, product acceptance records, firmware manifests, configuration records, support status, exception records. |
| Component capability security levels and acceptance criteria IEC 62443-4-2 | Component security capability claims are treated as generic labels rather than scoped acceptance requirements. | Scope and requirement mapping, product acceptance criteria, verifier review. | Scope statements, requirement mappings, test results, acceptance decisions, known limitations. |
| Defect and vulnerability handling IEC 62443-4-1 | Defects or vulnerabilities are not triaged, remediated, communicated, or tied to affected versions. | Software, component, and vulnerability management; secure update approval; status communication. | Defect records, vulnerability triage, affected-version analysis, remediation records, signed update packages, customer advisories. |
| Supplier, integrator, and user boundaries IEC 62443 series overview | Evidence ownership and responsibility are unclear across supplier, integrator, asset owner, or operator. | Responsibility matrix, evidence ownership, acceptance and handover workflow. | Responsibility matrix, handover records, acceptance packages, retained evidence locations, exception and risk-acceptance records. |
What to do next
- Use Product Acceptance to decide what evidence supports accepting industrial products, components, firmware loads, or services.
- Use Secure Development and Release Governance, Software Component and Vulnerability Management, and Secure Updates and Lifecycle Monitoring to turn IEC 62443-driven expectations into operating practices.
- Use Product Acceptance Package, Secure Update Approval, and Component Provenance Example to see how evidence can support product and component decisions.
- Use Trust Anchors and Device Identity, Attestation and Measured State, SBOM, VEX, and Component Visibility, and Secure Update and Recovery Mechanisms for implementation mechanisms.
- Use Evidence Checklist to keep IEC 62443-related evidence scoped, verifiable, retained, and tied to decisions.