---
key: "cra-reporting-runbook"
title: "Build a runbook for CRA vulnerability and incident reporting"
url: "https://softwaresecurity.com/frameworks/cra-reporting-runbook/"
api: "https://softwaresecurity.com/api/v1/articles/cra-reporting-runbook.json"
domain: "governance"
topic: "Governance \u0026 frameworks"
type: "Guide"
identifiers: ["A03:2025","A08:2025"]
tags: ["Incident response","Vulnerability disclosure","AppSec programs","Regulation"]
stages: ["respond","govern"]
roles: ["appsec-engineer","security-leader"]
license: "CC-BY-4.0"
license_url: "https://creativecommons.org/licenses/by/4.0/"
code_license: "MIT"
---

# Build a runbook for CRA vulnerability and incident reporting

Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform within 24 and 72 hours. Decide what is reportable, start the clock at the right moment, file through the platform and keep an evidence trail.

Canonical URL: https://softwaresecurity.com/frameworks/cra-reporting-runbook/

## In short

Since 11 September 2026, a manufacturer of a product with digital elements on the EU market must notify every actively exploited vulnerability and severe incident affecting product security through ENISA's Single Reporting Platform, addressed to its coordinating CSIRT. Send an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report within 14 days of a fix or mitigation (vulnerabilities) or one month after the notification (incidents). Inform affected users too.

- The clock starts at awareness: when a prompt initial assessment gives you reasonable certainty of exploitation or of a severe incident. Record that time in UTC with the evidence.
- Bug-bounty and lab findings without evidence of malicious use aren't mandatory reports; a third-party component flaw exploited in your product is.
- Reporting covers products already on the market, including those placed before 11 December 2027 and those past their support period.
- File at `portal.cra-srp.enisa.europa.eu` with personal EU Login accounts and MFA. There is no API yet, and the platform's 72-hour counter shows a time 48 hours after the early warning.
- Choose the coordinating CSIRT with the Article 14(7) order and record why; a notification sent to the wrong one may be invalidated.
- Micro and small enterprises can't be fined for a late early warning, but the other deadlines carry fines of up to EUR 15 million or 2.5% of worldwide annual turnover.

## Recommended defaults

| Setting | Value | Note | Source |
| --- | --- | --- | --- |
| Early warning | Within 24 hours of becoming aware | Member States where you know the product is available; for incidents, also whether unlawful or malicious acts are suspected. | CRA Art. 14(2)(a), 14(4)(a) |
| Vulnerability or incident notification | Within 72 hours of becoming aware | General information, measures taken, measures users can take and how sensitive the information is. | CRA Art. 14(2)(b), 14(4)(b) |
| Final report, actively exploited vulnerability | No later than 14 days after a corrective or mitigating measure is available | — | CRA Art. 14(2)(c) |
| Final report, severe incident | Within one month after submitting the incident notification | — | CRA Art. 14(4)(c) |
| Intermediate report | When the coordinating CSIRT asks for one | — | CRA Art. 14(6) |
| User information | Inform impacted users after becoming aware, in a timely manner | Machine-readable where appropriate. | CRA Art. 14(8) |
| Where to file | `https://portal.cra-srp.enisa.europa.eu`, addressed to the CSIRT designated as coordinator | Live since 11 September 2026; English only; no API in the first release. | CRA Art. 14(7), 16; ENISA SRP FAQ (3 October 2026) |
| Timestamps | UTC | — | ENISA SRP Glossary v1.4 |
| Applies from | Manufacturers: 11 September 2026. Open-source software stewards: 11 December 2027 | — | CRA Art. 71(2), 24(3) |

## Verify it

1. Run a tabletop with a synthetic exploited vulnerability reported at 18:00 on a Friday and confirm the early warning could be filed before the 24-hour mark.
2. Confirm at least two named people hold EU Login accounts with MFA, know the SRP registration steps and can reach the product security lead out of hours.
3. Check the product register: every product lists affected version ranges, CRA category, support end date and the EU Member States where it is sold.
4. Re-run the deadline script on a closed case and compare its output with the submission times recorded in the case.
5. Sample a closed case and confirm it holds the awareness decision and evidence, all three submissions, the user notice and the fix release.
6. Feed a researcher report with no exploitation evidence into triage and check it is routed to coordinated disclosure, not to the SRP.

## What you will learn

- Classify events as actively exploited vulnerabilities, severe incidents or neither.
- Fix the awareness time and compute the Article 14 deadlines.
- Choose the coordinating CSIRT and file through ENISA's Single Reporting Platform.
- Keep a case record that shows what was known, decided and submitted, and when.

Audience: Product security leads, PSIRT members, engineering managers and the people who will submit CRA reports for a manufacturer

Before you start:

- Know which of your products are sold in the EU and under whose name.
- Know how vulnerability reports and security incidents reach your team today.
- Read ISO 8601 timestamps with UTC offsets.

Time: About 36 minutes: 12 to read and 24 for the exercise

## Who reports what under the CRA, and from when?

Article 14 of the Cyber Resilience Act (Regulation (EU) 2024/2847) has applied since 11 September 2026, more than a year before most of the regulation applies on 11 December 2027. It binds manufacturers: anyone who develops a product with digital elements, or has one developed, and markets it under its own name or trademark, whether paid or free. It covers every in-scope product on the EU market, including products placed there before 11 December 2027, and the Commission's guidance says it continues after a product's support period ends.

There are three limits. Exploitation you were aware of before 11 September 2026 doesn't have to be reported retrospectively, but if you first learn of exploitation after that date, you report even if the flaw itself was known earlier. Open-source software stewards report only from 11 December 2027, and only to the extent they take part in development. Importers and distributors have different duties: tell the manufacturer about a vulnerability without undue delay and, for a significant cybersecurity risk, the market surveillance authorities. Selling the product under their own name or substantially modifying it makes them the manufacturer.

## Is the event reportable?

Two kinds of event trigger a report. An actively exploited vulnerability is one for which there is reliable evidence that a malicious actor exploited it in a system without the owner's permission. A severe incident is one that harms, or can harm, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led or can lead to malicious code being introduced or run in the product or in a user's network and information systems. The regulation's recitals give the example of an attacker planting malicious code in the channel that ships security updates.

The Commission's FAQ and guidance settle the common edge cases:

| Event | Mandatory report? | Why |
| --- | --- | --- |
| Bug-bounty or contracted lab finding, no sign of malicious use | No | Good-faith discovery isn't exploitation; handle it through /domains/appsec/vulnerability-response/coordinated-disclosure/ and, if you wish, notify it voluntarily under Article 15 |
| Zero-day with reliable evidence of attacks | Yes | The duty doesn't wait for a patch |
| Flaw in a third-party component, exploited in your product | Yes | You report it, and so does the component's manufacturer if it placed the component on the market |
| Component flaw that is unreachable or not exploited in your product | No | Fix it as a normal vulnerability and tell the maintainer unless they already know; Article 13(6) requires that from December 2027 |
| Malicious code pushed through your update channel | Yes, as a severe incident | Malicious code reached users' devices |
| Exploitation you knew of before 11 September 2026 | No | The duty starts with awareness on or after that date |

## When does the clock start?

The 24- and 72-hour clocks run from the moment the manufacturer becomes aware. The Commission's guidance, which follows the way NIS2 and GDPR guidance treat awareness, puts that moment after a prompt initial assessment, once you have a reasonable degree of certainty that a vulnerability in your product is being exploited or that a severe incident has compromised its security. A customer email or a threat-intelligence report starts the assessment, not the clock, but the guidance stresses prompt action, so a slow assessment is hard to defend.

Record the detection time, the awareness time and the evidence that produced certainty, and name who decided. Keep times in UTC, which the platform uses, and mark estimates as estimates. Your disclosure inbox, customer support, telemetry and threat intelligence all feed this decision, so each needs a route to an on-call product security lead within minutes, at weekends too. Weekends and public holidays don't pause the hour-based clocks.

## What are the three deadlines?

Each submission builds on the previous one, and each deadline is an outer limit: the regulation says without undue delay and in any event within the stated time. Three details trip teams up. The vulnerability final report counts from when a corrective or mitigating measure is available, and a published workaround may qualify, so plan for the earlier date. The incident final report counts from when you submitted the notification, not from the 72-hour limit. And the platform's 72-hour counter currently shows a due time 48 hours after the early warning was submitted, so calculate the legal deadlines yourself. The coordinating CSIRT can also ask for an intermediate report on progress.

The early warning needs few facts. Apart from the manufacturer name the platform fills in, ENISA's glossary marks only these as required at that stage: the event type, a title and summary, the product name and versions, the Member States where it is sold, the awareness time and, for incidents, whether malicious acts are suspected. Most other fields become required at 72 hours or in the final report. In the sensitivity field, name the sensitive detail and the harm early disclosure would cause rather than writing a generic confidentiality line.

Breaching Article 14 can bring fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. As corrected in July 2025, the regulation exempts micro and small enterprises from fines for missing only the 24-hour early warning, and exempts open-source software stewards entirely. The table sets out each stage. The script after it calculates the latest times from a case record in UTC, so a daylight-saving change can't shift a deadline, and it rejects timestamps without an offset.

```python
"""Latest submission times for one CRA Article 14 case. File earlier when you can."""
import calendar
import json
import sys
from datetime import datetime, timedelta, timezone


def utc(ts):
    t = datetime.fromisoformat(ts)
    if t.tzinfo is None:
        raise ValueError(f"{ts}: include a UTC offset, for example 2026-10-09T22:40:00+02:00")
    return t.astimezone(timezone.utc)


def one_month_after(t):
    """Same date next month, or that month's last day if the date doesn't exist."""
    y, m = (t.year + 1, 1) if t.month == 12 else (t.year, t.month + 1)
    return t.replace(year=y, month=m, day=min(t.day, calendar.monthrange(y, m)[1]))


def deadlines(case):
    aware = utc(case["aware_at"])
    due = {"early_warning": aware + timedelta(hours=24),   # Art. 14(2)(a), 14(4)(a)
           "notification": aware + timedelta(hours=72)}    # Art. 14(2)(b), 14(4)(b)
    if case["type"] == "vulnerability":   # Art. 14(2)(c): first corrective or mitigating measure + 14 days
        measure = case.get("measure_available_at")
        due["final_report"] = utc(measure) + timedelta(days=14) if measure else None
    elif case["type"] == "incident":      # Art. 14(4)(c): one month after the 72-hour notification
        sent = next((s["sent_at"] for s in case.get("submissions", []) if s["stage"] == "notification"), None)
        due["final_report"] = one_month_after(utc(sent)) if sent else None
    else:
        raise ValueError("type must be 'vulnerability' or 'incident'")
    return due


if __name__ == "__main__":
    with open(sys.argv[1], encoding="utf-8") as f:
        case = json.load(f)
    for stage, at in deadlines(case).items():
        print(f"{stage:13} " + (f"{at:%Y-%m-%d %H:%M} UTC" if at else "clock not started"))
```

| Stage | Deadline | Content |
| --- | --- | --- |
| Early warning | Within 24 hours of awareness | The Member States where you know the product is available; for incidents, whether unlawful or malicious acts are suspected |
| Notification | Within 72 hours of awareness | General information on the product and the exploit or incident, an initial assessment for incidents, measures taken, measures users can take, and how sensitive the information is |
| Final report, vulnerability | Within 14 days after a corrective or mitigating measure is available | Description with severity and impact, what is known about the malicious actor, and details of the update or other fix |
| Final report, incident | Within one month after submitting the notification | Detailed description with severity and impact, the likely threat or root cause, and mitigations applied and ongoing |

## How do you file through ENISA's Single Reporting Platform?

ENISA's Single Reporting Platform (SRP) went live on 11 September 2026 at `portal.cra-srp.enisa.europa.eu`. You submit once: the platform makes the notification available to your CSIRT designated as coordinator and, at the same time, to ENISA, and that CSIRT passes it to the CSIRTs of the other Member States you listed. One notification per event is enough even for a group with several EU subsidiaries, so decide internally who files.

Choose the coordinating CSIRT with the Article 14(7) order and keep the reasoning on file. It is the Member State where decisions on your products' cybersecurity are mainly taken or, if that is unclear, the one with most of your EU staff. Without an EU main establishment, take the Member State of the authorised representative acting for most of your products, then the importer placing most of them on the market, then the distributor, then the Member State with most users. ENISA publishes the list of coordinating CSIRTs; a notification sent to the wrong one may be invalidated and need resubmitting. Know the platform's first-release limits before you need it:

- Assigned representatives file using personal EU Login accounts with multi-factor authentication: one primary and up to 20 secondary per manufacturer. Create the EU Login accounts now.
- ENISA asks manufacturers to register on the SRP only when they first need to file. Registration takes minutes, the CSIRT validates it in parallel, and up to 20 notifications can be filed while validation is pending.
- There is no API and the interface is English only, so draft text outside the platform. Saved drafts are visible only to the person who saved them.
- A notification can't be edited after the final report. If the platform is down, file as soon as it returns; you may contact your CSIRT directly meanwhile.
- In the 72-hour notification of an exploited vulnerability you can flag particularly exceptional circumstances under Article 16(2), such as exploitation seen in only one Member State; ENISA then gets limited information until the CSIRT shares the full notification.
- Delegated Regulation (EU) 2026/881 sets when a CSIRT may delay passing a notification on, for example when you say an effective fix or user guidance will be available within 72 hours.

## Who else must you tell?

Article 14(8) requires you to inform impacted users, and where appropriate all users, of the vulnerability or incident and the measures they can take, in a structured machine-readable format where appropriate, such as a CSAF 2.0 advisory; CSAF 2.1 was still a committee draft in October 2026 (see /domains/appsec/vulnerability-response/security-advisories-csaf-vex/). The Commission reads this as risk-based: you can limit technical detail to the customers concerned when public detail would help attackers, then publish more once a fix is out. If you don't inform users in time, the CSIRT may do it. Once a fix is out, expect ENISA to seek your agreement to add the vulnerability to the European Vulnerability Database.

When the exploited flaw sits in someone else's component, also tell the component's maintainer through their security policy, unless you can confirm they already know, and share your fix if you wrote one. Article 13(6) makes this mandatory from 11 December 2027; do it now anyway.

## What should you prepare before the first case?

Most of the 24-hour window goes on finding facts you could have recorded in advance. Prepare these now, and review them whenever your products or EU footprint change:

- A product register with affected version ranges, CRA category, support end date and the EU Member States where each product is sold.
- A signed note naming your coordinating CSIRT under Article 14(7), with the facts behind it.
- At least two assigned representatives with EU Login and MFA who can be reached out of hours.
- Templates for each stage and for the user notice, written to the fields in ENISA's SRP glossary.
- Intake routes from the disclosure inbox, support, telemetry and threat intelligence to the on-call product security lead.

## What steps does every case follow?

Give each step an owner and a target well inside the legal limit:

| Step | Owner | Output |
| --- | --- | --- |
| Triage the event against the reportability table | Product security lead | Classification with evidence, or the open questions |
| Decide awareness | Product security lead and legal | Awareness time in UTC, evidence, decision makers |
| File the early warning with what you know | Assigned representative | SRP submission, confirmation email |
| Contain and fix | Engineering | Mitigation and fix with their availability times |
| File the notification; inform users | Assigned representative, communications | SRP submission, sensitivity choice, user notice |
| File the final report; review the case | Assigned representative, product security lead | SRP submission, lessons learned |

## What evidence trail should you keep outside the platform?

The SRP emails confirmations and lists your notifications on its dashboard, but its first release has no API. Keep your own case record as the source of truth: the awareness decision and evidence, what you submitted at each stage and when, the measures and when each became available, the user notices and any upstream report. CSIRTs pass notified information to market surveillance authorities, so expect your records to be compared with your submissions. This record is the input to the deadline script.

```json
{
  "case": "CRA-2026-0412",
  "type": "vulnerability",
  "product": {
    "name": "Gateway X",
    "affected_versions": "4.0 to 4.2.1",
    "cra_category": "default",
    "support_ends": "2031-06-30",
    "member_states": ["DE", "FR", "IE", "NL"]
  },
  "coordinator_csirt": "IE",
  "coordinator_basis": "Art. 14(7) memo LEG-118: no EU main establishment; authorised representative in Ireland",
  "detected_at": "2026-10-09T18:05:00+02:00",
  "aware_at": "2026-10-09T22:40:00+02:00",
  "awareness_basis": "Customer SOC logs show the login-bypass request against their 4.2.1 device; lab reproduced it at 22:31",
  "awareness_decided_by": ["psirt-lead", "legal-on-call"],
  "measure_available_at": "2026-10-11T09:00:00Z",
  "measures": [
    {"at": "2026-10-11T09:00:00Z", "kind": "mitigation", "ref": "Advisory GX-2026-07 v1: disable remote admin"},
    {"at": "2026-10-14T16:00:00Z", "kind": "fix", "ref": "Gateway X 4.2.2"}
  ],
  "submissions": [
    {"stage": "early_warning", "sent_at": "2026-10-10T08:15:00Z", "by": "ar-secondary-2", "srp_ref": "<from the SRP dashboard>"},
    {"stage": "notification", "sent_at": "2026-10-11T10:30:00Z", "by": "ar-primary", "srp_ref": "<same notification>", "pec_requested": false}
  ],
  "user_notices": [
    {"at": "2026-10-11T09:00:00Z", "channel": "CSAF advisory and customer portal", "ref": "GX-2026-07"}
  ],
  "upstream_report": "not applicable: flaw is in our own login code"
}
```

## Which other reports might the same event need?

An SRP notification satisfies only the CRA. The same event can also be a significant incident under NIS2, if you are an essential or important entity, with its own 24-hour, 72-hour and one-month reports, or a personal data breach that a controller must report to its data protection authority within 72 hours where feasible, under GDPR Article 33. The Commission's Digital Omnibus proposal would add a single entry point for those regimes, building on ENISA's SRP experience without changing the underlying duties. Until one exists, file each report through its own channel and keep one timeline for all of them. Whether NIS2 applies to a software company, directly or through customers, is covered in /frameworks/nis2-dora-for-software-suppliers/.

## Guided practice

You lead product security at Northwind Devices (fictional), a US manufacturer selling Gateway X in the EU. Classify four events, choose the coordinating CSIRT, set the awareness time and work out every deadline. Nothing is filed.

### Supplied material

```text
Northwind Devices: no EU main establishment. Authorised representative in Ireland acts for all products; importer in Germany.
Gateway X 4.0 to 4.2.1, sold in DE, FR, IE and NL; support ends 2031-06-30.
E1 2026-10-02: bug-bounty report of a login bypass in 4.2.1 with a proof of concept; no sign of use against anyone.
E2 2026-10-09 18:05 CEST: a customer's SOC emails logs showing the same bypass request against its 4.2.1 gateway
   from an unknown address, followed by a configuration export.
   18:10 CEST triage starts. 22:31 CEST the lab reproduces the logged request.
   22:40 CEST the product security lead and legal on-call record the vulnerability as actively exploited.
   2026-10-11 09:00 UTC: advisory GX-2026-07 tells customers to disable remote admin (workaround).
   2026-10-14 16:00 UTC: Gateway X 4.2.2 fixes the flaw.
   Early warning submitted 2026-10-10 08:15 UTC; the SRP dashboard shows the 72-hour notification as due 2026-10-12 08:15.
E3 A scanner flags a public advisory for the bundled XML library; the vulnerable parser function isn't compiled into Gateway X.
E4 2026-10-20 07:30 UTC: the build team confirms the signed 4.2.3 update served for six hours contained an injected binary;
   3% of devices installed it. Early warning submitted 2026-10-20 16:00 UTC; incident notification 2026-10-21 15:00 UTC.
```

### 1. Classify the events

Decide which of E1 to E4 must be reported and as what.

Worked answer: E1: not mandatory; good-faith discovery with no exploitation, handled through coordinated disclosure, with a voluntary notification possible. E2: actively exploited vulnerability; report. E3: not reportable; the flaw can't be exploited in Gateway X, and the maintainer already knows from the public advisory. E4: severe incident, since malicious code reached users' devices through the update channel; the early warning must say malicious acts are suspected.

### 2. Choose the coordinating CSIRT

Apply the Article 14(7) order.

Worked answer: No EU main establishment, so the first test is the authorised representative acting for the most products: Ireland. File to Ireland's CSIRT designated as coordinator, as listed by ENISA. The German importer only matters if there is no authorised representative.

### 3. Set the awareness time for E2

Pick the moment the clocks start and justify it.

Worked answer: 22:40 CEST on 2026-10-09, which is 20:40 UTC: the moment the lead recorded reasonable certainty after a prompt assessment that began at 18:10. The 18:05 email started the assessment, not the clocks.

### 4. Compute the E2 deadlines

Work out the early warning, notification and final report limits, and explain the SRP's due time.

Worked answer: Early warning by 2026-10-10 20:40 UTC (met at 08:15); notification by 2026-10-12 20:40 UTC. The workaround on 2026-10-11 09:00 UTC is the first mitigating measure, so plan the final report for 2026-10-25 09:00 UTC rather than 2026-10-28 16:00 UTC. The dashboard's 08:15 is 48 hours after the early warning, earlier than the legal limit; filing by then does no harm.

### 5. Compute the E4 deadlines

Work out all three limits and check the submissions made so far.

Worked answer: Awareness 2026-10-20 07:30 UTC: early warning by 2026-10-21 07:30 (met), notification by 2026-10-23 07:30 (met on 2026-10-21 15:00), final report by 2026-11-21 15:00 UTC, one month after the notification was submitted.

Deliverable: Case records for E2 and E4 with classification, CSIRT choice, awareness rationale, deadlines and the planned user notices.

Scope: Fictional facts. The answers follow the regulation, the Commission's July 2026 guidance and FAQ, and ENISA's platform documentation as of 10 October 2026; a real classification also needs your legal reviewer's sign-off.

Articles and teaching material: CC BY 4.0. Original executable code: MIT. Attribution: Software Security.

## Sources

- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng#art_14). OJ L 2024/2847, 20 November 2024.
- [Corrigendum to Regulation (EU) 2024/2847, Article 64(10)](https://eur-lex.europa.eu/eli/reg/2024/2847/corrigendum/2025-07-02/oj/eng). OJ L 2025/90555, 2 July 2025.
- [European Commission: Cyber Resilience Act reporting obligations](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting)
- [European Commission: guidance on the application of the CRA, C(2026) 5252 annex, section 9.1](https://ec.europa.eu/newsroom/dae/redirection/document/131456). 27 July 2026.
- [European Commission: FAQs on the CRA implementation (section 5)](https://ec.europa.eu/newsroom/dae/redirection/document/122331). Version 1.4 (4 September 2026).
- [Commission Delegated Regulation (EU) 2026/881 on delaying the dissemination of notifications](https://eur-lex.europa.eu/eli/reg_del/2026/881/oj/eng). OJ L 2026/881, 20 April 2026.
- [ENISA: CRA Single Reporting Platform FAQ](https://www.enisa.europa.eu/topics/product-security/vulnerability-services/eu-incident-response-and-cyber-crisis-management/single-reporting-platform-srp/frequently-asked-questions). Updated 3 October 2026.
- [ENISA: CRA SRP Glossary, notification fields by stage](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-glossary2). Version 1.4 (1 October 2026).
- [ENISA: CRA SRP guidance on assigned representative registration](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-user-registration)
- [ENISA: list of CSIRTs designated as coordinators](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/list-of-csirts-designated-as-coordinators)