The 24-hour CRA reporting clock: build the evidence packet before you need it

#cybersecurity #compliance #eu #devops

A vulnerability report lands at 17:20 on Friday. That is the wrong moment to design your incident process.

Educational material only — this is not legal advice.

A vulnerability report lands at 17:20 on Friday. The reporter says a flaw in a bundled component is being exploited. The maintainer is in another time zone. The last two releases used different versions, customer deployment data is incomplete, and nobody on the team has registered for the reporting platform.

The CRA's reporting duties for manufacturers are now live — they've applied since 11 September 2026. Manufacturers must report actively exploited vulnerabilities and severe incidents affecting product security through ENISA's Single Reporting Platform (SRP): an early warning within 24 hours of awareness, a fuller notification within 72 hours, then a final report — within 14 days of a fix for vulnerabilities, or within a month of the 72-hour notification for severe incidents.

The practical challenge isn't memorizing the clock. It's whether the team can identify the product, affected versions, current facts, decision owner, and next update while information is still incomplete.

Know what starts the workflow

Not every CVE match is an actively exploited vulnerability in your product. Create two intake triggers: credible information that a vulnerability in your product or a component is being actively exploited, and an event that may severely impact product security. At intake, don't wait for certainty — open a timed assessment, preserve the original report, assign an incident lead, and record when the organization became aware. "Awareness" starts the legal clock, so agree with counsel how you interpret and record it before you need it.

Separate facts from assessments

Keep observed facts apart from working assessments. Facts: report time and source, affected versions and platforms, indicators of exploitation, customer impact so far, preserved logs and samples. Assessments: is the issue present in shipped versions, is exploitation credible, does it meet severity criteria, confidence level and the next fact needed. A 24-hour warning can acknowledge uncertainty without blending assumptions into facts.

Pre-build the evidence packet

Create the packet structure before triage opens. Product identity: manufacturer, product and version range, platforms, EU distribution channels, support status, update mechanism. Technical evidence: affected artifacts and hashes, release-linked SBOMs, exploit indicators, reachability assessment, fix status. Decision trail: awareness timestamp, incident lead, reportability assessment, submission receipts, customer communication decisions. Don't alter original evidence — add versions and preserve the decision chain.

Give a five-person process to a two-person team

Assign named primary and backup owners for intake monitoring, technical triage, the reportability decision, SRP submission, customer communication, fix approval, and post-incident review. One escalation rule: if the primary is unreachable, the backup takes control after a defined period. The 24-hour window doesn't pause for holidays.

Rehearse the case most likely to hurt

Run a 60-minute tabletop with your actual product: a critical flaw in a bundled update component, two supported releases affected, a fix that breaks one platform's installer, some customers with auto-updates disabled. Ask the team to record awareness, find the affected releases and their SBOMs, draft the 24-hour warning from known facts only, and plan containment and customer guidance. Score it on retrieval time and decision clarity — the goal is removing avoidable delay, not theater.

Five readiness checks for this month

A security contact that reaches a person, not an abandoned inbox. SRP access for the right people, registered before you need it. Release traceability: component to affected versions, fast. One named decision owner, with a backup. One timed rehearsal producing a draft warning within the first hour. Fix access and ownership gaps before buying another scanner.

Has your team tested a CRA reporting workflow — or discovered it has no workable one? Drop a line or two in the comments about what would break first; I'm collecting practical lessons from small vendors, no call needed.

DEV Community