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
- What applies when
- Industry Resources
- Checklist for Industrial Automation
- Frequently Asked Questions
Most PLCs, SCADA systems, and DCS products are standard in-scope products. They are not automatically Important or Critical. Classification follows the product's core function, not the sector it works in. A production-control PLC stays Default. A PLC marketed with a built-in industrial firewall moves to Class II. IEC 62443 gives you a strong technical base for the CRA. The gap to close is SBOM: IEC 62443 never required one.
This guide covers CRA compliance for industrial automation manufacturers.
Summary
- Most PLCs, SCADA, and DCS products are standard in-scope (Default category). Products with a VPN, firewall, IDS/IPS, routing, or security-chip function as their core marketed feature move into Important categories.
- IEC 62443 certification significantly supports CRA compliance (not automatic equivalence).
- OT environments have unique update and lifecycle challenges.
- The support period must reflect expected product lifetime (Article 13(8)). Five years is the floor, not a default planning assumption.
- SBOM requirements apply to industrial control systems. IEC 62443 has no equivalent requirement.
- 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) (actively exploited vulnerability track). Article 14 runs two parallel reporting tracks: the vulnerability track above, and a severe-incident track with a 24 h / 72 h / 1 month cadence (final report due within one month of the 72-hour incident notification, per Article 14(4)(c)).
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
Classification is determined by core marketed functionality, not by where the product is installed (Article 7(1)). A PLC in a nuclear plant is Default if its core function is industrial control. A router in an office is Important Class I if it connects to the internet. Sector does not determine class. Function does.
| Class | What triggers it | Conformity route | Industrial examples |
|---|---|---|---|
| Critical | Core functionality matches Annex IV: Hardware Devices with Security Boxes; smart meter gateways or other devices for advanced security purposes including secure cryptoprocessing; smartcards and secure elements | European certification scheme; or Module B+C / Module H where no scheme applies (Art. 32(4)) | A hardware appliance in a tamper-evident security box; smart meter gateway as defined in Directive (EU) 2019/944; industrial secure element or smartcard |
| Important Class II | Core function is: firewall or IDS/IPS (Annex III Class II item 2); tamper-resistant microprocessor (item 3); tamper-resistant microcontroller (item 4) | Module B+C or Module H. Notified Body required. Or a certification scheme at 'substantial' assurance level (Art. 32(3)) | Industrial firewalls, industrial IDS/IPS; tamper-resistant microprocessors and microcontrollers when the device itself is the security product |
| Important Class I | Core function is: VPN (item 5); network management (item 6); SIEM (item 7); router, modem intended for the internet, or switch (item 12); security-related microprocessor (item 13) or microcontroller (item 14) | Module A (self-assessment) only if harmonised standards or common specifications are fully applied. Otherwise Module B+C or Module H (Art. 32(2)) | Products with VPN as core function; industrial routers and switches connecting to the internet; products built around a security-related microcontroller |
| Default (standard in-scope) | Any product with a digital element not matching a higher category above. Most PLCs, SCADA, and DCS products fall here. | Module A: internal control, self-assessment | PLCs, SCADA software, DCS, most IIoT gateways, industrial PCs, HMIs, engineering workstations |
A PLC that contains a microcontroller with security-related functionalities does not itself become Important Class I because of that component. Article 7(1) is explicit: "The integration of a product with digital elements which has the core functionality of a product category set out in Annex III shall not in itself render the product in which it is integrated subject to the [Important] conformity assessment procedures." Check what the product itself is marketed and designed to do. Consult the product-classification guide for the full decision flow.
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. IEC 62443 has no equivalent.
- Actively exploited vulnerability reporting: 24 h early warning → 72 h vulnerability notification → final report within 14 days after a corrective or mitigating measure is available. Both CSIRT designated as coordinator and ENISA receive notifications simultaneously via the ENISA Single Reporting Platform.
- Severe incident reporting: same 24 h / 72 h early tracks, but the final report is due within one month after the 72-hour incident notification, not 14 days. An incident is severe when it negatively affects availability, authenticity, integrity, or confidentiality of important functions, or leads to malicious code execution (Article 14(5)).
- User notification: after becoming aware of an actively exploited vulnerability or severe incident, manufacturers must inform impacted users, and where appropriate all users, of the vulnerability or incident and any mitigation or corrective measures they can take.
- CE marking and EU Declaration of Conformity.
- Support period that reflects expected product lifetime, with five years as the minimum floor under CRA Article 13(8).
- Specific documentation format requirements (Annex VII).
- Market surveillance coordination.
Leveraging IEC 62443 for CRA
If you already hold IEC 62443-4-1 or 4-2, you are not starting from scratch. You have something most software manufacturers don't: a documented SDL and tested security capabilities. The practical question is whether IEC 62443 will eventually become a CRA harmonised standard under Mandate M/606. If it does, Important Class I manufacturers could use Module A without a Notified Body. That is not settled yet. Check the harmonised standards status tracker before planning your conformity route.
- 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 for both the vulnerability and severe-incident tracks, 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 throughout the support period. The minimum is five years, and longer where the product is expected to be in use for longer (CRA Article 13(8)).
- A mechanism to deliver updates must exist. Continuous online connectivity is not required, but the capability must be there.
- Vulnerabilities must be fixed in reasonable time.
The update obligations are real, but the CRA does not mandate a specific delivery channel. The challenge is designing the channel to work inside OT constraints. See the security-updates guide for delivery mechanics across embedded, standalone, and air-gapped architectures.
- 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.
The support period must reflect the length of time the product is expected to be in use, taking into account reasonable user expectations, the nature and intended purpose of the product, and relevant Union law. Five years is the absolute floor. For a product expected to be in use for less than five years, the support period equals that shorter expected use time. For industrial products with 15 to 20 year deployed lifecycles, five years is the starting point, not the plan. Plan the support period from the customer's perspective, not from 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 and hardware components. Bootloader, device firmware, and field-programmable components. Industrial products often have hardware components with embedded firmware that belong in the SBOM. An HBOM (Hardware Bill of Materials) documents hardware components and their associated firmware. Consider whether your product needs one alongside the software SBOM.
- 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 for both reporting tracks, a documented support-period commitment reflecting expected product lifetime (five-year floor per Article 13(8)), and user documentation.
Industry-Specific Guidance
| Product type | Typical CRA class | Key requirements | IEC 62443 alignment | Watch-outs |
|---|---|---|---|---|
| Product typePLCs and controllers | Typical CRA classDefault (standard in-scope) in most cases. A PLC with a built-in VPN, firewall, or IDS/IPS as its core marketed function moves into Important. | Key requirementsSecure-boot capability, encrypted communications, strong authentication, audit logging, firmware-update mechanism, SBOM for firmware and runtime. | IEC 62443 alignmentIEC 62443-4-2 SL2+ maps well to the essential requirements; document security capabilities and test security functions as evidence. | Watch-outsReal-time constraints versus security processing; safety-function protection; legacy-protocol support (Modbus and others); do not conflate the PLC's class with any Annex III component inside it. |
| Product typeSCADA / DCS software | Typical CRA classDefault (standard in-scope) in most cases. SCADA and DCS are not listed in Annex III. If the product's core function is a network-management system or SIEM-like security monitoring, an Important Class I analysis is warranted. | 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 classCase-specific. A gateway whose core marketed function is VPN, internet-connected routing, or network management may be Important Class I. A gateway that primarily collects and forwards sensor data is likely Default. | 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.
What applies when
Products already on the market
If your product was placed on the EU market before 11 December 2027, you do not need to retrofit a conformity assessment, technical file, or CE marking. The cutoff is when the product was placed on the market, not when it was manufactured. A unit of an existing product line that you place on the EU market from 11 December 2027 onwards must be fully CRA-compliant at point of sale.
The transitional exemption does not cover vulnerability reporting. From 11 September 2026, you must report actively exploited vulnerabilities and severe incidents for every in-scope product you become aware of, including products already on the market. You must also notify impacted users of vulnerabilities and the corrective measures they can take. A large installed base is not an exemption.
Modifying an existing product
A modification is substantial if it affects compliance with the essential cybersecurity requirements or changes the intended purpose the product was assessed against. A substantially modified product re-enters full CRA compliance from the point it is placed back on the market. The person who makes the modification and places the product back on the market becomes the manufacturer for CRA purposes. This matters for OT system integrators who modify and re-sell third-party products.
The definition exists in the regulation. How it applies to specific OT modifications still needs Commission guidance.
Class II and Critical products: start finding a Notified Body now
Member States are expected to have sufficient notified body capacity in place by December 2026. Capacity may still be constrained in the early transition period. A delay in securing a Notified Body will push back your CE marking timeline. Do not leave this to 2027.
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 documented and operational.
- Coordinated vulnerability disclosure (CVD) policy published.
- ENISA Single Reporting Platform (SRP) registered and reporting tested. It covers both the actively exploited vulnerability track (14-day final report) and the severe incident track (1-month final report).
- User notification process in place for vulnerabilities and severe incidents (Article 14(8)).
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)).
If you already hold IEC 62443 certification, you are ahead of most software manufacturers walking into the CRA. The SDL, access controls, audit logging, and vulnerability-handling process all translate directly. The real work is the three things IEC 62443 never needed: an SBOM, a formal reporting channel to ENISA, and a published support-period commitment. Those gaps are real, but they are manageable.
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.
Which industrial automation products fall into Important Class II?
Industrial firewalls, industrial IDS/IPS systems, and tamper-resistant microprocessors and microcontrollers (when the device itself is the security product) 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 connecting to the internet, are Important Class I. For Critical products, Annex IV covers three categories: Hardware Devices with Security Boxes (item 1), smart meter gateways and other devices for advanced security purposes including secure cryptoprocessing (item 2), and smartcards and secure elements (item 3). Each category requires its own Annex IV analysis. 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. 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?
IEC 62443 does not require an SBOM. The CRA does. It also does not cover the two CRA Article 14 reporting tracks: the actively exploited vulnerability track (24 h early warning, 72 h notification, final report within 14 days after a fix is available) and the severe incident track (24 h early warning, 72 h notification, final report within one month after the 72-hour notification). After becoming aware of either, you must notify impacted users, and where appropriate all users, of the vulnerability or incident and corrective steps (Article 14(8)). CE marking with an EU Declaration of Conformity and a documented support period reflecting expected product lifetime are also required. IEC 62443 evidence can support your technical file, but none of these obligations are covered by the standard.
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 for both reporting tracks, a support-period commitment reflecting expected product lifetime, and user documentation on top. See the conformity-assessment decision guide for the full module comparison.
Our PLC has no internet connection. Is it still in scope?
Most air-gapped PLCs are still in scope. The CRA scope test is based on the product's intended purpose or reasonably foreseeable use, not on how it is connected at runtime. A PLC with an Ethernet programming port or a USB interface is in scope even if it never touches a live network in deployment. Very few industrial products have no connection capability whatsoever.
Being air-gapped is a risk-reduction measure. It belongs in your security risk assessment. It does not remove the CRA obligation.
The internet-connectivity question only matters for classification. Whether a router or modem is Important Class I depends on whether it is intended to connect to the internet. That is a classification rule. It has no bearing on whether your PLC is in scope.
This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.
Related Articles
CRA for German Manufacturers: BSI, CERT-Bund and CE Marking
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.