CRA's 24-hour clock starts when you notice, not when it suits you

When the clock starts

CRA's 24 hours works like when you lose your bank card: the clock starts when you notice it's gone, not when it's convenient to call the bank. Article 14 says manufacturers must report actively exploited vulnerabilities and severe incidents within 24 hours of becoming aware, using ENISA's single reporting platform ^[1].

For financial entities, DORA has been asking for speed since 17 January 2025. Delegated Regulation 2024/1774 under DORA requires logging procedures that protect log systems and log information against tampering, deletion and unauthorised access, and that detect failures in logging ^[2]. When a bank also makes software, or when a software maker serves the finance sector, both sets of rules apply. The duties don't cancel each other out; they stack.

What has to be reported

CRA defines a severe incident as one that has caused or is capable of causing severe operational disruption of the product's services or financial loss for the user or other natural or legal person, or has caused or is capable of causing physical injuries or fatalities ^[1]. Actively exploited vulnerabilities are those being used in attacks.

DORA talks about major ICT-related incidents: incidents that have a high adverse impact on the network and information systems supporting critical or important functions ^[2]. A financial entity hit by such an incident reports to its supervisor, and if the incident involved a product with digital elements, the manufacturer of that product reports under CRA.

For manufacturers selling to financial entities, the overlap is real. A vulnerability exploited against a bank's payment system could trigger both CRA and DORA reporting duties, with different timelines and different recipients.

The question nobody wants asked later

Both frameworks count hours. CRA says 24 hours from becoming aware. The difficult part is showing, months later, when awareness actually started. Say a junior engineer sees unusual traffic on a Friday afternoon, mentions it in Slack and goes home. Say the security team escalates it on Monday. When did the organisation become aware: Friday at 15:47 or Monday at 09:15?

That question can decide whether a deadline was met. It also decides whether the log showing what happened next can be trusted. If the people keeping the log are the same people who might benefit from moving the timestamps, the log is easier to challenge.

Logs you can check

DORA's technical standard says logs must be protected against tampering. CRA doesn't prescribe how logs are kept, but the reporting duty assumes you know what happened and when. Both assume the logs hold up under scrutiny.

A digital witness makes a log checkable by someone who doesn't have to trust the keeper. Here's how it works for an incident timeline. The thing to seal is each step as it happens: the first detection note, the decision to escalate, and each report as it is sent. Sealing takes a fingerprint of the record, not the record itself, so the log never leaves your systems. The fingerprint is posted on WitniumChain, where any later change would show.

When a supervisor or an auditor asks when you knew, anyone you share the record with can check that it's the one written at the time. It doesn't show that the report was complete or that the response was adequate. It shows that nobody has quietly rewritten the timeline since.

You seal each step through the REST API, the SDK or the MCP server. Your system sends the fingerprint and gets a witness ID back. To check, the verifier calculates the fingerprint again and compares it with the sealed one. The first 2,000 witnesses a month are free. Documentation here.

How it would work

1. When the engineer notes unusual traffic, the security platform seals that note.
2. When the team escalates, that decision is sealed.
3. When the report goes to ENISA or the supervisor, the sent report is sealed.

Each step gets its own fingerprint, its own witness ID and its own timestamp. Nobody, including us, can change a sealed record without it showing in the check.

Overlap isn't duplication

CRA and DORA ask for different things from different actors, but they share a premise: when something goes wrong, knowing what happened and when you knew it matters. For a financial entity selling software, or a manufacturer serving banks, both frameworks apply.

The overlap creates administrative load, but it doesn't create ambiguity. CRA's 24-hour clock runs for manufacturers reporting product vulnerabilities. DORA's incident reporting runs for financial entities reporting disruptions to critical functions. An event can trigger both, and then you report twice, to different recipients, on different templates.

What doesn't change is the need for logs you can stand behind. Whether it's ENISA asking under CRA or FI asking under DORA, the question is the same: can you show when you first knew, and what you did next?

What this means for you

If you manufacture products with digital elements and serve financial entities, assume both CRA and DORA apply and that an incident could trigger both reporting duties. The timelines are short, and the question of when awareness started will come up.

Before the next incident, ask:

• Who sees the first signs of a problem, and where is that logged?
• At what point does a detection become awareness for the organisation?
• Can we show, six months later, when each step in our response was recorded?
• Are the logs kept in a way that would hold up if someone questioned them?

A digital witness doesn't replace your incident response or your reporting process. It gives you a checkable record of when each step happened, so the timeline doesn't depend on trust.

What to watch

CRA's reporting duties under Article 14 apply from 11 September 2026 ^[1]. Financial entities have been under DORA since 17 January 2025 ^[2]. For products already on the market, CRA's transitional provisions give manufacturers until 11 December 2027 to comply with the essential requirements, but the reporting duty comes earlier.

If you're writing your CRA or DORA implementation plan, put log integrity and incident timelines on the same page. The frameworks assume you have both.