CRA incident and vulnerability reporting playbook

Practical guidance, not legal advice. The article numbers and deadline wording below are drawn from Article 14 of Regulation (EU) 2024/2847 and the European Commission's reporting guidance; verify them against the official text before a real filing. Reporting obligations start 11 September 2026.

The one thing to understand first

There are two different clocks, and mixing them up is the most common mistake. Your vulnerability disclosure program runs on a business-day rhythm: a researcher emails you, you reply in a few days, you fix on a sensible schedule. That is a courtesy process, and you control the pace.

This is the other clock. When one of two specific things happens to a product you have on the EU market, the CRA requires you to notify the authorities on a fixed timeline measured in hours, whether or not you have a fix, whether or not it is a weekend. This is a legal duty, and the penalties sit in the regulation's higher tiers (up to 15 million euro or 2.5% of worldwide annual turnover, whichever is higher).

The two triggers

You are on the reporting clock when either is true for a product with digital elements you have made available on the EU market.

• An actively exploited vulnerability: a vulnerability in your product that is being used in an attack, not merely one that exists or was reported to you. The trigger is the exploitation, not the discovery.
• A severe incident that affects your product's security: under Article 14, an incident is severe when it negatively affects, or could negatively affect, your product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions; or it has led, or could lead, to the introduction or execution of malicious code.

If you are unsure whether something crosses the threshold, treat it as if it does and get counsel on the phone. The clock does not pause while you decide.

The clocks, on one page

The two triggers share the 24-hour and 72-hour steps and differ only at the final report.

Becoming aware is when your clock starts. The moment anyone in your company knows, the 24 hours are running. That is why the roles below need to be assigned before anything happens, not during.

Where the reports go

You file through the ENISA Single Reporting Platform (the SRP), established under Article 16. Your notification goes to the CSIRT designated as coordinator in the Member State where your business has its main establishment in the Union, and it is made available to ENISA at the same time. The receiving CSIRT passes it to other Member States where your product is available.

Two things to do now, in calm conditions: confirm which Member State is your main establishment, and therefore which CSIRT is your coordinator (with counsel, especially if you are a non-EU manufacturer); and register for the ENISA Single Reporting Platform ahead of time so you are not creating an account while the clock runs.

Hour zero to 24: the early warning

The early warning is short. Its job is to alert the authorities fast, not to explain everything. You are not expected to have the full picture in 24 hours. Start a written timeline noting the exact time someone first became aware. Get counsel and your assessor on the phone. Assign the roles below. Draft the early warning and file it through the SRP.

Report type: [Actively exploited vulnerability / Severe incident]
Manufacturer: [COMPANY NAME], [main establishment Member State]
Product: [PRODUCT NAME and version(s)], a product with digital elements.
Time manufacturer became aware: [DATE and TIME, with timezone].
Summary: [One or two plain sentences. For an incident, state whether it is
  suspected of being caused by unlawful or malicious acts.]
Member States where the product has been made available, as far as known:
  [LIST, or "assessment ongoing"].
Contact for this report: [NAME, email, phone].

Hour 24 to 72: the notification

The 72-hour notification adds what you have learned: general information about the affected product, the general nature of the vulnerability and the exploit (or the incident), any corrective or mitigating measures already taken, the measures users can take, and your assessment of how sensitive or widespread it is.

Report reference: [link back to the early warning].
Product: [name, versions, short description of what it does].
Nature of the vulnerability / incident: [what kind of flaw or event this is].
Nature of the exploit: [how it is being exploited; N/A for a non-vulnerability incident].
Impact and sensitivity assessment: [what an attacker can do, how sensitive the
  affected data or functions are, roughly how many users are exposed].
Corrective or mitigating measures already taken: [what you have done].
Measures users can take now: [workaround, config change, apply the update, etc.].
Member States where the product is available: [updated list].
Current status: [investigating / fix in progress / fix released].

The final report

For an actively exploited vulnerability, file no later than 14 days after a corrective or mitigating measure is available. Include a description of the vulnerability with its severity and impact, information about any malicious actor exploiting it, and details of the security update released. For a severe incident, file within one month of the 72-hour notification. Include a detailed description with severity and impact, the type of threat or root cause, and the mitigations applied and ongoing.

Report reference: [link back to the earlier submissions].
Full description: [what the vulnerability or incident was, now that you understand it].
Severity and impact: [your considered assessment].
For a vulnerability: malicious actors known to have exploited it: [what you know].
  Security update or corrective measure released: [version, date, how users get it].
For an incident: type of threat or root cause: [what caused it].
  Mitigations applied and ongoing: [what you did and what is still in progress].
User information: [when and how you informed affected users].

The user-information duty

Separately from notifying the authorities, Article 14 requires you to inform the affected users of your product about the vulnerability or incident and, where necessary, the mitigations they can apply. Where appropriate this should be in a structured, machine-readable format. In plain terms: your customers need to hear from you, not just the regulator. For many products a human-readable advisory plus a machine-readable feed (such as CSAF) is the way to do it. Decide your channel now, not mid-incident.

Who does what: assign these names today

An incident is the wrong time to discover that nobody owns the filing. Name a person and a backup for each role. On a small team one person may hold several, which is fine, as long as it is written down and the backups are real.

• Reporting owner: files through the SRP and holds the clock, making sure a report goes out even if it is incomplete.
• Technical lead: investigates, reproduces, assesses severity, and builds the fix or mitigation.
• Communications owner: handles the user-information duty and any customer or press questions.
• Legal contact: your counsel, engaged the moment a trigger is suspected. Keep an after-hours number.

Weekends and holidays count. If your only reporting owner is unreachable on a Saturday, the clock does not care. That is what the backup is for.

The tabletop drill (run this before September)

You will not find the gaps in this plan by reading it. You find them by running it once, on a quiet afternoon, against a pretend incident. Block 90 minutes, get the named people together, and walk the clock.

The scenario: at 2pm on a Saturday, a researcher emails your security address to say they found a flaw in your product, and they link to a public forum post where someone is already sharing an exploit. That is an actively exploited vulnerability, and the 24-hour clock has started. Walk these questions out loud, and write down every answer you do not have.

1. Who sees the security email at 2pm on a Saturday, and how does it reach the reporting owner?
2. Who decides this is actively exploited and starts the clock, and how fast can that happen?
3. Can the reporting owner actually log into the ENISA SRP right now, or is the account not set up?
4. Which CSIRT is your coordinator? Does anyone in the room know?
5. Can you draft and file the early warning within 24 hours with the people available on a weekend?
6. Who tells your users, through what channel, and who writes that message?
7. Who is counsel, and will they answer the phone on a Saturday?

Every question you cannot answer cleanly is a gap to close before 11 September. Run the drill again after you fix the gaps. The second run should be boring. Boring is the goal.

The pre-September checklist

• Confirm your main-establishment Member State and your coordinator CSIRT, with counsel.
• Register on the ENISA Single Reporting Platform in advance.
• Assign the four roles by name, with real backups.
• Decide and set up your user-information channel.
• Save the four report templates above somewhere the reporting owner can reach them in minutes.
• Run the tabletop drill once, fix the gaps, and run it again.
• Confirm the article references, deadline wording, and penalty figures against the official text.