The Cyber Resilience Act (CRA) has a ladder of dates. The Commission pages say it entered into force on 10 December 2024, reporting obligations apply as of 11 September 2026 and the main obligations apply from 11 December 2027. This post lists each date and what the page says applies, using three European Commission pages and no other source.
What are the Cyber Resilience Act dates, in order?
The CRA overview page (last update 7 September 2026), the reporting obligations page (last update 11 September 2026) and the Commission summary of the legislative text (last update 3 December 2025) give the dates below. The summary says it is prepared by Commission services, is not meant to cover the full scope of the Regulation and is not representative of the Commission’s official position. It points readers to the text published in the Official Journal. This post is a summary of those pages, not legal advice.
- 10 Dec 2024Entry into forceThe CRA entered into force.
- 11 Jun 2026Chapter IVNotification of conformity assessment bodies applies.
- 27 Jul 2026GuidanceThe Commission published practical guidance for manufacturers, developers and businesses.
- 11 Sep 2026ReportingReporting obligations set out in Article 14 apply.
- 11 Dec 2027Main obligationsMain provisions apply; open-source steward reporting starts.
- 11 Jun 2028CertificatesEU type-examination certificates remain valid until this date, unless they expire before it.
What applied on 11 June 2026?
The summary page says Chapter IV, on the notification of conformity assessment bodies, applies from 11 June 2026. Conformity assessment bodies carry out conformity assessment activities. To do so under the CRA, a Member State needs to notify the Commission and other Member States of the bodies it authorizes. The page says Member States are required to designate, by 11 June 2026, notifying authorities for assessing, designating and notifying those bodies.
This matters because the overview page says some products of particular relevance for cybersecurity may need a third-party assessment by a notified body before they are sold on the EU market. Note that the summary page was last updated on 3 December 2025, so it words this date in the future tense.
What do the reporting obligations require from 11 September 2026?
The reporting page says that as of 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements. The summary page says this applies after the product is placed on the market, to issues the manufacturer becomes aware of. The page sets these timings:
- An early warning within 24 hours of becoming aware.
- A full notification within 72 hours.
- For actively exploited vulnerabilities, a final report no later than 14 days after a corrective measure is available.
- For severe incidents, a final report within a month from the 72-hour notification.
Manufacturers report only once, through the CRA Single Reporting Platform (SRP). The reporting page says ENISA established it with the CSIRT Network and that it is operational as of 11 September 2026. The notification goes to the CSIRT where the manufacturer has its main establishment and, unless particularly exceptional circumstances apply, is made available simultaneously to ENISA. For a closer look at the clock, see our post on the CRA reporting obligations and the 24-hour clock, and for a comparison with other regimes see incident reporting deadlines under NIS2, the CRA, SEC and CIRCIA.
The overview page also says the CRA requires manufacturers to handle vulnerabilities during the lifecycle of their products. Our glossary entry on vulnerability management explains the wider practice.
What changes on 11 December 2027?
The overview page says the main obligations introduced by the Act apply from 11 December 2027. The summary page says the CRA is fully applicable as of that date. It also says products placed on the market before 11 December 2027 are subject to the CRA only if, from that date, they are subject to a substantial modification. The reporting obligations are the exception, as the callout above shows.
The same date applies to open-source software stewards. The reporting page says that under Article 71(2) of the CRA, stewards are subject to reporting obligations under Article 24(3) from 11 December 2027. The summary page defines a steward as a legal person, other than a manufacturer, that systematically provides support on a sustained basis for the development of specific free and open-source software intended for commercial activities. It adds that stewards are not subject to penalties for infringements of the CRA. The reporting page says stewards must also use the SRP.
The summary page also says that a manufacturer which integrates third-party components needs to exercise due diligence so those components do not compromise the cybersecurity of its product. Our glossary entry on supply chain attacks gives background.
How long do certificates stay valid?
The summary page says EU type-examination certificates and approval decisions issued regarding cybersecurity requirements remain valid until 11 June 2028, unless they expire before that date.
What can a team check against these dates?
The pages suggest some questions rather than answers. Does the organization make products with digital elements on the Union market? If so, who would send an early warning within 24 hours, and through which route? The reporting page says ENISA has published FAQs, user guidance, a CRA SRP glossary and training materials, and that Section 9.1 of the Commission guidance and Section 5 of the Commission FAQs give further clarification. The summary page also says micro and small enterprise manufacturers may not be fined for failures to meet the 24h deadline.
For the wider picture, read our post on the EU Cyber Resilience Act and our cyber compliance calendar for 2026 and 2027. Counsel can confirm how each date applies to your products.
Last checked against the official pages on 9 October 2026. Dates and status can change, so confirm on the pages listed under Sources before acting.
For background on how threats are cataloged, see the Brandefense knowledge hub pages on threat groups, malware families, ATT&CK techniques and significant incidents, and the glossary. The cyber threat intelligence page describes the related service.