The Cyber Resilience Act: The Reporting Duty Is Already Live, and It Reaches Products You Shipped Years Ago

Almost everything written about the Cyber Resilience Act points at December 2027. That is when the main obligations bite, and it is far enough away to feel like a planning problem rather than an operational one.

The reporting obligation is not in December 2027. It started on 11 September 2026, and unlike the rest of the Regulation it reaches products that were placed on the market years ago.

The dates, in order

Regulation (EU) 2024/2847 entered into force on 10 December 2024 and applies in stages:

• 11 June 2026 — Chapter IV applies, covering notification of conformity assessment bodies.
• 11 September 2026 — the Article 14 reporting obligations apply.
• 11 December 2027 — the main provisions become fully applicable.

EU type-examination certificates and approval decisions on cybersecurity remain valid until 11 June 2028, unless they expire sooner.

The asymmetry that catches manufacturers out

This is the part worth reading twice, because the two halves of the Regulation treat legacy products in opposite ways.

For the design and conformity requirements, products placed on the market before 11 December 2027 are in scope only if they undergo a substantial modification after that date. A product shipped in 2024 and left alone is not caught.

For reporting, the position reverses: the obligations apply to all products already on the EU market, including those placed there earlier. The same 2024 product is in scope now.

So there is a window, running from last month until December 2027, in which a manufacturer can owe a 24-hour reporting duty on a product that is otherwise outside the Regulation entirely — and which may not appear on any CRA readiness plan, precisely because the design requirements do not apply to it.

The clock

Manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of the product, on a three-stage timetable:

• Early warning within 24 hours of becoming aware.
• Full notification within 72 hours.
• Final report — for an actively exploited vulnerability, no later than 14 days after a corrective measure is available; for a severe incident, within one month of the 72-hour submission.

Reports go to the CSIRT in the country where the manufacturer has its main establishment, with ENISA receiving the information at the same time unless exceptional circumstances apply. That CSIRT then passes the notification to the CSIRTs in every other territory where the product is made available, though it may delay this in exceptional cybersecurity-related cases.

Filing is through a single channel: the CRA Single Reporting Platform, developed by ENISA and due to be operational from the date the obligations started.

Twenty-four hours is the number to plan around. It is shorter than most internal escalation paths, and it runs from awareness rather than from confirmation — a different trigger from the one most incident processes are built on. The sector has been here before with the NIS2 Directive, which uses a comparable staged reporting structure.

What is actually in scope

The CRA covers hardware and software "products with digital elements" made available on the EU market, including components sold separately. A product is caught where its intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection.

Read that test carefully. "Indirect" and "reasonably foreseeable" between them pull in a great deal that a manufacturer might not think of as connected equipment. Products not supplied in the course of a commercial activity are out of scope, and certain products are excluded where other EU law already covers them.

The connected-product framing overlaps with other recent EU instruments, including the data access and sharing obligations we cover in our guide to the EU Data Act. A single connected device can now sit inside several regimes at once.

The rest of the manufacturer obligations

Reporting is the live duty, but it is one of several. From December 2027 a manufacturer must also carry out a cybersecurity risk assessment and meet the essential requirements in Annex I across the product's whole lifecycle; exercise due diligence when integrating third-party components; prepare technical documentation and keep it available for market surveillance authorities; complete the chosen conformity assessment, issue the EU declaration of conformity and affix the CE marking; and supply identification details, contact information and the user information and instructions set out in Annex II.

The third-party component duty is the one that tends to be underestimated. Most products with digital elements are assembled rather than written from scratch, so due diligence over components is not a procurement formality — it is a continuing obligation over a supply chain the manufacturer does not control and frequently cannot fully enumerate.

Conformity classes

How a product is assessed depends on which category it falls into:

• Default products, not listed in Annex III or IV — generally self-assessment under internal control, or a notified body, or a European cybersecurity certification scheme where one is available and applicable.
• Important products, Class I (Annex III) — self-assessment is allowed only where harmonised standards, common specifications or an applicable certification scheme were applied. Otherwise a notified body is required.
• Important products, Class II (Annex III) — third-party assessment, or a certification scheme where available and applicable.
• Critical products (Annex IV) — third-party assessment, or a certification scheme where available and applicable.
• Free and open-source important products in Classes I and II — self-assessment is permitted if the technical documentation is made publicly available.

The Class I rule is the one that changes behaviour: self-assessment is conditional on having applied a harmonised standard, so the availability of those standards determines whether a manufacturer needs a notified body at all. That is the same dynamic that governs conformity under the European Accessibility Act.

The support period, and the obligation to publish it

Manufacturers must determine a support period during which vulnerabilities are handled effectively in line with Annex I, and the end date — month and year — must be clearly stated at the time of purchase.

This is a commercial decision disguised as a compliance one. A short support period is cheap to honour and visible to every buyer at the point of sale. A long one is a marketing asset and a multi-year engineering commitment. It has to be set deliberately rather than defaulted.

What it means for people, stated plainly

The CRA imposes no training requirement. It is worth saying so directly, because the surrounding regimes mostly do.

What it creates instead is a 24-hour operational duty that only works if someone knows it exists. The realistic failure mode is not technical and it is not legal: it is that a support engineer learns a vulnerability is being exploited on a Friday, treats it as a normal ticket, and the clock expires before anyone with reporting responsibility hears about it. Awareness has to reach the people who find out first, which is rarely the compliance function. Our guides to cybersecurity policies and security awareness training cover the organisational side of that.

It is also distinct from cyber resilience as a general discipline, which we cover separately in what cyber resilience means. The CRA is a product regulation with a CE marking at the end of it, not a resilience framework.

Our suggestions

Inventory what you have already shipped that is still on the EU market, and decide today who owns the 24-hour clock for it. That list is the live exposure, and it is the one most readiness plans omit because the design requirements do not apply to it.

Set the escalation trigger at awareness, not at confirmation. A process that waits for a vulnerability to be verified before notifying anyone has already spent the window.

And treat the support period as a product decision made now rather than a field filled in during conformity assessment in 2027. It is published to buyers, and it is hard to shorten once it is out there. For organisations tracking the wider standards picture, our guides to ISO/IEC 42001 and post-quantum cryptography risk cover adjacent obligations arriving on similar timelines.