Skip to content
Crado AI
What 11 September 2026 and 11 December 2027 actually start

Blog

What 11 September 2026 and 11 December 2027 actually start

Photo: ThisisEngineering / Unsplash

Two dates dominate every Cyber Resilience Act conversation: 11 September 2026 and 11 December 2027. They are not the same obligation. Neither is a surprise that lands on the morning of the deadline. Regulation (EU) 2024/2847 is already in force. The dates below open specific duties for a manufacturer who places a product with digital elements on the Union market.

If you treat both dates as “CRA starts then”, you will miss the first operational clock and arrive at CE with an empty technical file.

The calendar is four dates, not two

DateWhat actually starts
10 December 2024The regulation entered into force. The legal text applies. Full application of the essential requirements comes later.
11 June 2026Rules on notifying conformity-assessment bodies. Relevant if your product class will need a notified body.
11 September 2026Article 14: actively exploited vulnerabilities and severe incidents. 24-hour early warning, 72-hour notification, then a final report.
11 December 2027Annex I essential requirements, conformity assessment, EU declaration of conformity and the CE mark when you place a product on the market.

Most slide decks skip June 2026 and collapse September 2026 into “something about incidents”. That is how teams plan a CE project for 2027 and discover, in August 2026, that they cannot name the product, the owner or the CSIRT in twenty-four hours.

What does not start on those mornings

Nothing in the regulation creates a finished SBOM, a risk assessment or a technical file on the day the duty applies. Market surveillance can ask for the file after 11 December 2027. Article 14 can fire on 12 September 2026 at 02:00. The system that answers both questions has to exist earlier.

The dates also do not start a GDPR-style “privacy programme”. CRA is a product-safety rule. The addressee is the manufacturer of a specific product, not “the company” once. A substantial modification is a new placing on the market.

They do not start a vulnerability-scanner subscription. CRA is not a scanner. Scanning is one input into Annex I Part II and the Article 14 queue.

11 September 2026 - Article 14 is an operations clock

This is the first date that changes how a manufacturer works on a Friday night. From 11 September 2026 you notify actively exploited vulnerabilities and severe incidents affecting the product.

The clocks in the text are short on purpose:

  • early warning within 24 hours from the moment you know,
  • full notification within 72 hours,
  • final report: 14 days after a fix for a vulnerability, or one month after the 72-hour notice for an incident.

One channel: the single reporting platform, to the CSIRT of the main establishment, and to ENISA. You do not invent a side mailbox. You do not wait for the Monday standup.

What “you know” actually means

The 24-hour clock starts when the manufacturer is aware, not when a ticket is tidy. If awareness lives in a researcher email, a customer ticket and a Slack thread, you have already lost hours before the queue exists. The operational question is: who is allowed to say “we know”, and which product version does that statement attach to?

Without a product catalogue you cannot answer which SKU, which version, which market and which support end. Without an SBOM that matches the shipped build you cannot say which component is on fire. Without a named owner the 24-hour window is a calendar reminder, not a process.

What you notify, and what you do not

Article 14 is not “every CVE in the backlog”. It is actively exploited vulnerabilities and severe incidents. That still requires a queue that can tell the difference: a CVSS number in a scanner is not the same as active exploitation, and a laptop outage in the office is not a product incident.

The report has to point at a product you placed on the market. If the same firmware ships under three brand names, the file has to know that. If a component vendor discloses first, due diligence on that component still sits with you.

What must already run in August 2026

  1. A PDE catalogue with name, version, type, markets and support end (month and year).
  2. An SBOM from the pipeline, tied to the version you actually ship.
  3. A vulnerability queue with a 24h / 72h clock and a named owner per product.
  4. A written path to the single reporting platform and the CSIRT of the main establishment.
  5. A technical file you can open without copying data off the network.

If any of those is “we will stand it up in September”, the first exploited vulnerability will be an email archaeology exercise.

11 December 2027 - essential requirements and CE

From this date a product placed on the Union market must meet Annex I, complete conformity assessment, carry an EU declaration and the CE mark. You must also maintain the cybersecurity risk assessment, the documentation, the SBOM and the support period stated at purchase with month and year.

This is not “turn on CE in December 2027”. The file has to exist before the product leaves the warehouse. An authority can demand it later. A missing SBOM or a risk row that does not point at Annex I is not a formatting issue. It is an incomplete conformity path.

Module A is still evidence

Most default-class products stay on module A (internal production control). That is not a free pass. You still need the risk assessment, Annex I evidence, the SBOM, the support period, instructions, the declaration and the mark. A notified body is a different class of product, not a substitute for the file.

11 June 2026 matters here: the rules on notifying conformity-assessment bodies start to apply. If your product will need a notified body, waiting until late 2027 to discover that queue is a second missed date.

Placing on the market is the trigger

CRA applies when you place the product on the Union market under your name or trademark. Products already made available before 11 December 2027 are not a blank cheque. A substantial modification is treated as a new placing on the market. A new major version, a new digital function that changes the risk, a rebrand that makes you the manufacturer of record: those are file events, not marketing events.

The support period you state at purchase (month and year) is part of the product identity. It is not a slogan on the website. It has to match the catalogue, the SBOM maintenance window and the vulnerability-handling duty in Annex I Part II.

What the 2027 file actually contains

Not a vulnerability PDF. The file is the product identity, the Article 13 risk assessment across the lifecycle, evidence against Annex I Part I (product properties) and Part II (vulnerability handling), the SBOM, the support period, instructions, the EU declaration and the CE mark. If one of those is missing, the path is not closed.

Common ways teams read the dates wrong

“We have until 2027.” Article 14 is fourteen months earlier. The 24-hour clock does not care about your CE project plan.

“September 2026 is only for incidents.” It is actively exploited vulnerabilities and severe incidents. The first needs an SBOM and a product map as much as the second.

“We will buy a scanner in 2026.” A scanner does not give you manufacturer identity, support dates, Annex I gaps or a declaration. It feeds a queue. It does not replace the queue.

“Software is later.” Standalone software placed on the Union market is a product with digital elements. The dates are the same.

“CE is the notified body’s job.” For most products it is yours. The body, if required, assesses. You still hold the evidence.

What to have running before the first date

Work backwards from 11 September 2026, not forwards from a 2027 slide.

  1. Catalogue every PDE: version, market, placing-on-the-market date, support end with month and year.
  2. Tie the Article 13 risk assessment to Annex I. A gap that lives in a side spreadsheet is not an assessment.
  3. Produce the SBOM from the pipeline and lock it to the shipped version.
  4. Stand up the 24h / 72h queue with a named owner and a path to the CSIRT and ENISA.
  5. Keep the technical file on-premise, exportable without taking the SBOM off the network.

Crado AI is the on-premise system for that loop: catalogue, risk, SBOM, Article 14, technical file and CE. The dates do not move. The file does not appear on the morning of 11 September.

Blog