CRA for Industrial Automation: IEC 62443 and OT Security
How the CRA applies to industrial automation and OT: IEC 62443 alignment, why most PLCs and SCADA are default-category, and what raises the class.
In this article
- Summary
- Which Industrial Products Are Covered?
- IEC 62443 and CRA Alignment
- OT-Specific Compliance Challenges
- SBOM for Industrial Systems
- Conformity Assessment for Industrial Products
- Industry-Specific Guidance
- Practical Compliance Roadmap
- Industry Resources
- Checklist for Industrial Automation
- Frequently Asked Questions
Industrial automation products face specific CRA challenges due to their critical role in manufacturing, energy, and infrastructure. Many fall into Important Class II, requiring third-party conformity assessment. Fortunately, the well-established IEC 62443 standard provides a strong foundation for CRA compliance.
This guide covers CRA compliance for industrial automation manufacturers.
Summary
- Many industrial automation products are Important Class II (third-party assessment required).
- IEC 62443 certification significantly supports CRA compliance (not automatic equivalence).
- OT environments have unique update and lifecycle challenges.
- A 5-year minimum support period applies under CRA Article 13(8); plan product lifecycles accordingly.
- SBOM requirements apply to industrial control systems.
- Safety-security integration is critical (IEC 62443 with IEC 61508 / ISO 13849).
Source: Regulation (EU) 2024/2847, Article 13(8) (support period) and Article 14(2)(a)(b)(c) (reporting cadence).
Which Industrial Products Are Covered?
CRA Scope for Industrial Automation
The CRA applies to "products with digital elements" placed on the EU market. For industrial automation, this includes:
Clearly in scope:
- PLCs (Programmable Logic Controllers)
- Industrial PCs and HMIs
- SCADA software
- DCS systems
- Industrial IoT sensors and gateways
- Industrial routers and switches
- Remote access solutions
- Engineering workstations and software
Exemptions may apply:
- Products exclusively for national security
- Products designed for military use
- Custom one-off industrial systems (may qualify as "spare parts")
CRA Classification for Industrial Products
Most industrial automation products fall into Important Class I or II.
The route is a Notified Body (Module B+C or Module H) or an available and applicable certification scheme. Some industrial products have the core functionality of an Annex IV category, such as hardware security modules and smart meter gateways; those are Critical products, a higher tier that also needs third-party assessment.
- Firewalls for industrial use
- Industrial IDS/IPS systems
- Tamper-resistant microprocessors and microcontrollers
Self-assessment is possible when harmonised standards, common specifications, or a certification scheme fully cover the product's requirements.
- PLCs and industrial controllers
- SCADA/DCS software
- Industrial IoT gateways
- Remote access and VPN solutions
- Industrial routers, modems, and switches
- Microcontrollers and microprocessors with security-related functionalities
The manufacturer can usually use internal control where the product has lower security impact.
- Basic sensors with no network capability
- Simple industrial peripherals
- Non-networked equipment
Classification depends on specific product capabilities. Consult CRA Annexes III and IV for definitive classification.
IEC 62443 and CRA Alignment
What Is IEC 62443?
IEC 62443 is the international standard series for Industrial Automation and Control Systems (IACS) security. It covers:
- IEC 62443-4-1: Secure development lifecycle.
- IEC 62443-4-2: Component security requirements (4 Security Levels, SL 1 to SL 4).
- IEC 62443-3-3: System security requirements.
- IEC 62443-2-4: Service provider requirements.
IEC 62443 ↔ CRA coverage at a glance
- Vulnerability handling process
- Access control
- Cryptography
- Audit logging
- Update capability
- Secure by default
- Data protection
- No-known-vulnerabilities proof
- SBOM
- CE marking / Declaration of Conformity
- Article 14 reporting
- Support-period statement
Where IEC 62443 evidence maps directly to CRA requirements, where it covers only part of the obligation, and where the CRA adds new obligations.
IEC 62443 ↔ CRA Mapping
| CRA Requirement | IEC 62443 Coverage | Status |
|---|---|---|
| Secure by default | SL requirements (4-2) | Partial, CRA default stricter |
| Vulnerability handling | 4-1 (SDL), 2-4 (maintenance) | Good alignment |
| Security updates | 4-1, 2-4 | Alignment on process |
| No known vulnerabilities | 4-1 (vulnerability management) | Process aligned |
| Data protection | 4-2 (confidentiality) | Partial |
| Access control | 4-2 (authentication, authorisation) | Strong alignment |
| Cryptography | 4-2 (encryption requirements) | Good alignment |
| Audit logging | 4-2 (audit logs) | Good alignment |
| Update capability | 4-2 (firmware update) | Alignment |
| SBOM | Not in IEC 62443 | Gap |
| CE marking | Not in IEC 62443 | Gap |
| 5-year support | Not specified | Gap |
IEC 62443 as Foundation, Not Equivalence
IEC 62443 certification does NOT automatically mean CRA compliance. Use it as foundation and evidence, not as equivalence.
What IEC 62443 provides:
- Strong technical security foundation.
- Mature security development lifecycle.
- Well-documented security capabilities.
- Evidence for conformity assessment.
What CRA adds beyond IEC 62443:
- SBOM requirements (new).
- Specific vulnerability reporting to CSIRT designated as coordinator and ENISA (within 24 hours early warning, 72 hours vulnerability notification, and 14 days final report per CRA Article 14(2)).
- CE marking and Declaration of Conformity.
- 5-year minimum support commitment under CRA Article 13(8).
- Specific documentation format requirements.
- Market surveillance coordination.
Leveraging IEC 62443 for CRA
- If you have IEC 62443-4-1 certification. Reuse the SDL documentation for the CRA technical file, demonstrate your secure development lifecycle, and point to it as evidence for the risk-assessment approach.
- If you have IEC 62443-4-2 certification. Reuse the security-capability documentation, map each Security Level achieved to the CRA essential requirements, and present it as evidence for security-function implementation.
- Add the CRA-only items on top. Generate an SBOM, implement ENISA reporting capability, document the 5-year support commitment, prepare the EU Declaration of Conformity, and apply CE marking.
OT-Specific Compliance Challenges
Update and Patching Challenges
Industrial environments have unique constraints on updates.
Challenges:
- 24/7 operations with no maintenance windows.
- Safety-system revalidation after updates.
- Legacy-system integration.
- Air-gapped or semi-connected environments.
- Long qualification cycles.
CRA requirements still apply:
- Security updates must be provided for at least 5 years (CRA Article 13(8)).
- A mechanism to deliver updates must exist.
- Vulnerabilities must be fixed in reasonable time.
- Staged rollout. Test environments first, then pilot production lines, then full rollout with monitoring.
- Update scheduling. Coordinate with planned maintenance, provide advance notice in weeks or months, and support customer-scheduled update cycles.
- Offline delivery. USB-based update packages, update servers inside the OT network, or secure file-transfer mechanisms for air-gapped sites.
- Safety revalidation. Document the update's impact on safety functions, provide revalidation guidance, and consider safety-security co-engineering.
Long Product Lifecycles
Industrial products often have 15 to 20+ year lifecycles, but the CRA requires only 5 years minimum.
Security updates and vulnerability handling are in force for the minimum support period.
Manufacturer may continue to provide security updates beyond the CRA floor, especially when the product is still in use.
Limited updates; more of the operational risk shifts to the customer.
Customer responsibility; communicate end-of-support dates clearly at point of sale.
At least five years from when the product is placed on the market, or longer if the product is expected to be in use for more than five years (Article 13(8)). Plan the support period based on reasonable product lifetime, not just on the CRA floor.
Documentation needs:
- Clearly communicate the support period at purchase.
- Provide an end-of-support date.
- Document customer responsibilities post-support.
Safety-Security Integration
Industrial products often have safety requirements (SIL levels per IEC 61508 / ISO 13849). CRA adds security requirements.
Combined safety and security threat modelling. Treat security threats to safety functions as a first-class failure mode.
Safety requirements (SIL 1 to SIL 4) and security requirements (SL 1 to SL 4) live side by side. No security measure shall compromise safety.
Safety validation, security testing, and combined-scenario testing all run before release. Each discipline signs off independently.
Safety revalidation for security patches. Security assessment for safety changes. Both loops are mandatory, not optional.
No security measure shall compromise safety. Where the two disciplines conflict, safety wins, and the security design changes.
SBOM for Industrial Systems
Component Identification Challenges
Industrial products often contain:
- Real-time operating systems (RTOS).
- Proprietary firmware.
- Third-party libraries (OPC UA, MQTT, Modbus stacks).
- Hardware components with firmware.
- Software components. RTOS and kernel, protocol stacks (OPC UA, Modbus, EtherNet/IP, PROFINET), security libraries (TLS, crypto), third-party middleware, and application software.
- Firmware. Bootloader, device firmware, and field-programmable components.
- Depth. Primary components are manufacturer-controlled; request SBOMs from suppliers for third-party components; go as deep as practically possible into nested components.
Supply Chain Complexity
Industrial products often have complex supply chains.
Your software and firmware. Full SBOM required.
Third-party components. Request an SBOM from each supplier and include it in your own SBOM.
Components within components. Best-effort inclusion. Document known limitations.
Actions:
- Update supplier agreements for SBOM requirements.
- Establish an SBOM exchange format with suppliers.
- Create a process for SBOM integration.
- Document supply-chain limitations.
Conformity Assessment for Industrial Products
Module B+C (EU-Type Examination)
For Important Class II industrial products:
- Module B, Type Examination. The Notified Body examines technical-file completeness, risk-assessment adequacy, security-requirement coverage, any IEC 62443 certification presented as evidence, SBOM quality, and test results. Deliverable: an EU-Type Examination Certificate.
- Module C, Conformity to Type. The manufacturer ensures production matches the examined type, maintains internal QA for production, and keeps documentation up to date. Deliverable: a self-declaration of conformity to type.
Using IEC 62443 Certification
If you have IEC 62443-4-2 certification:
- Present to the Notified Body. Submit the IEC 62443-4-2 certificate, the Security Level achieved (SL 1 to SL 4), the ISASecure certificate if applicable, and the evaluation report.
- Notified Body assessment. The NB recognises IEC 62443 as evidence, verifies coverage of the CRA requirements, identifies any gaps, and may reduce the testing scope.
- Additional evidence still required. SBOM (not covered by IEC 62443), ENISA reporting capability, a documented 5-year support commitment, and user documentation.
Industry-Specific Guidance
| Product type | Typical CRA class | Key requirements | IEC 62443 alignment | Watch-outs |
|---|---|---|---|---|
| Product typePLCs and controllers | Typical CRA classUsually Important Class I or II. | Key requirementsSecure-boot capability, encrypted communications (optional moving to default), strong authentication, audit logging, firmware-update mechanism, SBOM for firmware and runtime. | IEC 62443 alignmentUse IEC 62443-4-2 SL2+ as baseline, document security capabilities, test security functions. | Watch-outsReal-time constraints versus security processing; safety-function protection; legacy-protocol support (Modbus and others). |
| Product typeSCADA / DCS software | Typical CRA classUsually Important Class I. | Key requirementsSecure architecture, role-based access control, encrypted communications, audit trail, update mechanism, SBOM for all components. | IEC 62443 alignmentMap role-based access control, audit, update and communication controls to IEC 62443 system and component requirements. | Watch-outsDatabase security, OPC UA security configuration, historian data protection, remote-access security. |
| Product typeIndustrial IoT gateways | Typical CRA classUsually Important Class I. | Key requirementsSecure boot, network-segmentation support, encrypted protocols (MQTT-TLS and similar), device authentication, firmware-update mechanism, SBOM. | IEC 62443 alignmentUse IEC 62443-4-2 for component security functions and document gateway segmentation assumptions. | Watch-outsEdge-computing security, cloud-connectivity security, protocol-translation security, data filtering and validation. |
Practical Compliance Roadmap
Phase 1: Assessment
Product inventory.
- List all products with digital elements.
- Classify per CRA categories.
- Identify Important Class II products.
Existing certifications.
- List IEC 62443 certifications.
- Map to CRA requirements.
- Identify gaps.
Gap analysis.
- SBOM capability.
- Vulnerability-reporting readiness.
- 5-year support planning.
- Documentation gaps.
Phase 2: Preparation
Technical.
- Implement SBOM generation.
- Establish a vulnerability-handling process.
- Prepare ENISA reporting capability.
- Update product security baselines.
Documentation.
- Technical-file structure.
- Security documentation updates.
- User guidance for secure deployment.
- Support-period communication.
Commercial.
- Support-period definitions.
- Contract updates for customers.
- Pricing review where compliance costs are significant.
Phase 3: Compliance
From 11 September 2026.
- Vulnerability reporting operational.
- Single reporting platform in use.
Through 2027.
- Complete conformity assessments.
- Engage Notified Bodies (Important Class II).
- Obtain EU-Type Examination certificates.
- Update all product documentation.
By 11 December 2027.
- All in-scope products CRA-compliant.
- CE marking applied.
- Customer communication complete.
Industry Resources
Standards Bodies
- IEC (International Electrotechnical Commission). IEC 62443 series. iec.ch
- ISA (International Society of Automation). ISA/IEC 62443 development, ISASecure certification program. isa.org
- NAMUR (Process Industry Association). NE recommendations for OT security. namur.net
- NIST. Cybersecurity Framework, SP 800-82 (OT security guide). nist.gov
Industry Associations
| Association | Focus | Website |
|---|---|---|
| ZVEI (Germany) | Electrical industry | zvei.org |
| ORGALIM | European engineering | orgalim.eu |
| VDMA (Germany) | Machinery | vdma.org |
| GAMBICA (UK) | Industrial automation | gambica.org.uk |
| ODVA | Industrial networks | odva.org |
If you manufacture machinery with digital elements, see our guide for machinery manufacturers for specific guidance on dual compliance with the CRA and the EU Machinery Regulation.
Checklist for Industrial Automation
Product classification
- Classification determined (Default / Important I / Important II).
- Conformity-assessment path selected.
- Notified Body identified, if needed.
Existing certifications
- IEC 62443-4-1 (SDL).
- IEC 62443-4-2 (component security).
- ISASecure certification.
- Mapped to CRA requirements.
Technical compliance
- Security-by-default configuration.
- Secure update mechanism.
- SBOM generation capability.
- Vulnerability-handling process.
- ENISA reporting capability.
Documentation
- Technical file prepared.
- Risk assessment documented.
- Security architecture documented.
- User security guidance prepared.
Lifecycle
- 5-year support period defined.
- Update delivery mechanism.
- End-of-life planning.
- Safety revalidation process for updates.
Supply chain
- Supplier SBOM requirements.
- Component security assessment.
- Supply-chain documentation.
Selling to NIS 2 essential entities can raise risk and evidence expectations, but it does not change a product's CRA class. The class still depends on the product's core functionality under Annex III/IV (Article 7(1)).
IEC 62443 alignment gives you a head start on CRA compliance. Many requirements overlap, reducing your additional compliance burden.
Frequently Asked Questions
Is IEC 62443 certification equivalent to CRA compliance?
No. IEC 62443 certification does not automatically mean CRA compliance. It provides a strong technical security foundation and evidence that a Notified Body can reuse, but the CRA adds obligations that IEC 62443 does not cover: SBOM requirements, ENISA incident reporting under Article 14, CE marking and Declaration of Conformity, and a 5-year minimum support commitment under Article 13(8).
Which industrial automation products fall into Important Class II?
Industrial firewalls, industrial IDS/IPS systems, and tamper-resistant microprocessors and microcontrollers fall into Important Class II, which requires third-party conformity assessment (typically Module B+C or Module H). Microcontrollers and microprocessors with security-related functionalities, and industrial routers and switches, are Important Class I. Hardware security modules and smart meter gateways have the core functionality of Annex IV categories, so they are Critical products. See the product-classification guide for the full decision flow.
Does the CRA's 5-year minimum support period apply even to products with 15 to 20 year industrial lifecycles?
Yes. Five years is the floor set by CRA Article 13(8). Where the product is reasonably expected to be in use for longer, the manufacturer must determine a longer support period to reflect that lifetime. Industrial products with 15 to 20 year lifecycles typically need to plan support well beyond the 5-year floor and communicate the end-of-support date clearly at point of sale.
How do we handle CRA security updates in OT environments with no maintenance windows?
Use a combination of staged rollout (test, pilot, full production), scheduled update windows coordinated with planned maintenance, offline delivery mechanisms such as USB packages or update servers inside the OT network, and documented safety revalidation for each update. The CRA does not require continuous online connectivity, but it does require that a mechanism to deliver updates exists and that vulnerabilities are fixed in a reasonable time.
What CRA requirements are not covered by IEC 62443?
SBOM generation and maintenance, vulnerability and severe-incident reporting to the CSIRT designated as coordinator and ENISA on the 24 hours / 72 hours / 14 days cadence set by CRA Article 14(2), CE marking with an EU Declaration of Conformity, the 5-year minimum support commitment, and market-surveillance coordination. IEC 62443 evidence helps with the technical requirements but does not discharge any of these obligations.
Can IEC 62443-4-2 certification reduce Notified Body testing scope?
Yes, it can. A Notified Body recognising IEC 62443-4-2 as evidence will verify coverage of the CRA requirements, identify any gaps, and may reduce the testing scope accordingly. Present the certificate, the Security Level achieved (SL 1 to SL 4), any ISASecure certificate, and the evaluation report. You still need to supply SBOM evidence, ENISA reporting capability, a documented 5-year support commitment, and user documentation on top. See the conformity-assessment decision guide for the full module comparison.
This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.
Related Articles
Does the CRA apply to your product?
Answer 6 simple questions to find out if your product falls under the EU Cyber Resilience Act scope. Get your result in under 2 minutes.
Ready to achieve CRA compliance?
Start managing your SBOMs and compliance documentation with CRA Evidence.