The Cyber Resilience Act sets reporting deadlines measured in hours

Reporting rules that count the hours

The Cyber Resilience Act applies from 11 September 2026, and one of its first requirements is about speed. When a manufacturer of a product with a digital element becomes aware that one of its products is subject to an actively exploited vulnerability or a serious incident, it must report it through ENISA's common platform ^[1].

The deadlines are tight. An early warning goes out within 24 hours of becoming aware, limited to what is known at that point. A full incident notification follows within 72 hours, and a final report within 14 days of the notification ^[1]. For context, DORA's reporting rules for financial entities count in hours as well: four hours for major incidents ^[3].

What counts as serious

A serious incident is one that has caused or is capable of causing death or serious damage to people's health, significant and widespread disruption to essential services, serious economic loss or significant material or immaterial damage, or that has had a serious impact on public security or public health ^[1].

An actively exploited vulnerability is one where there is reliable evidence that executable code or a technique capable of exploiting it exists and is being used in the wild ^[1].

One platform, many regulators

The reporting goes through ENISA's single reporting platform, the European Cyber Vulnerability Database ^[1]. That is a change from the current arrangement, where manufacturers report to different authorities depending on the sector. Under the Act, ENISA routes reports to the relevant supervisory authorities, notified bodies and other EU entities ^[1].

The obligation sits with the manufacturer. Distributors and importers must also pass on information they receive about vulnerabilities and incidents, without delay ^[1].

Security requirements from December 2027

From 11 December 2027, products with digital elements placed on the market must meet essential security requirements set out in Annex I of the Act ^[2]. These include the ability to record and monitor security-relevant events over the product's lifetime, protection of stored and transmitted data, mechanisms for secure updates, and handling of known exploitable vulnerabilities during the expected support period ^[2].

The requirements are similar to what high-risk AI systems must do under the AI Act's Article 12, which applies from 2 December 2027 for Annex III systems. That article asks for automatic recording of events ^[4]. Neither rule specifies how logs must be protected, but both place weight on having them.

When a timeline becomes evidence

Reporting under the Act is based on awareness: when the manufacturer became aware of the vulnerability or incident. That makes the timeline itself a question of evidence.

Say a supervisor later asks why an early warning went out after 30 hours instead of 24. The manufacturer's answer turns on when it knew. Notes and logs show that, but only if they are kept in a way that makes them hard to question.

Sealing the incident timeline

Here, the thing to seal is each step of an incident as it happens: the first detection note, the decision to escalate, and each report as it is sent to the platform.

Sealing takes a fingerprint of the record, not the record itself. The record stays in your systems. The fingerprint is sealed through WitniumChain, and you get a witness ID back. When a supervisor or an auditor asks to see the timeline, anyone you share the records with can calculate the fingerprint again and check that it matches the sealed one. A single changed character will make it not match ^[5].

What it shows is when each step was recorded, in a way nobody can quietly rewrite afterwards, even someone with administrator rights. What it doesn't show is that the report was complete or that the response was adequate. Those are separate questions.

Your system sends the fingerprint through the REST API, the SDK or the MCP server. The first 2,000 witnesses a month are free ^[5].

How it would work

1. Your incident response system writes a detection note. It sends a fingerprint to seal the note.
2. An hour later, someone decides to escalate. That decision is sealed.
3. The early warning is sent at 22 hours. The system seals a copy of what was sent, and when.

If asked later, you show the sealed records and their timestamps. Anyone can check that they haven't changed.

What this means for you

If you make or import products with digital elements, three questions are worth asking now:

• Who in the organisation will know when we become aware of a vulnerability or incident, and how will they know?
• Can we show when we knew, not just that we knew?
• Are our logs and incident records kept in a way that will hold up if questioned?

The Act does not say logs must be tamper-proof or immutable. It asks for the ability to log and monitor security events. The evidential value of those logs is a separate matter, and one that will come up when a report is challenged or an incident is investigated.

What to watch

11 September 2026: reporting obligations apply.

11 December 2027: products placed on the market after this date must meet the essential security requirements in Annex I ^[2].

11 December 2030: products already on the market by 11 December 2027 must comply with the Act's requirements ^[2].

Sources