Compliance & provabilityField notes
CRA reporting duty: what your system must deliver within 24 hours
4 min read
Since 11 September 2026, the reporting obligations of the Cyber Resilience Act have applied. Anyone placing a product with digital elements on the EU market must report an actively exploited vulnerability or a severe security incident: an early warning within 24 hours, followed by a more detailed notification within 72 hours. Reports go through the single reporting platform to the national CSIRT coordinator and ENISA.
The legal side is clear. The question inside teams is different: can our system actually deliver this?
It hits organisations that should be moving something else forward. Europe needs its focus on innovation — not on an incident outside the organisation's control suddenly blocking a week or more. Several people who should broadly know what to do are still pulled out of their daily work. Attention moves away from what matters.
That is an organisational problem: splitting people and attention across several topics at once. It is the same criticism made of multitasking and too many meetings — made worse when someone is ill or on leave. Permanent availability from individuals cannot be the answer.
What really starts the clock
The 24 hours run from awareness. Not from confirmation, not from a completed analysis.
A customer reports unusual behaviour at 17:40. Someone investigates at 21:00 and recognises the exploitation — from then on, less than one working day remains.
The early warning does not require a complete root-cause analysis. It initially contains minimal information about the event and affected Member States; for security incidents, it also says whether unlawful or malicious action is suspected. Even so, the team must already understand what it is looking at. Anyone who first has to piece that together from logs, snapshots and the memory of two colleagues spends the deadline doing archaeology instead of containment.
Duty, system capability, evidence
| Reporting stage and duty | What the organisation must be able to do | How to evidence it |
|---|---|---|
| 24 hours: classify the event and name affected Member States | Reliably record when awareness began and the initial scope | Opened incident record with timestamp, source and unchanged initial assessment |
| 72 hours: describe the product, nature of the exploitation or incident, and measures | Narrow down affected versions, users or tenants | Query by version and tenant key, with attribution technically enforced |
| Final report: set out root cause, severity, impact and measures | Append to the record without overwriting earlier findings | Versioned incident history with author and reason for every change |
| CRA product documentation: document components and dependencies | Associate the legally required SBOM with the exact build shipped | Automatically generated and archived bill of materials for each build |
| Organise notification and containment in parallel | Make responsibilities and configuration or permission changes traceable | Named reporting role and change history with author and reason |
The 72-hour notification is followed by a final report: for vulnerabilities, no later than 14 days after a corrective measure becomes available; for severe security incidents, within one month of the 72-hour notification.
The right-hand column is what decides. All of this can be assembled — just rarely within the deadline, and even less often in a form that survives later scrutiny.
Why logs arrive too late
Technical logs are built for operations and debugging. They show that something changed. Rarely why or on what business grounds. They are truncated, rotated and may disappear early, depending on retention. Incidents, meanwhile, often surface weeks later.
Then there is the structural catch: a bolt-on log has to be maintained with every new interface. It is incomplete exactly where an integration was built under deadline pressure — often where the incident originates.
Five questions before the emergency
- Can we say, for any record, within an hour, who changed it when and why?
- Can the affected set of tenants be queried — or does it have to be estimated?
- Do we know which dependencies are in the version actually shipped?
- Who is allowed to send the notification, and is that person reachable on a Sunday evening?
- Does our first report remain intact when the picture changes later?
If three of those get a “probably”, the issue is not compliance. It is architecture.
The limit
The CRA is no reason to rebuild a running system. For most organisations, a narrow cut is enough: the one domain where decisions count — approvals, permissions, contract and pricing logic. That is where a dependable event history pays off. The rest stays.
Conversely, a perfect event stream does not replace a process. If nobody has defined who reports and when the clock starts, the best traceability will not help.
Further reading
- Cyber Resilience Act: what it means for your software
- Provability as an architecture topic
- Audit-proof logging: why database logs do not count in an audit
- Proof Check: ten questions, ten minutes
Articles on this topic
Compliance & provabilityFoundation
Tenant separation that survives the security questionnaire
One forgotten filter is a reportable incident. Why isolation in application code is not evidence — and which models enterprise buyers accept.
Compliance & provabilityField notes
Tamper-proof logging: why database logs do not count in an audit
Almost every system logs. Audits still fail on the question of who changed what and when. The difference between a log and evidence — and what creates it.
Compliance & provabilityNote
Twelve roles become three: what Gartner's team shapes mean for provability
Gartner expects smaller engineering teams. The role map behind it mostly removes translation roles — and with them the places where decisions used to get written down as a side effect.