EU Cyber Resilience Act · Reg (EU) 2024/2847 · reporting live 11 Sep 2026
CRA reporting starts 11 Sep 2026 — the 24h/72h/14-day runbook, signed.
From 11 September 2026, every manufacturer of a “product with digital elements” on the EU market owes ENISA an early warning within 24 hours of learning of an actively exploited vulnerability or severe incident, an updated notification within 72 hours, and a final report within 14 days — via the ENISA Single Reporting Platform, with the relevant national CSIRT notified too. The CRA Readiness Kit is the runbook, the SBOM workflow, and the CI gate that make those clocks survivable — every artifact in the same signed dialect as the rest of our evidence rail.
A template plus tooling — not legal advice, not a conformity assessment.
The deadline mechanics
Three clocks, all starting from the moment the manufacturer becomes aware. The trigger is an actively exploited vulnerability in the product, or a severe incident affecting the product’s security. Reports go to ENISA via the Single Reporting Platform, with notification also to the relevant national CSIRT.
| Window | Deadline from awareness | What to submit |
|---|---|---|
| Early warning | within 24 hours | Initial notification that an actively exploited vulnerability or severe incident exists; whether it is believed unlawful or malicious; which member states may be affected. Minimal facts, sent fast. |
| Notification | within 72 hours | Updated report: severity and impact assessment, and — where available — indicators of compromise plus any corrective or mitigating measures taken or advised. |
| Final report | within 14 days | Full report: description of the vulnerability or incident, its severity and impact, root cause, and the mitigation or remediation applied. (For incidents: after handling.) |
The conformity-assessment framework is live — relevant if a product is later classified important or critical.
The 24h / 72h / 14-day ENISA reporting clocks are live. The runbook must be operational by this date.
CE marking, full essential-requirement conformity, and documentation obligations in force.
Who is in scope: any “product with digital elements” placed on the EU market — software and connected hardware alike. If you ship digital products into the EU, assume this reaches you and confirm the boundary with counsel.
What the kit contains
The step-by-step runbook: four named roles (Incident Lead, Engineering On-Call, Counsel/Compliance, Comms/Customer), the awareness-timestamp discipline that starts the clocks, the triage questions, and the 24h / 72h / 14-day filing sequence to ENISA and the relevant national CSIRT.
Working commands for JavaScript/TypeScript (npx @cyclonedx/cyclonedx-npm) and Python (cyclonedx-py) trees, aggregated per shipped artifact and regenerated on every dependency change — the machine-readable component inventory the CRA expects a manufacturer to hold.
Software-composition analysis wired into CI so a known-vulnerable dependency fails the build: npm audit and pip-audit against the lockfiles, or an SBOM-aware scanner (Grype, Trivy, OSV-Scanner) over the generated CycloneDX files, with an accepted-risk note required to pass a high/critical finding.
A minimal register where every candidate incident lands with its awareness timestamp, triage verdict, filings, and closure — so the 24-hour clock is measured from a recorded moment, not reconstructed from memory afterwards.
Every artifact in the kit — the SBOM, the runbook, the register entries — is signed with the same Ed25519 approach as the rest of our evidence rail, so a downstream operator or supervisor can verify what they were handed is what was produced.
We run this ourselves
We ship digital products into the EU, so the 11 September clocks apply to us too. The kit is not theory sold at a distance: it is the same compliance pack we are standing up for our own products against the same date — the same runbook roles, the same CycloneDX commands over our own dependency trees, the same SCA gate in our own CI, the same Ed25519 signing root.
Honestly stated: standing up a runbook is work — registering platform access, naming the roles, keeping the SBOM current on every release. We publish the workflow we practice, and where our own pack still has an open item, the pack says so rather than pretending otherwise.
The honest boundary
The CRA Readiness Kit is a template plus tooling. It is not legal advice and not a conformity assessment, and holding a signed SBOM does not make a product compliant. Whether the CRA classifies you as a manufacturer, which distribution modes cross its threshold, and the precise reporting-window wording are questions for Regulation (EU) 2024/2847, ENISA’s platform guidance, and your counsel. We measure and we template; we never decide.
No public prices — pricing lives behind the enterprise door. The explainer, like all our public material, is free for everyone, always.
Frequently asked
What starts on 11 September 2026 under the Cyber Resilience Act?
From 11 September 2026, manufacturers of products with digital elements placed on the EU market must report actively exploited vulnerabilities and severe incidents to ENISA via the Single Reporting Platform, with notification also to the relevant national CSIRT: an early warning within 24 hours of becoming aware, an updated notification within 72 hours, and a final report within 14 days for a vulnerability (after handling, for an incident).
Who is in scope?
The CRA covers 'products with digital elements' placed on the EU market — software and connected hardware alike. If you ship a digital product into the EU, assume the reporting obligations reach you and confirm your exact classification with counsel.
What is the CRA Readiness Kit?
The evidence artifacts a product with digital elements needs, in one signed dialect: the ENISA reporting runbook template (roles, clocks, filing sequence), a CycloneDX SBOM generation workflow, an SCA gate pattern for CI, an incident-register pattern, and an Ed25519 signing approach so every artifact is verifiable.
Is this legal advice or a conformity assessment?
No. The kit is a template plus tooling. It is not legal advice and not a conformity assessment — confirm your scope, classification, and the precise reporting-window wording against Regulation (EU) 2024/2847 and ENISA platform guidance with your counsel.
Council of AI (CSOAI Ltd) is an independent measurement body. Dates above (11 Jun 2026, 11 Sep 2026, 11 Dec 2027; the 24h / 72h / 14-day windows) should be confirmed against the final text of Regulation (EU) 2024/2847 and ENISA Single Reporting Platform guidance before you rely on them — treat the tables here as operational scaffolding, not the legal text.