The CRA's 24-Hour Clock Is Running: Building a Vulnerability Reporting Workflow That Survives Contact With Reality

Most product teams still talk about the EU Cyber Resilience Act (CRA) as a 2027 problem. It isn't. The reporting obligations in the regulation have applied since 11 September 2026, and they cover products that are already on the market, not just new ones. The remaining CRA requirements apply from 11 December 2027.

That changes the question for product security leaders. It is no longer "will our secure development lifecycle satisfy the CRA by 2027?" It is "if someone tells us tonight that one of our shipped products is being exploited, who decides whether the clock has started, and who files what within 24 hours?"

This post covers what the reporting duty requires, where real organizations are likely to stumble, and how to build a workflow that works at 2 a.m. on a Saturday.

What does the CRA require manufacturers to report?

Short answer: Manufacturers of products with digital elements must report any actively exploited vulnerability in their product, and any severe incident affecting the product's security, to ENISA and the designated national CSIRT, on a staged timeline.

The timeline, per the legal analyses cited here (Jones Day; Travers Smith):

StageDeadlineApplies toEarly warningWithin 24 hours of becoming awareActively exploited vulnerabilities and severe incidentsNotificationWithin 72 hoursBothFinal report (vulnerability)Within 14 days after a corrective or mitigating measure is availableActively exploited vulnerabilitiesFinal report (incident)Within one month of the 72-hour notificationSevere incidents

Reports go simultaneously to ENISA and the relevant CSIRT through ENISA's Single Reporting Platform (SRP). Manufacturers must also inform impacted users, and where appropriate all users. Penalties for non-compliance with these obligations can reach €15 million or 2.5% of worldwide annual turnover, whichever is higher.

Two scoping points trip people up:

• There is no size or revenue exemption, and the CRA reaches non-EU manufacturers that sell into the EU.
• No retroactive duty. Exploitation you already knew about before 11 September 2026 doesn't have to be reported retroactively; if exploitation is discovered after that date, the clock starts then.

When does the 24-hour clock actually start?

Short answer: When, after an initial assessment, you have a reasonable degree of certainty that a vulnerability is being actively exploited or that a severe incident has compromised the product.

An "actively exploited vulnerability" is one where there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission .

This definition is where the engineering work lives. It means your organization needs a defined triage decision point, a moment where a named person says "this meets the threshold." Without it, the clock is ambiguous, and ambiguity under a 24-hour deadline is a liability.

A pattern we see often in product security reviews: the vulnerability intake process works (a researcher emails security@, a ticket is created), but nothing connects "a ticket exists" to "a person with authority has judged exploitation status." The ticket sits in a queue with a normal SLA, built for CVSS-based patch prioritization, not for regulatory clocks.

Where reporting workflows break in practice

1. Third-party components make "awareness" murky

An actively exploited vulnerability originating in a component you ship must be reported. If the flaw is unreachable or not exploited in your specific product, reporting isn't mandatory, though voluntary reporting is possible.

To make that call in hours, you need to know what is in each shipped version. That is a software supply chain visibility problem: current SBOMs per release, reachability analysis, and a mapping from component to affected product lines. Teams that generate SBOMs only for customer questionnaires usually discover they are stale or incomplete at exactly the wrong moment. If this is a gap for you, our supply chain security work focuses on dependency, provenance and pipeline controls that feed this kind of answer.

Supplier contracts matter too. The 24-hour deadline doesn't pause because your upstream vendor is slow to tell you about exploitation, so contracts should require prompt disclosure of vulnerability and incident information.

2. Nobody owns the "is it reportable?" decision

Responsibility must be explicitly allocated: who decides the threshold is met, who files, who communicates to users. In many organizations the PSIRT, the SOC, legal, and product management each assume another owns it.

3. Jurisdiction routing is done in a crisis

Manufacturers with an EU establishment report to the CSIRT of the Member State where cybersecurity decisions are predominantly taken. Those without one follow a priority order that starts with the authorised representative's Member State. Work this out in advance, and set up SRP access before you need it. Registration is only required when a notification is due, but access should be ready.

4. Three regimes, one incident

A single incident can trigger CRA, NIS 2 and GDPR reporting. Separate processes will collide; ideally these run through one incident response process with distinct regulatory tracks.

‍

A workable CRA reporting workflow

Here is a practical shape that product security teams can adapt. It is our interpretation of the requirements, not legal advice.

Stage 0: Pre-work (do this now)

• Maintain an authoritative product inventory: every product with digital elements, its supported versions, and its EU market status.
• Keep a per-release SBOM and a way to query "which products contain component X at version Y?"
• Document the reporting RACI: triage lead, regulatory filer, executive approver, customer communications owner, legal reviewer.
• Pre-register and test SRP access; pre-draft early-warning templates.
• Determine your competent CSIRT.

Stage 1: Intake and triage (hour 0–8)

• Treat any credible signal of exploitation, whether from a customer, a threat-intel feed, a bug bounty, or the CISA Known Exploited Vulnerabilities (KEV) catalog, as a regulatory-clock candidate, distinct from ordinary patch severity.
• Triage questions: Is our product affected (version, config, reachability)? What evidence of exploitation exists, and how reliable is it?

Stage 2: Threshold decision (hour 8–16)

• A named decision-maker records "reasonable certainty: yes/no" with rationale and timestamp. Record the "no" decisions as well; they are your evidence of diligence.

Stage 3: Early warning (by hour 24)

• File the minimal early warning. Don't wait for root cause.

Stage 4: 72-hour notification, mitigation and final report

• Update with assessment, severity and mitigations; file the final report within 14 days of a fix or mitigation being available (vulnerabilities) or within one month of the notification (incidents).
• Notify impacted users.

Design the workflow for the worst realistic day: a weekend, a key person on leave, an upstream vendor silent. Tabletop it. A reporting process that has never been rehearsed is a hypothesis.

Why this is a design problem, not just a compliance problem

The reporting duty rewards organizations that already know their products' architecture and attack surface. Deciding "is this reachable in our product?" is much faster if you maintain current architecture diagrams and threat models, and slower if the answer lives in one senior engineer's head.

This is why we treat CRA readiness as an extension of product security fundamentals: threat modeling that stays current as the product changes, a security architecture review that documents trust boundaries and third-party dependencies, and application security testing that produces evidence of due diligence. For software companies with fast release cycles, our software product security practice looks at how to embed this into delivery without slowing it down.

What not to over-read

• Open-source scope is narrower than people assume. Free and open-source software that isn't monetized falls outside the CRA; open-source stewards face limited reporting obligations from 11 December 2027, not September 2026 (Travers Smith). If you are a commercial manufacturer shipping open-source components, however, the reporting duty applies to your product.
• Small-company relief is limited. Micro and small enterprises are shielded from administrative fines specifically for missing the 24-hour early warning deadline, not from the obligation itself.
• This article isn't legal advice. Scope determinations (is your product a "product with digital elements" and not exempt?) need legal review.

Conclusion: what to do this quarter

1. Confirm which of your products are in scope, including those already shipped.
2. Name the person who makes the "actively exploited" call, and a deputy.
3. Make your SBOMs queryable and current per release.
4. Set up and test SRP access; pre-draft early-warning templates.
5. Merge CRA, NIS 2 and GDPR into one incident response process.
6. Run a tabletop: simulate a KEV-listed flaw in a bundled library at 6 p.m. on a Friday.

The 24-hour clock isn't hard because 24 hours is short. It's hard because most organizations don't know, in 24 hours, what they ship.

‍