Back to insights
RegulatoryMarch 20266 min read

EU Cyber Resilience Act: what it means for hardware security

Regulation (EU) 2024/2847, published in November 2024 and fully enforceable from 11 December 2027, imposes binding cybersecurity requirements on every product with digital elements placed on the EU market. For hardware vendors, the operational implications are significant and the lead time is short.

What the CRA actually does

The Cyber Resilience Act, Regulation (EU) 2024/2847 [1], is the first horizontal EU legislation that imposes mandatory cybersecurity requirements on products with digital elements across their entire lifecycle. It applies to manufacturers, importers and distributors placing such products on the Union market, regardless of their establishment. The scope is deliberately broad: any product with software, firmware or networked components, from industrial controllers to consumer wearables, falls within it unless explicitly excluded [2].

The legal architecture follows the pattern familiar from the Radio Equipment Directive and the Machinery Regulation: essential requirements set out in Annex I, conformity assessment procedures, CE marking, and a market surveillance regime backed by penalties up to 15 million euros or 2.5 percent of global annual turnover, whichever is higher [3]. The structural novelty is the addition of a mandatory vulnerability handling and disclosure regime that extends throughout the support period.

The essential requirements, in operational terms

Annex I, Part I lists the cybersecurity requirements that every in-scope product must satisfy at the moment of placement on the market. Key obligations include: a secure-by-default configuration, protection against unauthorised access through appropriate authentication and access control, protection of the confidentiality and integrity of stored and transmitted data, minimisation of the attack surface, mitigation of the impact of incidents through resilient design, and provision of security update mechanisms [1].

Annex I, Part II governs the vulnerability handling process across the support period. Manufacturers must identify and document the components and vulnerabilities of their products via a software bill of materials, address vulnerabilities without delay through free security updates, publicly disclose information about fixed vulnerabilities once a patch is available, and operate a coordinated vulnerability disclosure policy. These are continuous obligations, not point-in-time checks [1].

For hardware vendors, the practical implication is that the firmware-update infrastructure, the SBOM toolchain and the CVD policy are now regulated assets, not optional engineering hygiene. A product cannot be placed on the market without them, and the conformity assessment will examine them.

Important and critical product classes

Annex III classifies a subset of products as important (Class I and Class II) and Annex IV identifies critical products. The classification drives the conformity assessment route. Default products may self-assess. Class I important products require either application of a harmonised standard or third-party assessment. Class II important products require third-party assessment by a notified body. Critical products require European cybersecurity certification under the framework established by Regulation (EU) 2019/881 [1][7].

For the hardware security domain, the relevant Class II entries include hardware devices with security boxes, smart card readers with security functions, microprocessors with security-related functions intended for essential entities under NIS2 [4], and hardware microcontrollers with security-related functions. A device such as a post-quantum hardware key or a sovereign secure communication endpoint falls squarely in this regime. Critical product status, where designated by Commission delegated act for the highest-risk hardware roots of trust, imposes mandatory EU cybersecurity certification at the assurance level set in the delegated act.

The 24-hour and 72-hour reporting obligations

Article 14 introduces incident and vulnerability reporting obligations that are tighter than most existing regimes. Actively exploited vulnerabilities must be notified to ENISA [5] and the relevant CSIRT within 24 hours of awareness through an early warning, followed by a more complete notification within 72 hours and a final report within 14 days. Severe incidents impacting the security of the product must be reported on the same timeline [1].

Operationally, this means that the manufacturer needs an internal triage and notification pipeline capable of producing a structured report to a regulator within hours of a security event. For a small or mid-sized vendor, this is a meaningful organisational requirement, not a tooling problem. The CRA explicitly contemplates that compliance with this article requires a security operations function with defined roles and escalation paths, with the kind of maturity typically formalised under ISO/IEC 27001 [8].

Timeline and grace periods

The Regulation entered into force in late 2024 [3]. Article 14 reporting obligations apply from 11 September 2026. The full set of obligations, including conformity assessment and CE marking, applies from 11 December 2027. There is no grace period for products placed on the market after that date [1].

For a hardware vendor with a 12 to 24 month development cycle, the practical horizon is now. A product entering serious design work in 2026 must reach market with a CRA-compliant security posture, conformity assessment file and vulnerability handling infrastructure. Retrofitting is not realistic for the structural requirements such as secure update, SBOM coverage and the architectural elements that support resilient operation [6].

What this means for you

For vendors of hardware security products selling into the EU, the CRA is not a documentation exercise. It is a regulated assurance regime with notified-body involvement for any non-trivial security function, continuous obligations during the support period, and penalties calibrated to ensure compliance is cheaper than non-compliance. Treat it as you would the Medical Device Regulation or the Radio Equipment Directive: a structural design input, not a final-mile audit.

Concretely: identify your product's Annex III classification today; engage a notified body for Class II products at least 12 months before planned market entry; build the SBOM and CVD infrastructure into your engineering process rather than adding it later; align your firmware update mechanism, threat model and incident response runbook with Annex I before tape-out, not after.

For buyers of hardware security products, the CRA is a powerful procurement lever. From December 2027 onwards, the CE mark on an in-scope product is a binding declaration of compliance with the essential cybersecurity requirements. The conformity assessment file, the SBOM and the CVD policy are documents you are entitled to demand. The presence of a robust regulatory posture is now a discriminator between serious vendors and the rest [1][2][3].

References

  1. Regulation (EU) 2024/2847 — Cyber Resilience Act (Official Journal text)
  2. European Commission — Cyber Resilience Act policy page
  3. Council of the EU — Cyber Resilience Act adoption press release (10 Oct 2024)
  4. Directive (EU) 2022/2555 — NIS2 Directive
  5. ENISA — Threat Landscape 2024
  6. ENISA — Foresight Cybersecurity Threats for 2030 (2024 update)
  7. Common Criteria Portal — basis for the EU cybersecurity certification framework
  8. ISO/IEC 27001 — Information Security Management standard

Ready to Secure Your Digital Sovereignty?

Join Europe's post-quantum security revolution. Contact our team for institutional partnerships and strategic collaborations.