The CRA reporting clock starts 11 September 2026. Here's what an engineering team actually needs.
From 11 September 2026 every manufacturer selling a product with digital elements into the EU owes a 24-hour early warning on actively exploited vulnerabilities — including on products already shipped. Most teams are treating the CRA as a 2027 problem. The reporting half is not.
Most product teams have filed the EU Cyber Resilience Act under "2027." That is half right. The main obligations — the essential cybersecurity requirements, the conformity assessment, the CE marking — land on 11 December 2027. But the reporting obligations under Article 14 do not wait for them. They start on 11 September 2026.
If you sell a product with digital elements into the EU, from that date you owe:
- a 24-hour early warning on any actively exploited vulnerability in your product, or any severe incident affecting its security
- a 72-hour notification with the substantive detail
- a 14-day final report
submitted through the ENISA Single Reporting Platform, which routes to your CSIRT and to ENISA.
Three things about that are easy to miss, and each one changes what you have to build.
It covers products you have already shipped
The reporting duty is not scoped to products placed on the market after September 2026. It attaches to your product portfolio as it exists — including the version a customer deployed three years ago and has not updated since.
That has a practical consequence most teams have not costed. To report on a product, you need to know what is in it. To fix it, you need a route to push an update. If you have shipped firmware, an on-premise appliance, a self-hosted distribution or a desktop client that has no working update channel, the reporting obligation surfaces that gap on a 24-hour clock.
What to do: inventory every product with digital elements you have placed on the EU market, and for each one record its dependency surface and whether you can actually deliver a security update to the installed base today. That inventory is the first deliverable of any CRA programme and it is usually the uncomfortable one.
"Actively exploited" is a decision someone has to make at 2am
The 24-hour clock starts when you become aware of active exploitation. That is a judgement call, and if nobody has written down who makes it and against what criteria, the clock runs while your team debates.
Compare this to the GDPR breach clock, which most teams have internalised: 72 hours, personal data, notify the supervisory authority. The CRA clock is shorter, the trigger is different, and it is a product obligation rather than a data-protection one — so it very often lands on a different team, one that has never had a regulatory reporting duty before.
What to do: write the criteria before you need them. Name the person who makes the call and the person who makes it when they are on holiday. Then rehearse the path once, end to end, as a drill — including the actual submission route. A runbook nobody has executed is a document, not a capability.
For most software, there is no notified body to satisfy
This is the good news, and it is significant.
Products in the CRA's default category — which is most software — self-assess. There is no notified body, no third-party conformity assessment, no accredited auditor, and nothing to buy from a certification firm. The important and critical categories do require third-party assessment, and if you are in one you will need a notified body, but the majority of product companies are not.
What that means commercially: the entire CRA obligation, for most companies, is engineering work. Nobody is gatekeeping it. There is no certificate you are waiting on. The only thing between you and compliance is whether the artefacts exist and the process runs.
The artefacts, concretely
Six things. None of them is a policy document that sits on a shelf.
1. An SBOM, generated in CI, not written by hand. Machine-readable — CycloneDX or SPDX — produced on every build, versioned per release, retained, and covering transitive dependencies rather than just your direct ones. An SBOM you generate manually at audit time is worse than none, because it will be wrong and you will have attested to it.
2. A vulnerability handling process with names in it. Documented intake, a severity model, triage ownership, remediation timelines, and an evidence trail per handled report. The names matter more than the document: an unowned process does not run.
3. A coordinated disclosure policy and a monitored channel. A published policy, a security.txt, an intake address someone actually reads, an acknowledgement process for researchers, and an advisory template you can publish under time pressure. If a researcher cannot find where to report, you will learn about your vulnerability from somewhere worse.
4. The reporting runbook. The 24h / 72h / 14-day sequence, the written criteria for "actively exploited," the named decision-maker and deputy, and the confirmed ENISA submission route. Drilled once.
5. A security update mechanism, and a stated support period. How you deliver a fix to the installed base, and for how long you commit to doing so. The support-period position is a commercial decision with a regulatory consequence, so it belongs with your product leadership rather than your legal team.
6. CI/CD security gates and a dependency policy. Not strictly a reporting artefact, but this is what stops the next report from being about a vulnerability you could have caught. Secret scanning, dependency policy, SAST with a triage owner.
Where this connects to NIS2, and why your EU customers are asking
If your EU customers have started sending supply-chain security questionnaires, this is why. NIS2 Article 21(2)(d) requires in-scope entities to manage supply-chain security, which they discharge by pushing obligations down to suppliers contractually — including to suppliers outside the EU.
So the CRA artefacts do double duty. They are your own obligation as a manufacturer, and they are the evidence your NIS2-regulated customers need to see. In practice the SBOM and the vulnerability handling process are the two documents that turn a stalled supply-chain review into a signature.
What is not happening in September
Two corrections worth making, because a lot of currently-circulating material has them wrong.
The EU AI Act high-risk obligations are not landing. The Digital Omnibus entered into force on 27 July 2026 and deferred the Annex III standalone high-risk obligations to 2 December 2027, and the Annex I product-embedded ones to 2 August 2028. What remains live from August 2026 is Article 50 transparency and Article 4 AI literacy. Nobody needs a €40,000 readiness programme for a disclosure label. If a vendor is selling you AI Act readiness against an August 2026 deadline, they are working from stale material.
The CRA main obligations are not landing either. Essential requirements, conformity assessment and CE marking are December 2027. September 2026 is reporting only. That is a much smaller and much more achievable piece of work — which is exactly why it is worth doing properly now rather than bundling it into a 2027 panic.
The honest scoping note
We deliver this work from Mumbai, and we say so before anyone asks.
For CRA product readiness that turns out not to matter, and it is the reason this is the one EU engagement we actively recommend. SBOMs, vulnerability handling processes, disclosure policies and CI gates touch no personal data. So none of the machinery that constrains our other EU work — Standard Contractual Clauses, a Transfer Impact Assessment, supplementary measures, all necessary because India has no EU adequacy decision — applies here at all. The transfer question simply does not arise.
We are also not a notified body and cannot perform conformity assessment, and we do not sign your declaration of conformity. That declaration is the manufacturer's, and it stays yours. What we build is the evidence behind it.
If you want the specifics, the EU Cyber Resilience Act Readiness page sets out the scope, and where we work sets out our full published position per market — including what we decline in the EU and why.
Regulatory position as at 18 August 2026. The CRA reporting obligations take effect 11 September 2026; main obligations 11 December 2027. This is a practical engineering reference, not legal advice — take advice on your own product's category.