From 11 December 2027, every product with digital elements placed on the EU market must comply with the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847). For manufacturers of industrial networked devices – sensors, edge controllers, gateways, PLCs – the obvious question follows: if you're already developing against IEC 62443-4-1 and 62443-4-2, how much of the CRA groundwork is already done?
The short answer: most of it – but not all of it. The gaps are real but manageable, and knowing exactly where they are saves significant rework down the line.
What the CRA Actually Requires
The CRA is the EU's first horizontal legislation making cybersecurity mandatory for products with digital elements. It applies to any hardware or software that can connect – directly or indirectly – to a network or another device. In practice, that means virtually every industrial sensor, controller, or gateway carrying Ethernet, Wi-Fi, Bluetooth, or a serial interface.
The requirements fall into two buckets:
Annex I, Part I – Product Properties: Before the product ships, it must meet specific technical criteria: no known exploitable vulnerabilities, secure default configuration, an update mechanism, access control, data encryption, minimal attack surface, and more.
Annex I, Part II – Vulnerability Handling: After market placement, the manufacturer must actively identify, remediate, and report vulnerabilities for the product's entire support lifetime – a minimum of five years.
Beyond the technical side, there are regulatory obligations around documentation, reporting, and CE marking that no technical standard currently covers.
IEC 62443-4 in a Nutshell - Cybersecurity standard for industrial control systems
These parts of the standards are relevant for manufacturers of industrial devices.
IEC 62443-4-1 defines how a development organization must structure its processes to produce secure products. It covers eight Practice Areas – from security management and requirements specification through secure design, implementation, and testing down to patch management. Each area has three maturity levels. A 62443-4-1 certification confirms that those processes exist and are verifiably followed.
IEC 62443-4-2 specifies what the finished product must actually do. Requirements are organized by component type (embedded device, host device, network device, software application) and Security Level (SL 1–4). Most industrial devices target SL 2, covering protection against intentional but unsophisticated attacks. Requirement categories span authentication, access control, integrity, data confidentiality, restricted data flow, event response, and resource availability.
Where 62443-4 and the CRA Overlap
Applying both standards cover the technical and process-level core of the CRA almost entirely.
On the process side, the CRA's vulnerability handling obligations under Annex I Part II largely mirror what 62443-4-1 already requires under Patch Management and Defect Management: structured processes for identifying and remediating vulnerabilities, regular security testing, and due diligence on third-party and open-source components.
On the technical side, an embedded device meeting IEC 62443-4-2 EDR SL 2 already satisfies most of the CRA's Annex I Part I product requirements: authentication and access control (IAC), data encryption in transit and at rest (DC), minimal attack surface through disabled unused services (RDF/SI), and an update mechanism (TRE).
Put simply: 62443-4-2 SL 2 and CRA Annex I Part I are largely pointing at the same set of technical controls.
The Gap Analysis: Four Areas That Still Need Work
Despite the strong overlap, four gaps consistently show up when mapping 62443-4 against the CRA.
Gap 1: EU Regulatory Market Obligations
IEC 62443 is a technical standard, not EU law. It has no concept of CE marking or the EU Declaration of Conformity. These obligations are CRA-only.
The EU Declaration of Conformity must identify the product, manufacturer, applied standards, and the conformity assessment module used – and must be retained for ten years.
The CE mark may only be affixed after the conformity assessment is complete. It signals not just technical compliance but fulfillment of all regulatory obligations.
The conformity assessment procedure depends on the product category. Default products (~90% of all products with digital elements) can self-assess under Module A. Important Class I products require self-assessment against a harmonised European Standard or, in the absence of one, involvement of a Notified Body. Important Class II and critical products require an external Notified Body assessment.
One important caveat: IEC 62443-4-1/-4-2 are not yet referenced as harmonised European standards in the EU Official Journal. Until they are, 62443 certification doesn't trigger presumption of conformity for Important Class I products. CEN/CENELEC harmonisation work is underway – this is a development worth tracking closely.
Gap 2: ENISA Reporting Obligations
This is operationally the most demanding gap, and IEC 62443 offers no equivalent. From 11 September 2026, CRA Article 14 reporting obligations apply.
When an actively exploited vulnerability in a shipped product becomes known, the clock starts: 24 hours for an early warning to ENISA and CERT-Bund, 72 hours for a detailed notification including product identification, vulnerability description, and interim measures, 14 days after a corrective measure becomes available for a final report with full technical details, CVSS score, and patch information.
Meeting those deadlines requires a functioning Product Security Incident Response Team - PSIRT - before the product goes to market – a publicly accessible reporting channel and an internal triage process capable of acting within 24 hours.
Gap 3: Machine-Readable Software bills of materials (SBOM)
CRA Annex I Part II explicitly requires a machine-readable SBOM covering at minimum the top-level dependencies. BSI TR-03183-2 specifies the formats: SPDX 3.0.1 or CycloneDX 1.6.
IEC 62443-4-1 has no comparable artifact requirement. Organizations following 62443 typically maintain a component list, but not a standardized, machine-readable SBOM document.
For an embedded device, this means every software component – RTOS, TCP/IP stack, cryptographic library, bootloader, BSP drivers, open-source utilities – must be captured with name, version, supplier, PURL or CPE identifier, license, artifact hash, and dependency relationships. Crucially, the SBOM is not a one-time document: it must be updated with every release and fed into an ongoing CVE matching process.
Gap 4: CRA-Specific Product Requirements
A few CRA product requirements go beyond what 62443-4-2 mandates.
Automatic updates enabled by default – with a clearly accessible opt-out. 62443-4-2 requires an update mechanism but says nothing about its default state.
Secure by default with factory reset capability – users must be able to reset the product to its original secure configuration. 62443-4-2 addresses secure configuration but not this specific reset requirement.
Free security updates throughout the entire declared support period. This commercial obligation has no 62443 equivalent.
Declared support period – communicated on packaging, in accompanying documentation, or on the manufacturer's website. For industrial devices with long service lives, five years is often a floor, not a ceiling.
From 62443-4 to CRA Compliance: The Practical Steps
For organizations already implementing or working toward IEC 62443-4-1/-4-2, the path to CRA compliance is an extension – not a parallel project.
Step 1 – Classify the product. Default, Important Class I, Important Class II, or critical – the classification determines the conformity assessment route and should be resolved early, ideally with legal input.
Step 2 – Integrate SBOM generation into the build pipeline. Tools like Syft, Trivy, sw360, or Microsoft Component Governance can produce SPDX or CycloneDX artifacts directly from the build. Pair this with automated CVE matching against NVD and OSV, and route new hits to the PSIRT automatically. This makes the SBOM a living security tool, not just a compliance checkbox.
Step 3 – Build and operate the PSIRT before market entry. Minimum requirements: a public reporting channel (dedicated email alias with PGP key plus a web form), an internal triage process capable of acting within 24 hours, security advisory templates, and a defined patch release process including OTA delivery for security-critical fixes.
Step 4 – Create Technical Documentation per CRA Annex VII. This means: a product description with intended use and technical specifications, a documented cybersecurity risk assessment (identified assets, threats, evaluated and accepted risks, implemented controls), a system architecture covering all hardware and software components and interfaces, a description of vulnerability handling processes, and user documentation per Annex II. Everything must be retained for ten years.
Step 5 – Create User Information per Annex II. Manufacturer identification, unique product identification, a web address for security information and updates, known operational risks, key security properties, declared support period, and guidance for secure commissioning. This goes into the product documentation.
Step 6 – Conduct the conformity assessment and affix the CE mark. For Default-category products, a manufacturer self-assessment and EU Declaration of Conformity suffice. For Important Class I, track CEN/CENELEC harmonisation: once 62443-4-1/-4-2 are referenced in the EU Official Journal, certification against them will provide presumption of conformity and eliminate the Notified Body requirement.
Step 7 – Maintain compliance post-market. Monitor new CVEs against the SBOM components, update the risk assessment as threats evolve or the product changes, keep Technical Documentation current, and continue operating the PSIRT throughout the declared support period.
The Bottom Line
IEC 62443-4-1 and 62443-4-2 are a solid foundation. Manufacturer consistently applying those standards have already covered most of the technical and process-level substance of the CRA.
The remaining gaps – machine-readable SBOM, ENISA reporting with PSIRT, EU conformity documentation, CE marking, and a handful of CRA-specific product requirements – are none of them technically exotic. They can be closed systematically, and most integrate naturally into an existing 62443 development workflow.
The strategic case for combining IEC 62443-4 certification with CRA compliance is straightforward: it satisfies EU regulatory obligations while simultaneously meeting the growing market demand from industrial customers who increasingly include 62443 compliance in tenders and supplier qualification criteria.
Sources: CRA Regulation (EU) 2024/2847 · BSI TR-03183-1 v0.10.0 · BSI TR-03183-2 v2.1.0 · BSI TR-03183-3 v1.0.0 · IEC 62443-4-1:2018 · IEC 62443-4-2:2019
