The Cyber Resilience Act has felt distant for many product teams because its full application date sits in December 2027. That is no longer a useful way to plan. The first real operational deadline arrives earlier: from 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents affecting products with digital elements.
That deadline changes the work from legal tracking to operational readiness. A reporting clock is not started by a quarterly governance meeting. It starts when the manufacturer becomes aware of exploitation or a severe incident. By then, the team needs a clear record of what the product is, where it is shipped, who owns the vulnerability decision, what evidence is reliable, and how customers can be protected.
What the CRA reporting clock expects
The European Commission’s current reporting page says manufacturers need to submit an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report later in the process. ENISA is building the Single Reporting Platform so manufacturers can report once through the EU system instead of trying to manage separate national notifications manually.
For security teams, the practical question is simple: can you assemble that first 24-hour report without starting from a blank document?
The evidence to prepare before September
- Product scope: product name, versions, supported branches, cloud dependencies, remote data-processing components, and affected markets.
- Exploit signal: why the team believes exploitation is active, which telemetry supports the view, and what remains uncertain.
- Security impact: availability, authenticity, integrity, and confidentiality impact in plain language.
- Fix path: patch status, mitigation, update channel, customer guidance, and rollback risk.
- Ownership: named incident lead, product owner, legal contact, communications owner, and engineering approver.
Make the process boring before it matters
The safest reporting workflow is the one the team has already rehearsed. Run a tabletop using a real component from your software bill of materials. Pretend there is exploitation in the wild. Ask who decides whether the evidence is credible, who drafts the notification, who approves customer wording, and who knows whether the product is available in each Member State.
Teams often discover that the hard part is not the form. The hard part is product lineage, ownership, and confidence. If those are weak, the reporting process becomes a scramble at the exact moment when regulators and customers expect calm.
A useful 2026 target
By the end of summer 2026, every in-scope product should have a lightweight CRA reporting pack: contacts, product inventory, vulnerability intake route, SBOM location, customer update route, severity model, and a tested approval path. That pack will not make an incident easy, but it will keep the first day from being improvised.
Further reading: European Commission CRA reporting obligations, CRA implementation timeline, ENISA Single Reporting Platform.