Build a runbook for CRA vulnerability and incident reporting

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.

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:

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.

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.

"""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"))

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.

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.

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.

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

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.

{
  "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"
}

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/.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14. OJ L 2024/2847, 20 November 2024.
2. Corrigendum to Regulation (EU) 2024/2847, Article 64(10). OJ L 2025/90555, 2 July 2025.
3. European Commission: Cyber Resilience Act reporting obligations
4. European Commission: guidance on the application of the CRA, C(2026) 5252 annex, section 9.1. 27 July 2026.
5. European Commission: FAQs on the CRA implementation (section 5). Version 1.4 (4 September 2026).
6. Commission Delegated Regulation (EU) 2026/881 on delaying the dissemination of notifications. OJ L 2026/881, 20 April 2026.
7. ENISA: CRA Single Reporting Platform FAQ. Updated 3 October 2026.
8. ENISA: CRA SRP Glossary, notification fields by stage. Version 1.4 (1 October 2026).
9. ENISA: CRA SRP guidance on assigned representative registration
10. ENISA: list of CSIRTs designated as coordinators

Reference information

Tags

Incident responseVulnerability disclosureAppSec programsRegulation

SDLC phase

MaintenanceSecurity program

Role

AppSec engineersSecurity leaders

Download this guide as Markdown

Continue exploring