CRA reporting obligations: what changes on 11 September 2026
On 11 September 2026, the first operative obligations of the EU Cyber Resilience Act take effect: from that date, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents having an impact on the security of their product — with an early warning due within 24 hours of becoming aware. The rest of the CRA follows on 11 December 2027, but the reporting duty arrives first, and it applies to products already on the EU market today.
This guide covers who has to report, what triggers a report, the deadlines, and what has to exist inside your company before a 24-hour clock is survivable.
What changes on 11 September 2026
Until now the CRA has been in transition: in force since 10 December 2024, binding no one yet. September 11 ends that for one specific duty — Article 14 reporting. Everything else (essential requirements, conformity assessment, CE marking) stays future tense until December 2027; the reporting obligation does not wait for it.
Two things make this date sharper than a typical compliance deadline. First, the clock is short: 24 hours to an early warning is an operational test, not a paperwork one. Second, the duty attaches the moment you become aware — it does not matter whether the vulnerability is fixed, whether the product carries CE marking yet, or whether the product was sold last year.
Who has to report, and to whom
The duty falls on manufacturers — including anyone who sells software or connected hardware in the EU under their own brand, wherever the company itself is based. A US or UK company with EU customers reports like an EU one.
Reports go to two recipients at once, through one channel: the CSIRT designated as coordinator for the member state concerned, and ENISA, via the single reporting platform established for the purpose. If you have no reporting contact mapped and no account or process for the platform, that is the first gap to close.
What counts as an actively exploited vulnerability
A vulnerability in your product for which there is reliable evidence that someone has executed malicious code in a real environment using it — not a theoretical finding, not a pentest result, not a CVE in a component that nobody has used against you. The threshold is exploitation in the wild, in your product or via your product.
The subtlety is the word aware. A researcher email, a customer ticket describing suspicious behavior traced to your product, threat-intel naming your CVE as exploited — awareness can arrive through any door. If nothing routes those doors to the person who owns the 24-hour clock, the company is aware and the clock is running while the right people are not.
What counts as a severe incident
An incident having an impact on the security of the product with digital elements — the regulation's examples run to compromise of the manufacturer's build or update infrastructure, or an incident that could affect the confidentiality, integrity or availability of the product for its users. The center of gravity is the product and its supply chain, not your corporate IT in general: a compromised laptop is an internal incident; a compromised update-signing server is a CRA report.
If your organization is also in scope of NIS2 or DORA, note that the reporting regimes stack rather than replace each other — the same event can trigger more than one duty, to different authorities, on different clocks.
The reporting timeline: initial notification, intermediate, final
| Step | Deadline | Content |
|---|---|---|
| Early warning | Within 24 hours of awareness | That exploitation or a severe incident is occurring; which member states are affected where known |
| Notification | Within 72 hours of awareness | What is known: nature of the exploit or incident, affected product and versions, corrective or mitigating measures taken or available |
| Final report | Vulnerabilities: no later than 14 days after a corrective or mitigating measure is available. Incidents: within one month of the 72-hour notification | Description, severity and impact, root cause where available, remediation applied |
Two practical notes. The early warning is deliberately thin — it exists so authorities can spot campaigns across manufacturers, and sending it does not commit you to conclusions you have not reached. And the final-report clock for vulnerabilities starts from the availability of a fix, so the duty quietly includes producing one.
What you need in place before you can report
Reporting is the last step of a chain, and the CRA already prescribes most of the chain in its vulnerability-handling requirements. A useful self-test — a few of the questions we ask when assessing CRA readiness, reworded into plain language:
- Do you operate a coordinated vulnerability disclosure policy, published where a researcher would look for it?
- Is there a public contact address for reporting vulnerabilities in your products — and does someone own the inbox?
- Can you produce a software bill of materials for each product, so a component CVE can be mapped to affected versions within hours?
- When a vulnerability is confirmed, is it remediated without undue delay and shipped as a free security update?
- Are fixed vulnerabilities publicly disclosed once updates are available, with enough information for users to act?
If you cannot answer one of these confidently, that tells you where the 24-hour clock would break down. These five are a sample, not the list — the full picture is what a readiness assessment is for.
What comes next: December 2027
On 11 December 2027 the main body of the CRA applies: the essential cybersecurity requirements of Annex I, conformity assessment, technical documentation, CE marking, and the support-period obligations. Products that cannot show conformity stop being placeable on the EU market.
The sensible sequencing is to treat September 2026 as the forcing function: the capabilities that make reporting survivable — component inventory, disclosure process, update pipeline, ownership — are the same capabilities December 2027 will demand evidence of. Built once, they serve both deadlines. Our explainer on what the Cyber Resilience Act is covers the full set of requirements behind that second date.
Assessing where you stand
The gap between "we take security seriously" and "we can notify a CSIRT within 24 hours with the affected versions attached" is precisely the gap the CRA was written to expose. It is measurable: map the requirements, check what exists, list what does not.
ZeroRisk runs that assessment for you — the agent maps your current state against the CRA and the other frameworks that apply to you, and the same platform tracks whether your own suppliers can make the same claims. See how it works on the CRA compliance software page, or start with the free gap report.