10 min read - CRA reporting starts: rehearse the 24-hour workflow

On 11 September 2026, one part of the EU Cyber Resilience Act becomes an operational deadline. Manufacturers must report an actively exploited vulnerability contained in a product with digital elements, or a severe incident affecting that product's security, through ENISA's Single Reporting Platform. The European Commission's reporting page sets a 24-hour early warning and a fuller notification within 72 hours.

Three days before the start date, a long policy document is less useful than a timed rehearsal. Can your product, security, engineering and legal owners turn a weak signal into a supported reporting decision, identify the right product versions and submit the early warning while the facts are still incomplete?

The rehearsal below addresses that question. It does not determine if a company or product falls within the CRA, interpret when a specific organisation becomes aware, or replace qualified legal advice.

Separate the September duty from the 2027 programme

The CRA does not switch on all at once. The legal text of Regulation (EU) 2024/2847 says that Article 14 reporting begins on 11 September 2026, while the regulation generally takes effect on 11 December 2027. Treating the earlier date as shorthand for complete CRA conformity creates two problems: teams may spend the remaining days on broad documentation work, and the actual reporting route may still have no owner.

Start with a bounded question for each product sold or otherwise made available in the EU: which legal entity is the manufacturer for CRA purposes, and who has authority to file on its behalf? Confirm that answer with counsel against the product and commercial arrangement. A development team, distributor, integration partner and manufacturer may all touch the same software, but contact with the code does not settle the legal role.

The same caution matters for a France-Morocco delivery team. Office location, repository ownership or who first receives an alert does not by itself identify the manufacturer or coordinating CSIRT. Route the evidence to the verified manufacturer role instead of inventing a legal responsibility from the team chart.

Keep the September workstream narrow: assess the manufacturer role, name primary and backup filers, prepare the three reporting stages, and rehearse both triggers. Other CRA work still needs its own governed plan.

Give the two reporting triggers different questions

Article 14 has two triggers, and a generic "security event" queue can blur them.

For a vulnerability, the regulation defines an actively exploited vulnerability as one for which reliable evidence shows that a malicious actor exploited it in a system without the system owner's permission. The reporting duty concerns such a vulnerability when the manufacturer's product with digital elements contains it. A public proof of concept, a high severity score or a scanner alert does not repeat that definition. Your triage record should state what evidence supports active exploitation and how the affected component maps to maintained product versions.

For an incident, Article 14 treats the case as severe when it negatively affects, or can negatively affect, a product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or when it has led or can lead to malicious code in the product or a user's network and information systems. Ask what happened to the product's security properties and why the available evidence meets or does not meet that threshold.

Do not wait for perfect attribution. The early warning exists before the team finishes its investigation. But do not turn uncertainty into a guess either. Record the source, time received, affected artefact, known versions, confidence and unanswered questions. Then preserve the decision, including why the team filed, did not file or escalated for further review.

Finland's national cybersecurity authority, Traficom, gives manufacturers a useful operational sequence in its CRA preparation checklist: identify in-scope products, appoint primary and secondary representatives, plan intake channels, document the process and practise it. It also advises final-product manufacturers to assess third-party component reports and report once they confirm that the issue affects their product. Apply that guidance to your own facts and legal role.

Define when the clock reaches the reporting team

The statutory wording ties the 24-hour and 72-hour periods to the manufacturer becoming aware. No generic workflow can decide that moment for a particular case, but a rehearsal can expose the delays that make the question dangerous.

Map each likely intake point and its handoff to the people who assess the threshold. Include security mailboxes, support, dependency alerts, providers and reports sent to named engineers. Record who monitors each route, its coverage hours, the backup and the maximum handoff time.

A useful evidence log can stay small:

Avoid an automation that starts or stops the legal clock without human review. Automation can collect timestamps, enrich component data and alert the on-call team. The accountable people still need an agreed method for judging reliable evidence, product impact and severity.

Prepare the three filing stages before an incident

The Commission's reporting summary and Article 14 describe a staged record rather than a finished post-incident report due on day one.

The early warning is due without undue delay and within 24 hours of awareness. For an actively exploited vulnerability, it includes the Member States where the manufacturer knows the product was made available, where applicable. For a severe incident, it also states if the manufacturer suspects unlawful or malicious acts and, where applicable, identifies those Member States.

Within 72 hours of awareness, the manufacturer supplements the record with the available product, exploit or incident information, an initial assessment, and corrective or mitigating measures. It can also indicate how sensitive it considers the notified information.

The final deadline then splits. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, it is due within one month after the 72-hour incident notification.

Build separate templates for those stages. Prefill only the verified manufacturer name, product catalogue and authorised contacts. Leave incident facts blank; plausible defaults are easy to submit and easy to get wrong.

User communication needs a linked track. Article 14 also requires the manufacturer, after becoming aware of a reportable vulnerability or incident, to inform affected users and, where appropriate, all users about the issue and measures they can deploy. Prepare approval and delivery routes without pretending the same message will suit every product or event.

Rehearse the platform, not a screenshot of it

ENISA's Single Reporting Platform page states that the platform will support mandatory reporting from 11 September. It publishes a glossary, registration guidance and instructions for primary and secondary Assigned Representatives, while warning that the guidance may change.

Use the current material to assign both representatives and review the fields. Link to the official page in the runbook, and record how the team will verify platform status before a real submission.

For a French manufacturer, ANSSI's CRA page identifies CERT-FR as the coordinating CSIRT and explains that the SRP sends the notification to that coordinator and, except in exceptional circumstances, to ENISA. A manufacturer established elsewhere should verify its coordinator in the official ENISA material instead of copying the French route.

Do not use a production incident as the platform test. Walk the assigned representatives through the current guidance with a fictional case, confirm that backup access works, and retain the exercise log. Do not submit the fictional case to the live reporting channel unless the official platform provides an explicit test function and its instructions permit that use.

Run a four-hour tabletop with incomplete facts

Use a fictional software product and synthetic evidence. At minute zero, give customer support a report that a flaw in a bundled component appears to have been exploited. Do not tell the participants if the Article 14 threshold is met.

Require the team to:

1. preserve the original report and time;
2. identify the assessed manufacturer and affected product versions;
3. separate evidence of active exploitation from evidence that the product contains the flaw;
4. decide which specialist must resolve the remaining legal or technical question;
5. draft the early warning with unknown fields marked as unknown;
6. prepare the 72-hour investigation plan and the user-communication decision.

Halfway through, remove the primary Assigned Representative from the exercise. Later, add a second product version whose dependency record is incomplete. These changes test the backup and product mapping rather than the team's ability to follow a clean script.

Finish with timestamps. Measure the longest handoff, the time to identify the manufacturer, the time to assemble the early-warning fields and if the backup completed the authorised step. Give every unresolved point an owner and a due date before 11 September.

This rehearsal will not make the organisation CRA compliant. It gives leaders something more modest and reviewable: evidence that a specific reporting path can process an intake and reach a supported decision within the tested time.

Sources and limitations

We opened and reviewed all sources below on 8 September 2026.

• Regulation (EU) 2024/2847 on EUR-Lex supplies the definitions, Article 14 reporting stages, user-information duty and application dates.
• The European Commission's CRA reporting page summarises the deadlines, routing and Single Reporting Platform start date.
• ENISA's Single Reporting Platform page provides the current platform resources, glossary and Assigned Representative guidance.
• ANSSI's CRA regulatory page identifies the French coordinating CSIRT and the French implementation timeline.
• Traficom's manufacturer preparation checklist supplies independent national-authority guidance on product inventory, representatives, intake and rehearsal.

The regulation and official guidance, not this article, control. ENISA says its platform instructions may change. We did not assess any company's manufacturer role, product scope, awareness time, notification content or other legal duties. The workflow and tabletop are Exceev's proposed planning method, not a regulator-approved procedure or evidence of compliance. Verify the live platform, current guidance and legal analysis before acting.

Our cybersecurity clause guide for technology vendors can help teams identify contract questions that sit beside regulatory reporting. Exceev's Discover, Build, Deliver process shows how we turn a time-bound requirement into a tested engineering plan without treating a checklist as proof.