Regulation (EU) 2024/2847 – Cyber Resilience Act (CRA) establishes horizontal cybersecurity requirements for all products with digital elements placed on the EU market. The EU adopted it in late 2024. Most obligations will apply from 11 December 2027, with 24-hour reporting duties starting earlier in 2026. If you manage industrial products, maintenance, procurement, or compliance, you should map your portfolio, understand who must do what, and plan your engineering and post-market processes now. This guide explains the scope, obligations, timelines, and concrete preparation steps with a technical, hands-on lens.

Table of Contents

Regulation (EU) 2024/2847 – Cyber Resilience Act (CRA): what it changes and why it matters

The CRA closes a regulatory gap. Connected products proliferated faster than secure engineering practices, leaving users exposed to default passwords, unpatched flaws, and opaque support windows. The regulation forces security by design and by default across the product life cycle and removes competitive advantages for vendors who cut corners on security. It also recognizes the cross-border nature of cyber incidents: a single exploited device or software component can spread harm across supply chains within minutes. Common rules aim to reduce systemic risk and raise customer trust in connected products across the EU market.

Scope: which products fall under Regulation (EU) 2024/2847 – Cyber Resilience Act (CRA)?

The CRA covers any product with digital elements made available on the EU market whose intended use involves direct or indirect, physical or logical connection to another device or network. In practice, that includes consumer IoT and electronics (wearables, smartphones, smart home devices), industrial equipment with network functions (sensors, controllers, machines connected to OT/IT networks), and software (operating systems, desktop and mobile apps, embedded firmware, business software). Software supplied on its own counts as a product. Remote data processing services that form an integral part of a product also fall within scope. If your device relies on a cloud backend to operate, you must treat that backend as part of the product’s compliance perimeter.

The scope is broad, but the regulation exempts categories already governed by sectoral regimes with equivalent safeguards. The CRA does not apply to medical devices, motor vehicles and their equipment, aviation products, or marine equipment subject to their dedicated EU rules. Equipment, software, and services developed exclusively for military or national security purposes, including classified information processing, sit outside the CRA as well. Identical spare parts supplied as replacements for components in compliant products are also exempt. Free and open-source software provided outside commercial activity remains out of scope; however, if you incorporate open source into a commercial product, you, as the manufacturer of the finished product, bear full responsibility for CRA compliance.

Why the EU introduced the CRA: evolving threats and supply‑chain blast radius

Connected devices and software multiply attack surfaces. Too many products ship with known vulnerabilities, weak defaults, or no clear update policy. Users and buyers cannot easily assess how long vendors will supply security fixes or whether a device implements baseline protections. That asymmetry increases incident frequency and impact. The CRA sets uniform minimums across the EU so that every product reaches a consistent baseline of hardening, updateability, and transparency. By requiring fast vulnerability remediation and coordinated disclosure, the law also shortens the window of exploitability and improves collective defense across borders.

Regulation (EU) 2024/2847 – Cyber Resilience Act (CRA): core obligations for manufacturers

Manufacturers carry the heaviest obligations. If you place a product on the market under your name or brand, or if you substantially modify a product in a way that affects cybersecurity, you become the manufacturer in the eyes of the CRA. You must design, build, maintain, and document the product so it meets the essential cybersecurity requirements and you must keep it secure throughout its supported life.

Security by design/default: mandatory product controls

Build products to meet the essential cybersecurity requirements from Annex I. Engineer the default configuration to minimize attack surface: ship unique credentials, disable unnecessary services and ports, harden interfaces, and implement least privilege. Remove known vulnerabilities before placing the product on the market. Use strong cryptography where appropriate to protect data at rest and in transit. Implement authentication, authorization, integrity checks, tamper resistance, event logging, and safe factory reset. Design for resilience against denial-of-service and other service-disrupting attacks. Match the level of control to the risk profile of the intended use.

Vulnerability handling, updates, and minimum support window

Set up a vulnerability handling process and keep it running long after product launch. Monitor for new issues, accept external reports, triage, fix, and ship security updates promptly via a secure update mechanism (for example, with digital signatures and rollback protection). Publish a coordinated vulnerability disclosure policy with a clear contact point. Support security updates for the entire expected lifetime of the product and in any case at least five years, unless the very nature of the product justifies a shorter period and you state it transparently. Customers must not end up with unsupported, insecure devices after a year or two of use.

Cyber risk assessment and technical file

Perform and keep an up-to-date cyber risk assessment as part of your design process. Consider intended use, reasonably foreseeable misuse, operational environments (IT/OT networks, exposure, data sensitivity), and adversary capabilities. Document threats, attack vectors, and mitigations. Feed the results into architecture and implementation decisions. Keep the technical documentation for at least 10 years from market placement or longer if your declared support exceeds that. Review and revise the assessment when context or threats change.

Third‑party components and open source governance

Control the risk from external components, both hardware and software, including open source. Maintain an SBOM (Software Bill of Materials) with versions. Track known vulnerabilities and apply updates or replacements. When you discover a vulnerability in an open-source component, notify the maintainers; if you develop a fix, upstream it. Contractually require suppliers to meet security criteria and to notify you promptly about discovered issues. Your product’s security equals the security of its building blocks.

Conformity assessment and CE under Regulation (EU) 2024/2847 – Cyber Resilience Act (CRA)

Before you place a product on the market, complete a conformity assessment and compile technical documentation that demonstrates compliance. For most non‑high‑risk products, an internal control procedure suffices if you apply relevant harmonised standards once available. You then issue an EU declaration of conformity and affix the CE marking. For “important” and “critical” categories listed in Annex III and IV, stricter pathways apply. Important class II and critical products require third‑party assessment by a notified body. Important class I products may use self‑assessment only when appropriate harmonised standards are applied; otherwise, you also need a notified body. Classify your products early and book external assessments to avoid market delays.

Post‑market monitoring and 24‑hour incident/vulnerability reporting

Set up monitoring to detect actively exploited vulnerabilities and serious incidents affecting your product’s security. From 11 September 2026 you must report within 24 hours of becoming aware to the national CSIRT coordinator and to ENISA through the EU platform. This obligation applies to all relevant products on the market at that time, regardless of when you initially sold them. Prepare playbooks, assign roles, and rehearse so you can gather the required facts and submit them on time.

Regulation (EU) 2024/2847 – Cyber Resilience Act (CRA): duties for importers and distributors

Importers act as a security gate. Before making a product available in the EU, they must verify that the manufacturer fulfilled its obligations: CE marking present, EU declaration of conformity available, instructions and safety information included, and technical documentation prepared. If doubts arise, importers must withhold the product until the non‑conformity is resolved. When a product fails to meet CRA requirements, importers must inform market surveillance authorities and coordinate corrective actions or withdrawal.

Distributors must perform similar diligence before resale. They check CE marking, required documentation, and public communications about non‑conformities. If they suspect a serious risk or non‑compliance, they must suspend distribution, alert the manufacturer or importer, and cooperate with authorities on corrective measures. If an importer or distributor markets a product under their own name or modifies it in a way that affects cybersecurity, they assume the role and responsibilities of a manufacturer.

Regulation (EU) 2024/2847 – Cyber Resilience Act (CRA): timelines and transitional periods

Key dates guide your roadmap:

11 June 2026: rules for notified bodies and conformity assessment infrastructure start to apply. Member States must designate and notify bodies so manufacturers can plan certifications for important and critical products.
11 September 2026: the 24‑hour reporting obligation for actively exploited vulnerabilities and serious security incidents starts for all in‑scope products on the market.
11 December 2027: full application. From this date, you cannot legally place a product with digital elements on the EU market unless it complies with the CRA. Units already individually made available before this date can remain in the supply chain, but every new unit placed after must comply. Existing EU type‑examination certificates issued under other regimes remain valid only until mid‑2028 unless they specify an earlier end date.

Treat the end of 2027 as the hard cut‑over for new units. Use 2025–2026 to redesign architectures and processes. Use 2026 to validate your reporting playbooks and, where necessary, to complete external assessments.

Regulation (EU) 2024/2847 – Cyber Resilience Act (CRA): readiness checklist for 2026/2027

Inventory and classify your products. Identify all products with digital elements. Decide whether any fall into important (class I/II) or critical categories in Annex III/IV. This classification drives your conformity route and timelines.
Map requirements to designs. Read Annex I essential requirements and map them to your architectures. Track emerging harmonised standards and relevant industry frameworks (for example, the IEC 62443 family for industrial automation and control systems).
Run a gap analysis. Compare current controls and SDLC practices against CRA expectations. Assess authentication, cryptography, secure boot/update, logging, hardening, penetration testing, fuzzing, and response processes. Identify missing controls and process weaknesses.
Upgrade your Secure SDLC. Embed threat modeling, security architecture reviews, secure coding, code review with security checklists, automated SAST/DAST, fuzzing, dependency scanning, and reproducible builds. Build security acceptance criteria into your definition of done.
Engineer updateability and define a realistic support window. Ensure products can receive secure updates in the field. Plan resources to deliver fixes for at least five years or the expected lifetime. Communicate the support period in product information.
Produce and maintain the technical file. Prepare the cyber risk assessment, security architecture, test evidence, update procedures, and the coordinated vulnerability disclosure policy. Set up long‑term archival. Draft EU declarations of conformity that explicitly cover CRA obligations.
Secure your supply chain. Maintain SBOMs. Update supplier contracts with security clauses and notification duties. Vet cloud backends tied to the product. Align third‑party modules and firmware with your secure update strategy.
Train your teams and inform customers. Train R&D, QA, IT/OT, service, procurement, and sales on CRA roles and procedures. Prepare customer‑facing security information so buyers understand defaults, update policy, and support lifetime.
Plan conformity and certification. Decide early whether you need a notified body. Pre‑test against draft or published standards. Reserve lab capacity well ahead of launch.
Operationalize post‑market surveillance and reporting. Implement telemetry, PSIRT workflows, 24/7 escalation, and the ability to file to ENISA and the national CSIRT within 24 hours. Rehearse incident drills.

Doing this work early prevents 2027 bottlenecks. Teams that institutionalize secure engineering will ship better products, face less rework, and build trust with industrial buyers who increasingly treat cyber as a core quality attribute.

Regulation (EU) 2024/2847 – Cyber Resilience Act (CRA) and the Machinery Regulation (EU) 2023/1230: how they align

The Machinery Regulation targets safety of machinery in the traditional sense: it protects health and safety of users and bystanders. It requires you to consider cyber threats only insofar as they could cause hazardous machine behavior that endangers people. It does not prescribe the full IT security stack, nor does it require multi‑year post‑market security updates.

The CRA covers the broader IT security posture of products with digital elements, including confidentiality, integrity, availability, updateability, vulnerability handling, and reporting. A modern connected machine therefore often falls under both acts. You must meet both sets of requirements and your EU declaration of conformity should reference each applicable legal act. In practice, design for both from day one: engineer functional safety and cybersecurity together, and test both the safety chains and the digital attack surface.

Examples: what falls under which act in practice

Pure IT/consumer electronics. Routers, smartphones, IP cameras, smart speakers: CRA applies; Machinery Regulation does not. Focus on cyber controls, updates, and transparency.
Traditional, non‑connected machines. A hydraulic press with purely local, non‑networked control: Machinery Regulation applies; CRA does not, because the product does not connect. If you later add connectivity, the CRA instantly becomes relevant.
Connected industrial machines. Collaborative robots, AGVs, production lines using IoT sensors, PLCs, and remote monitoring: both apply. You must prevent unsafe states caused by cyber interference and also deliver comprehensive cyber hardening, multi‑year updates, and reporting under the CRA.

Key takeaways for industrial managers

Regulation (EU) 2024/2847 raises the bar for every connected product sold in the EU. Treat it as an opportunity to institutionalize secure engineering, not a checkbox exercise. Classify your portfolio, update your SDLC, design for secure updates, build a PSIRT, and secure your supply chain. Align CRA workstreams with your Machinery Regulation transition where relevant. If you start now, you will hit the 2026 reporting milestone and the 2027 placing‑on‑the‑market deadline without scrambling, while improving product quality and buyer confidence.

Oceń post