What the CRA's September 2026 reporting obligations mean in practice

If you make software or hardware available in the EU and you learn that a vulnerability in your product is being actively exploited, you have 24 hours to file an early warning with the authorities. Article 14 of the Cyber Resilience Act is in force since 11 September 2026 — more than a year ahead of the rest of the Regulation, which follows on 11 December 2027 (Article 71).

This is the part of the CRA that most companies discover late, because the headline date everyone repeats is December 2027. Here is what Article 14 actually requires, who it covers, and what a small software company should have in place — now, not eventually.

Who must report

Manufacturers of products with digital elements made available on the EU market — which under the CRA means not only companies that build software, but also those that sell someone else's product under their own brand, and those that substantially modify a product and place it on the market (Articles 21 and 22 extend manufacturer obligations to both). If you are unsure whether your product is in scope at all, that is a prior question — check your CRA scope here before worrying about timers.

What must be reported, and how fast

Article 14 creates two reporting tracks, each with three steps.

Track 1 — actively exploited vulnerabilities. An "actively exploited vulnerability" is one for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission (Article 3(42)). Once you become aware of one in your product:

• Within 24 hours: an early warning, indicating (where applicable) the Member States where your product is available.
• Within 72 hours: a vulnerability notification — general information about the product, the nature of the exploit and vulnerability, and any corrective or mitigating measures taken or available to users.
• Within 14 days of a corrective or mitigating measure being available: a final report, including a description of the vulnerability, its severity and impact, and details of the fix.

Track 2 — severe incidents affecting your product's security. An incident is "severe" when it negatively affects (or can affect) the product's ability to protect sensitive or important data or functions, or when it has led (or could lead) to the introduction or execution of malicious code in the product or its users' systems (Article 14(5)). The same 24h/72h rhythm applies, with the final report due one month after the incident notification.

Notifications go through the single reporting platform (Article 16), addressed to the CSIRT designated as coordinator of the Member State where you have your main establishment — and simultaneously accessible to ENISA. Manufacturers with no EU establishment still report: Article 14(7) sets out a cascade for determining which Member State's CSIRT receives your notifications.

There is a second, easy-to-miss duty in Article 14(8): informing your users. After becoming aware of an actively exploited vulnerability or severe incident, you must inform impacted users — and where appropriate all users — including the mitigation steps they can take. If you fail to do it in a timely manner, the CSIRT can do it for you. Few things are worse for customer trust than users learning about your incident from a government notice.

The part nobody tells you: 24 hours is an operational problem, not a legal one

Reading Article 14 takes ten minutes. Complying with it inside 24 hours requires things that either exist before the incident or do not exist at all:

• A way to learn you are affected. You cannot report a vulnerability you do not know about. That means an up-to-date inventory of what is in your product — in practice, an SBOM — matched against vulnerability and exploitation data. This is also simply required: Annex I Part II obliges manufacturers to identify and document vulnerabilities and components, including an SBOM covering at least top-level dependencies.
• A definition of "aware". The clock starts when the manufacturer becomes aware. Your internal process should define who assesses evidence of active exploitation and how the decision is recorded.
• Prepared templates. The worst moment to write your first early warning is at hour 20 of the 24. The required content of each notification step is known in advance — draft it now, fill in the blanks later.
• A runbook that works on a bad day. Who classifies, who drafts, who submits, who informs users, and who covers each role when someone is unreachable.

None of this requires buying anything. All of it requires decisions taken before the incident, not during it — and the Article 14 clock is in force since 11 September 2026.

What this means if you are still preparing for December 2027

The December 2027 date covers the full essential requirements — secure development, technical documentation, conformity assessment, CE marking. September 2026 was narrower but came first, and it quietly tests the same foundations: if you cannot produce an SBOM or track vulnerabilities in your dependencies today, you are not ready for either date. Starting with vulnerability visibility is the rare compliance step that is also just good engineering.

→ Find out in two minutes whether the CRA — and its reporting clock — applies to your product. Free, with a confidence level and cited sources.

---

This article is general information about Regulation (EU) 2024/2847, not legal advice. Sources: Regulation (EU) 2024/2847 (EUR-Lex, Official Journal) — Articles 3, 14, 16, 21, 22, 71 and Annex I Part II; European Commission — CRA reporting obligations. Last reviewed: August 2026.