The Cyber Resilience Act (CRA): What Hardware Makers Must Do Before the Next Deadline

Last updated: September 2026. Dates and obligations below are drawn from Regulation (EU) 2024/2847; the Commission is still issuing guidance and the harmonised standards are still being developed, so confirm the current detail for your product before you rely on it.

The short version

The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, turns cybersecurity into a condition of selling almost any connected product with digital elements in the EU. If your product has software, can connect, and is sold in the EU, the CRA almost certainly makes secure design, vulnerability handling, and CE marking mandatory, and importers and distributors have duties of their own. The Regulation entered into force on 10 December 2024, and the obligations arrive in stages. Reporting of actively exploited vulnerabilities and severe incidents has applied since 11 September 2026, so that duty is already live; the full set of requirements follows on 11 December 2027. That second date sounds far off; the engineering behind it (building security in, standing up a vulnerability-handling process, and getting through conformity assessment) is not something you start in 2027.

The four dates that matter

Article 71 of the CRA sets when each part of it starts to apply, and it phases the obligations in. Put these dates in your roadmap now:

Date	What applies	Who needs to act
10 December 2024	Regulation in force (clock starts)	Everyone: start scoping
11 June 2026 · applies	Rules on notifying conformity-assessment bodies (Chapter IV, Arts. 35–51)	Member States, designating the bodies that assess "important"/"critical" products
11 September 2026 · applies	Reporting obligations (Art. 14): actively exploited vulnerabilities and severe incidents are reported through the Single Reporting Platform run by the EU Agency for Cybersecurity (ENISA), simultaneously to ENISA and to the coordinating Computer Security Incident Response Team (CSIRT), within 24 and 72 hours	Manufacturers of in-scope products on the EU market
11 December 2027	General application: all remaining obligations (essential requirements, conformity assessment, CE marking)	Manufacturers, importers, distributors

Of the duties that fall on you, reporting is the one that arrives first, and it is already here. Long before your product has to be fully compliant, you must report an actively exploited vulnerability within the mandated window once you become aware of it: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a corrective or mitigating measure becoming available, or within a month of the 72-hour notification for a severe incident. You must also inform affected users (Article 14(8)). In practice, that means being able to detect and triage a vulnerability in the first place. Reports go through the CRA Single Reporting Platform, which ENISA opened on the day the duty began. If you cannot do that yet, that is your first project, and you are starting it late.

The duty also covers the installed base. Article 69(3) applies the reporting obligation to every in-scope product already on the market, even though the rest of the regime leaves those units alone until they are substantially modified. A product you shipped in 2025 is inside the reporting regime today.

The staggering has a logic worth understanding, because the sequence runs from the most urgent duty on a manufacturer to the most laborious one. A live vulnerability in a product already in users' hands is an immediate risk, and of the duties that fall on you the reporting obligation came first. The sequence reads as the EU wanting that channel open well before the full regime arrives. The rules for conformity-assessment bodies applied earlier still, from 11 June 2026, so that notified bodies would exist and stand ready before manufacturers began queuing for them, which is what recital 95 asks of Member States. The full obligations come last, which gives industry the longest lead time for the most demanding work: secure-by-design and conformity assessment. Read in that order, the timeline amounts to a to-do list: get the reporting process running, then determine your tier and run the assessment, then affix the CE marking.

Are you in scope?

The CRA covers products with digital elements (software or hardware products) made available on the EU market whose intended purpose or reasonably foreseeable use includes a data connection to a device or network. That scope sweeps in most connected hardware: anything with firmware and a radio or a port. A Wi-Fi thermostat, an industrial gateway, a Bluetooth sensor, and a USB peripheral with its own firmware are all products with digital elements, and software placed on the market on its own (an application, a library) can be in scope too. For most makers of connected hardware, whether the Regulation applies is accordingly rarely in doubt. The questions that remain open are which tier the product falls into and how demanding its conformity assessment will be.

A few categories remain outside the CRA because other EU regimes already govern their cybersecurity: medical devices, motor-vehicle type-approval, aviation products certified under Regulation (EU) 2018/1139, and marine equipment, among others. An uncertified drone or aviation component can still be in scope. If your product falls under one of those frameworks, check that framework first. Two further exclusions are narrow: spare parts that replace identical components and are made to the same specifications, and products developed or modified exclusively for national security or defense purposes (Article 2(6) and 2(7)). Everyone else building connected hardware should assume they're in.

Work it through in order:

1. Does the product have digital elements (software, firmware, or digital hardware) and a data connection, and is it made available on the EU market? If no, the CRA doesn't apply.

2. Is it excluded? Products under a listed sectoral regime (medical devices, motor-vehicle type-approval, certified aviation products, marine equipment) follow that regime, and identical spare parts and products developed or modified exclusively for national security or defense are also outside the CRA. If yes, the CRA doesn't apply.

3. Otherwise you're in scope: now determine your product's tier, which sets how hard the conformity assessment is.

Default, important, or critical: the tier sets the assessment

Not every in-scope product bears the same burden. The CRA sorts products into tiers, and the tier sets how conformity must be shown:

• For default products, everything outside the Annex III and Annex IV lists and therefore most of what a hardware company ships, the manufacturer can use self-assessment to show conformity.

• Important products (listed in Annex III, split into class I and the higher-risk class II) face stricter routes. Free and open-source software in either class may self-assess, provided its technical documentation is made public when the product is placed on the market (Article 32(5)). Any other class I product may still be self-assessed, but only where its manufacturer has applied harmonised standards, common specifications, or a qualifying European cybersecurity certification scheme in full; otherwise it goes to a notified body (Article 32(2)). Any other class II product has no self-assessment route: conformity runs through a notified body, or through a European cybersecurity certification scheme at assurance level at least "substantial" (Article 32(3)).

• Critical products (listed in Annex IV) occupy the top tier. Where the Commission has mandated a European cybersecurity certification scheme for the category, that scheme is the route; where it has not, the class II procedures apply (Article 32(4)). Self-assessment is never open to them.

The gradation is one of scrutiny: the higher the risk a tier represents, the less conformity may rest on the manufacturer's own assessment. The exact category lists are set out in Annex III and Annex IV, and their technical description is fixed by Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025; the Commission can still amend the Annexes themselves by delegated act. Map your specific product against the current lists and that technical description before you assume a tier. The stakes of that mapping are practical. If your hardware product lands in class II rather than the default tier, conformity can no longer rest on self-assessment: it runs through a notified body or a certification scheme, and you still sign the EU declaration of conformity yourself.

Cyber Resilience Act requirements: what you actually have to do

The manufacturer obligations (Articles 13 and 14) come down to designing security in, keeping it up through the support period, and being able to prove it. In practice, they break down into five obligations, each listed with its start date:

Obligation	What it requires	Who	Article	Applies from
Build to the essential requirements	Secure by design and by default: a secure default configuration, protection against unauthorized access, a limited attack surface, protected data, and so on	Manufacturer	Art. 13; Annex I, Part I	11 December 2027
Handle vulnerabilities across the support period	Identify and document vulnerabilities, provide security updates, and draw up a software bill of materials (SBOM): a machine-readable record, in a commonly used format, covering at least the top-level software dependencies of your product. You cannot patch what you cannot inventory.	Manufacturer	Art. 13; Annex I, Part II	11 December 2027
Report	Report actively exploited vulnerabilities and severe incidents within the mandated deadlines through the Single Reporting Platform, and inform affected users	Manufacturer, including for products already on the market	Art. 14; Art. 69(3)	11 September 2026
Prove conformity	Assess conformity, draw up the technical documentation and the EU declaration of conformity, and affix the CE marking	Manufacturer; importers and distributors verify	Arts. 13 and 28–32; Arts. 19 and 20	11 December 2027
Define and disclose a support period	Provide security updates for at least five years, or for the expected use time if that is shorter, and state the end date of the support period at the time of purchase	Manufacturer	Art. 13(8) and 13(19)	11 December 2027

"Secure by design and by default" translates into concrete engineering choices: no universal default or hardcoded passwords, which in practice means a unique credential per device or one the user sets at first setup; a smaller attack surface, with unused interfaces and ports disabled; data protected in transit and at rest; and updates that can be delivered in the field. Handling vulnerabilities across the support period is the operational half: you need a channel through which vulnerability reports can reach you, a process for triaging and fixing what arrives, and the ability to push updates for as long as you have committed to support the product. Each half is a capability that must be built and then kept running, and neither is a one-time gate you pass at launch; the building takes calendar time, the running continues through the support period you have disclosed, and together they are the real reason the 2027 date is tighter than it looks.

Importers and distributors have their own duties, and they are not the same duties. An importer must not place a product on the market unless it bears the CE marking and the importer has verified that the manufacturer carried out the conformity assessment and drew up the technical documentation (Article 19(2)). A distributor's list is shorter: before making a product available it checks that the CE marking is there and that the manufacturer and importer supplied the required identification, documentation, and instructions (Article 20(2)). The obligations therefore reach every economic operator that places the product on the EU market or makes it available there.

A realistic timeline

A workable sequence counts backward from December 2027. For the rest of 2026, confirm scope and tier, make sure you can take in, triage, and report actively exploited vulnerabilities (Article 14 reporting has applied since 11 September 2026; the full vulnerability-handling requirements of Annex I Part II follow on 11 December 2027), and start the SBOM. In early–mid 2027, close the secure-by-design gaps, complete technical documentation, and run conformity assessment, booking a notified body early if you're in Annex III class II or Annex IV, or in class I without a harmonised standard you can apply in full, because capacity is likely to be tight. Before 11 December 2027, issue the declaration of conformity and affix the CE marking. Expect teams that treat 2027 as the start date instead of the finish line to struggle.

Two uncertainties complicate the plan. The first is notified-body capacity, the wildcard: if you're in Annex III class II or Annex IV, or in class I without a harmonised standard you can apply in full, the pool of bodies that can assess you is finite, every affected manufacturer is on the same clock, and the two facts together mean that a slot you assume is free in mid-2027 may not be. Article 35(2) names 11 December 2026 as the date for a sufficient number of notified bodies in the Union, to avoid bottlenecks and hindrances to market entry. The date is addressed to Member States, and it is not a booking for you. The second is that much of the detailed "how" arrives through the harmonised standards requested under standardisation request M/606, which are still being developed. A product built to a harmonised standard is presumed to conform to the essential requirements that the standard covers, and only once the standard's reference has been published in the Official Journal (Article 27(1)). Check the current list of published references rather than assuming a draft standard will be enough, and design to the essential requirements in the meantime rather than over-building to a guess.

What this means if you're a DACH SME

For a small or mid-sized hardware company selling into the EU, the CRA is a reason to start work now, and it is no reason to panic: the dates are known and the sequence between them is workable. Three things deserve calendar time. First, decide your tier: most products self-assess, but confirm you're not in Annex III or IV, because that changes your whole timeline and cost. Second, make sure you can detect, triage, and report actively exploited vulnerabilities, because Article 14 reporting has applied since 11 September 2026 regardless of your product's tier. Third, start the software bill of materials, because it feeds both compliance and your ability to answer "are we affected?" the next time a widely used component has a vulnerability. None of these needs a finished product; all of them take longer to build than a deadline-driven scramble allows, which is the whole argument for starting in 2026 rather than 2027.

FAQ

Does the CRA apply to my product?

If it has digital elements (software, firmware, or digital hardware) and a data connection, and you make it available on the EU market, the answer is almost certainly yes. It is different where a sectoral regime covers the product (medical devices, motor-vehicle type-approval, certified aviation products, marine equipment) or one of the narrow exclusions applies: identical spare parts, and products developed or modified exclusively for national security or defense. Connected hardware is the core target.

When is the real deadline?

There are two, and the first has already passed. Reporting obligations for actively exploited vulnerabilities and severe incidents have applied since 11 September 2026; the full requirements (essential requirements, conformity assessment, CE marking) apply from 11 December 2027. The Regulation entered into force on 10 December 2024.

Do I need a third party to certify my product?

It depends on the tier. Default products self-assess. Free and open-source software in Annex III may self-assess if its technical documentation is made public (Article 32(5)). Any other class I product in Annex III can still be self-assessed where its manufacturer has applied harmonised standards, common specifications, or a qualifying certification scheme in full, and otherwise needs a notified body. Any other class II product in Annex III, and every critical product in Annex IV, has no self-assessment route: a notified body, or a European cybersecurity certification scheme. Map your product to the Annexes to find out.

What's an SBOM and do I really need one?

A software bill of materials is a record of the software components in your product. The CRA's vulnerability-handling requirements call for one, and practically you need it to know what to patch when a component vulnerability appears. Start it early.

I just import or distribute: am I off the hook?

No: importers may only place compliant, CE-marked products on the market, and a distributor must check the CE marking and the required documentation before making a product available. If you place the product on the market under your own name or trademark, or you substantially modify it, the CRA treats you as its manufacturer (Article 21), with the full Article 13 and 14 duties. The obligations follow the product down the chain, although they are not identical at each step.

What if I sell into the EU from outside it?

The CRA follows the product onto the EU market, so a non-EU manufacturer is still responsible for its product's compliance, and the importer placing it on the EU market must verify that. Being based outside the EU doesn't put you outside the CRA.

How long do I have to support a product?

You must define and disclose a support period during which you provide security updates, sized to how long the product is reasonably expected to be in use. Article 13(8) sets the minimum at five years, or at the expected use time where the product is expected to be in use for less than five years, and a longer expected life pushes the period up. That minimum is a legal floor: you cannot ship with a shorter support period.

What happens if I don't comply?

Non-compliant products can be barred from the EU market and ordered withdrawn, and the CRA provides for penalties. In my read, for most connected-hardware makers the loss of EU market access is the larger commercial risk, which is why treating the deadlines as real is worth it.

Close

The CRA turns two things you already depend on into compliance questions: the software components inside each connected part, and the support commitment behind them. A module whose supplier will not give you a software bill of materials or a firm update path is a compliance gap and a sourcing dependency at once, and it is usually cheaper to treat that as one problem than as two.

If that is the problem in front of you, get in touch. I work on product-architecture and hardware-component questions, most often where China sourcing is involved, and I look at hardware, firmware, and sourcing together rather than one layer at a time.

Meritong is a China-sourcing and supply-chain strategy practice. I am not a lawyer; this article is general information, and it is not legal or compliance advice. The CRA's harmonised standards are still being developed and further Commission acts are expected. Confirm the current requirements for your specific product with qualified counsel or your notified body.