Most CRA conversations are about December 2027: CE marking, conformity assessment, the technical file. That is the date teams have planned against. It is the wrong one to worry about first.
On 11 September 2026, Article 14 switches on, bringing CRA reporting obligations into force. From that date, if a vulnerability in your product is being actively exploited, you have twenty-four hours to tell the European Union about it.
This is the first CRA obligation with real operational teeth. A failure in the 2027 conformity requirements may sit unnoticed until someone reviews your documentation during an audit. A missed Article 14 notification is different. Once you have reasonable certainty that a vulnerability is being actively exploited, you have 24 hours to report it. If a CSIRT in another member state receives a report about the same vulnerability and yours is absent, the gap can become visible almost immediately.
This piece covers what you actually have to do, mechanically, and what to have in place beforehand.
What Triggers CRA Reporting?
Article 14 creates two reporting duties. Neither one says "report your vulnerabilities."
- Vulnerability in your product that is being actively exploited in the wild. A disclosure, a high-severity CVE, or a scanner finding on its own does not trigger the reporting obligation. What matters is evidence that the vulnerability is actually being exploited against your product.
- A severe incident affecting your product's security. This covers events on your side rather than flaws in your code. A compromise of your build pipeline or signing keys qualifies. An incident that never reaches what you shipped does not.
That distinction matters more than any other sentence in this article. Teams read "24-hour reporting," imagine a firehose of CVE notifications, and conclude the regime is unworkable.
The reality is much narrower. Your scanner returning four hundred findings on Tuesday triggers nothing. Evidence that one of them is being exploited against your product triggers everything.
Settle this decision in advance. Who determines that a vulnerability is actively exploited, and on what evidence? Answering that is the single most useful thing you can do before September.
CRA Reporting Deadlines: 24 Hours, 72 Hours and Final Report
Both triggers follow the same staged cascade. They diverge only at the final report.
Stage | Deadline | Contents |
Early warning | 24 hours from awareness | Confirmation that an actively exploited vulnerability or severe security incident has occurred. For a severe incident, the notification should also state whether it is suspected to involve unlawful or malicious acts. |
Full notification | 72 hours from awareness | Expanded technical detail, an impact assessment, and initial corrective or mitigating measures. |
Final report | 14 days after a corrective measure is available, for actively exploited vulnerabilities. One month after the 72-hour notification, for severe incidents. | Root cause analysis, mitigations implemented, security updates planned. |
Treat the twenty-four-hour filing as a flare. It carries no analysis. The Commission designed the cascade so the first filing stays thin by intention and the substance arrives at 72 hours. Teams planning to complete an investigation before filing have misread the structure.
When Does the CRA 24-Hour Reporting Clock Start?
This part carries the most operational consequence and gets the least attention.
The clock runs from awareness, not from disclosure, discovery, or the moment your scanner fired
The Commission's guidance frames awareness as having a reasonable degree of certainty that a vulnerability in your product is being actively exploited, or that a severe incident has compromised your product's security.
You usually cannot reach reasonable certainty without an initial assessment. So a researcher emailing you something alarming does not oblige you to file that instant. You are permitted to triage first. What you cannot do is triage indefinitely.
Two practical consequences follow:
Define "reasonable degree of certainty" in writing
Write it down before you need it. Which signals count as evidence of active exploitation?
- A vendor advisory?
- Telemetry from your own estate?
- A public proof of concept, or only observed use?
Deciding this at 2am during an incident produces a worse answer than deciding it in August.
Nothing pauses the clocks once they run
Not a weekend. Not a holiday. Not the fact that your one person who understands the affected component is on a plane.
Twenty-four hours is a wall clock, and a business-hours SLA will not cover it. This is a rota problem before it is a compliance problem.
Who has to file
Broader than most teams assume on first read.
The duty falls on the manufacturer of a product with digital elements made available on the EU market. Importers and distributors carry secondary verification and reporting duties.
Three things catch people:
- It applies regardless of where you are headquartered. A company in Singapore, Bangalore or San Francisco selling into the EU is in scope. Non-EU manufacturers need a designated authorised EU representative who can interface with ENISA and national CSIRTs.
- It applies to products already on the market. The reporting obligation is not gated on the December 2027 date. If a product with digital elements is available in the EU on 11 September 2026 and an actively exploited vulnerability surfaces in it, you report. Legacy products included.
- It attaches to the product, and company size makes no difference. There is no SME carve-out from the reporting duty.
One narrowing is genuinely useful: the obligation does not extend to vulnerabilities whose active exploitation you were already aware of before 11 September 2026.
Where it goes
Filings go to ENISA and the relevant national CSIRT simultaneously, through ENISA's Single Reporting Platform. One submission, both recipients.
Register before you need to report. The Single Reporting Platform must be operational by 11 September 2026, so if you are in scope, complete registration and access checks beforehand. Do not leave onboarding until an incident occurs.
There is also a limited confidentiality mechanism under Article 16(2). In specific circumstances, you can flag conditions that restrict what ENISA sees until the receiving CSIRT releases the full notification. The receiving CSIRT decides on further dissemination. This is a narrow provision, not a general right to keep a filing confidential.
The dependency problem
Here is where this stops being a compliance department problem.
A manufacturer owes due diligence over the open source it integrates into its product, and must handle and report vulnerabilities in it. The regulation draws no line between a vulnerability you wrote and one you inherited. For reporting purposes, a component pulled in transitively three levels down by a dependency solver is your vulnerability, in your product.
So the twenty-four-hour clock creates a question you have to answer in minutes:
Is this component in our product, in which versions, and which of them are we still supporting?
Most organisations cannot answer that quickly today. A missing SBOM is rarely the problem. Most organizations have SBOMs, generated at build time and stored somewhere. The problem is whether you can use them under pressure. If you have to go find an SBOM and work through it manually to identify affected products and versions, it is not an operational control
The test is simple, and you can run it this month:
- Pick a component you genuinely depend on.
- Time how long someone takes to produce a definitive list of every product and version that contains it.
- Include which of those are still in their support period.
If that takes longer than an hour, September will be unpleasant.
How to Prepare for CRA Reporting Before 11 September 2026
In rough order of value:
- Scope your products. List everything with digital elements made available in the EU. Confirm which legal entity is the manufacturer of each. This is more contested internally than it sounds.
- Appoint the decision-maker. One named role decides "actively exploited," with a named deputy. Write down what evidence they need.
- Register for the Single Reporting Platform. Do not leave account creation to incident day.
- Designate an authorised EU representative if you are outside the EU.
- Build the 24-hour rota. Wall-clock coverage, including weekends. Test the escalation path.
- Make your SBOM queryable. Component to product to version to support status, in minutes rather than days.
- Map support periods. The obligation follows products you still support, so knowing which those are is a prerequisite.
- Run a tabletop. Take a real historical incident, start the clock, and see whether you would have filed in time. This finds more problems than reading the regulation does.
- Draft the templates now. The 24-hour early warning is short. Having a form ready to fill out is faster and more consistent than starting from scratch during an incident.
What the CRA does not require
Worth saying plainly, because a lot of vendor commentary this year has implied otherwise.
The CRA does not require you to buy curated dependencies, a particular scanner, or any vendor's platform. It requires you to know what is in your product and to report specific events within specific windows. That is a detection-and-disclosure workflow obligation.
Tooling helps to the extent it makes those questions answerable under time pressure. It is not a substitute for having decided who declares active exploitation, or for having someone reachable at 3am on a Sunday. Most organisations that miss a deadline in the first year will miss it for organisational reasons, not technical ones.
The short version
11 September 2026 is real. It applies to products you already sell. It applies to you if you sell into the EU from anywhere. The penalty ceiling for serious breaches is €15 million or 2.5% of global turnover, whichever is higher.
The trigger is narrow, covering active exploitation only. The first filing is thin by design. The clock starts at reasonable certainty, and nothing stops it once it runs.
If you do one thing before September, make it the tabletop. Everything else on the checklist is discoverable from a document. Whether your organisation can actually get a filing out in twenty-four hours is a question only a rehearsal answers.
This is a practical summary, not legal advice. The European Commission published extended guidance on the CRA in July 2026: more than eighty pages, non-binding, with worked examples and flowcharts. It is the right primary source, and your counsel is the right reader of it.
