Purpose
Art. 14 CRA (Regulation (EU) 2024/2847) obliges manufacturers of products with digital elements, actively exploited vulnerabilities and serious security incidents in a three-stage cascade. The obligation applies from 11.09.2026 and is therefore the first operational CRA obligation of all — more than a year before full application. This skill determines whether a reportable event exists, calculates the deadlines, provides the reporting content and builds the internal escalation process, without which the 24-hour deadline is practically impossible to meet.
⚠️ Currency (as of 2026-07): The regulation entered into force on 10.12.2024 . The reporting obligations apply from 11.09.2026 — the deadline runs in seven weeks. Since 11.06.2026 the provisions on conformity assessment bodies apply; full application with essential requirements, CE marking and conformity assessment follows only on 11.12.2027.
The reporting obligation is brought forward. It applies before the substantive product requirements of Annex I apply. A manufacturer can therefore be subject to reporting obligations even though its products do not yet have to meet the essential requirements. Anyone planning for 2027 misses the relevant cut-off date by 15 months.
Sanctions framework: Infringements of the central manufacturer and reporting obligations are punishable by up to EUR 15 million or 2.5% of worldwide annual turnover , whichever amount is higher (Art. 64 CRA).
Inputs
- Affected product with version, role of the client (manufacturer / open-source software steward) and CRA classification
- Time of becoming aware, to the minute, with evidence (ticket, log, email)
- Type of event: vulnerability with proof of exploitation or security incident
- Evidence of active exploitation (exploit in the wild, attack indicators, report by a researcher, CERT notice)
- Impact: number of users affected, availability, confidentiality, integrity, cross-border effect
- Availability of a security update or a workaround and its timing
- Member State of the main establishment in the Union
- Parallel obligation circles: NIS2 entity? Personal data affected? DORA financial entity?
Sub-agent architecture
Three conceptual roles structure the processing, which in an emergency runs in parallel and under time pressure. A trigger checker decides first and within minutes whether a reportable event within the meaning of Art. 14 CRA exists — an actively exploited vulnerability or a serious security incident — and records the time of becoming aware as the event that triggers the deadline. A deadline calculator derives the three due dates from this, each with date and time, and monitors them until the final report. A report editor formulates the content of the respective stage in a manner appropriate to the addressee, without disclosing unnecessary details and without prejudging the investigation. In case of doubt, the trigger checker decides in favor of reporting: The early warning is deliberately designed to be low-threshold and can be corrected in the full report.
Process
1. Determine the reporting trigger (Art. 14 CRA)
The CRA recognizes two separate triggers. They must be clearly distinguished because the deadline for the final report runs differently.
a) Actively exploited vulnerability. A vulnerability in a product with digital elements for which there are reliable indications that an attacker is actually exploiting it — without the manufacturer having fixed or publicly disclosed it. What is decisive is exploitation, not severity: A highly rated but unexploited vulnerability does not trigger the reporting obligation under Art. 14 CRA; it falls under vulnerability management pursuant to Annex I Part II.
Typical indications: exploit code in the wild, attack indicators from customer installations, a tip from a security researcher with a proof of concept in conjunction with observed attack traffic, inclusion in a catalog of known exploited vulnerabilities.
b) Serious security incident. A security incident that adversely affectsthe cybersecurity of the product or the product's ability to protect the confidentiality, integrity or availability of critical or essential functions. This also covers incidents in the manufacturer's development or delivery infrastructure insofar as they have an impact on the product — such as a compromised build server or signing key.
In case of doubt, report. The early warning does not require a completed analysis. An early warning later found not to be reportable can be corrected without consequence; a missed 24-hour deadline cannot.
2. 24-hour early warning (Art. 14 CRA)
Due within 24 hours of becoming aware. The deadline begins at the time at which the manufacturer becomes aware — not the time of an internal confirmation, a management decision or a completed forensic report.
Content of the early warning, deliberately kept brief:
- Name of the affected product and the affected versions
- Type of event: actively exploited vulnerability or serious security incident
- Initial, preliminary assessment of the impact
- Statement of whether exploitation has been observed and to what extent
- Affected Member States, insofar as already foreseeable
- Contact details of the responsible office at the manufacturer
The early warning is not an incident report. Completeness is not required; delay in favor of completeness is the classic mistake.
3. 72-hour full notification (Art. 14 CRA)
Due within 72 hours of becoming aware — the deadline runs from the same point in time as the early warning, not from its dispatch. In effect, 48 hours remain after the early warning.
Content:
- General information about the nature and severity of the event
- Affected products, versions and estimated number of affected users
- Available information about the vulnerability, including identifier (CVE), insofar as assigned
- Measures taken and planned corrective and remedial measures
- Recommendations for action for users and operators
- Update and, if applicable, correction of the information from the early warning
Where the investigation is still ongoing, this must be expressly noted. Uncertain information must be marked as provisional, not omitted.
4. Final report — 14 days or 1 month (Art. 14 CRA)
Here the two triggers diverge:
| Trigger | Deadline for the final report | Start of the deadline |
|---|---|---|
| Actively exploited vulnerability | at the latest 14 days | from availability of a security update or a workaround |
| Serious security incident | 1 month | from the initial notification (72-hour notification) |
Content of the final report:
- Description of the vulnerability including severity and impacts
- Information about exploiting actors, insofar as available
- Details of the provided security update or the remedial measure
- In the event of an incident: cause, course, severity, impacts and remedial measures applied
- If applicable, cross-border impacts
The 14-day deadline is the practically most delicate: it is tied not to the notification but to the availability of the update . Anyone who does not document the time the update is made available cannot later prove compliance with the deadline.
5. Reporting channel — single reporting platform, CSIRT and ENISA (Art. 14, 16 CRA)
Reporting is done via the CRA single reporting platform (Single Reporting Platform). The addressee is the CSIRT of the Member State in which the manufacturer has its main establishment. The ENISA receives the information in parallel via the platform — a separate notification to ENISA is not required and not envisaged.
Practical consequences:
- The Member State of the main establishment must be determined and documented in advance; it controls the competent CSIRT. For manufacturers without an establishment in the Union, this must be determined via the authorised representative.
- For Germany, the BSI (bsi.bund.de) is the relevant interface.
[unverifiziert - prüfen]The specific design of the German connection to the platform and the allocation of responsibilities under Art. 52 CRA are to be verified. - Accesses, certificates and authorisations for the platform are to be set up before 11 September 2026 and tested at least once. Access that is only applied for in an emergency costs the 24-hour deadline.
- The reporting channel must also be ensured outside business hours; incidents typically begin at night or at the weekend.
6. Internal escalation process for the 24-hour deadline (Art. 13, 14 CRA)
The 24-hour deadline is an organisational obligation, not a mere formality. What is required is a documented process with at least the following elements:
- Bundle incoming channels : support, security researchers via the CVD policy, CERT advisories, monitoring, supplier reports — all feed into a ticket with a timestamp.
- Define and log awareness of the incident: whoever in the company becomes aware is deemed to constitute the manufacturer's awareness. The timestamp must be recorded immutably.
- Triage within a few hours by a designated role with a deputisation arrangement and 24/7 availability.
- Move decision-making authority upstream: approval of the early warning must not depend on management. Pre-approved text modules and a clear approval matrix.
- On-call duty and escalation list with contact details, reviewed annually.
- Exercise: at least one dry run per year against the platform, with minutes.
- Interlinking with vulnerability management under Annex I Part II and with communication to users.
The process documentation is at the same time the exculpatory evidence vis-à-vis the market surveillance authority.
7. User information, documentation and demarcation from NIS2 and the GDPR (Art. 14 CRA)
User information. In addition to the notification to the authorities, the affected users must be informed about the event and, if necessary, about remedial measures. Notification to the authorities and user information are separate obligations; one does not replace the other.
Documentation. For each incident, the following must be retained: time and evidence of becoming aware, triage decision with reasoning, deadline calculation, wording of all three reporting stages with proof of transmission, time the update was made available, user information, follow-up.
Delimitation — one incident, multiple reporting obligations:
| Regime | Trigger | Addressee | Deadlines |
|---|---|---|---|
| CRA Art. 14 | Product with digital elements | CSIRT via the single reporting platform, ENISA in parallel | 24h / 72h / 14 days or 1 month |
| NIS2 Art. 23 | Entity in a covered sector | competent authority, in Germany the BSI | 24h / 72h / 1 month |
| GDPR Art. 33 | personal data | supervisory authority (LfDI/BfDI), if applicable data subjects under Art. 34 | 72h |
| DORA Art. 19 | financial entities, ICT incident | competent financial supervisory authority | separate deadline calculation |
A single incident can trigger all four obligations at the same time. The reports are to be coordinated in content, but submitted separately; no obligation consumes another.
Sources
Statute
- Regulation (EU) 2024/2847 (Cyber Resilience Act) — full text with annexes
- Art. 14 CRA (reporting obligations of manufacturers — 24 hours / 72 hours / final report), Art. 13 CRA (obligations of manufacturers), Art. 16 CRA (single reporting platform, ENISA)
[unverifiziert - prüfen], Art. 52 CRA (market surveillance), Art. 64 CRA (sanctions) - Annex I Part II CRA (vulnerability handling) — interface to the reporting obligation
- Art. 23 Directive (EU) 2022/2555 (NIS2) — entity-related reporting obligation
- Art. 33, 34 GDPR — data protection notification
- Regulation (EU) 2022/2554 (DORA) — ICT incident reporting in the financial sector
Guidelines
- European Commission, Cyber Resilience Act — reporting obligations and implementation FAQ
- ENISA, technical specifications for the single reporting platform
- BSI — reporting channels and implementation in Germany
Case law: On the Cyber Resilience Act, no case law is apparent (as of 07/2026); the reporting obligations apply only from 11.09.2026. Experience from GDPR and NIS2 reporting practice may at most be used by analogy and must be expressly identified as an analogy.
Output format
CRA-MELDUNG — <Vorfall-ID> — <Produkt> — <Datum>
I. Rolle und Produkt [Hersteller / OSS-Verwalter; Produkt, Version]
II. Auslöser (Art. 14 CRA) [aktiv ausgenutzte Schwachstelle /
schwerwiegender Sicherheitsvorfall / keiner]
Begründung <…>
III. Kenntniserlangung <TT.MM.JJJJ, HH:MM> — Beleg: <…>
IV. Meldekaskade
24h-Frühwarnung Frist: <TT.MM. HH:MM> Status: <abgesetzt / offen>
72h-Vollmeldung Frist: <TT.MM. HH:MM> Status: <…>
Abschlussbericht Frist: <14 Tage ab Update / 1 Monat ab Erstmeldung>
V. Meldeweg Einheitliche Meldeplattform →
CSIRT <Mitgliedstaat der Hauptniederlassung>
ENISA erhält parallel — keine Zusatzmeldung
VI. Inhalte je Meldestufe <Textbausteine / Verweise>
VII. Nutzerinformation [erforderlich? Kanal, Zeitpunkt]
VIII. Parallele Meldepflichten NIS2 [ja/nein] · DSGVO Art. 33 [ja/nein]
DORA [ja/nein]
IX. Sanktionsrisiko (Art. 64 CRA) [bis 15 Mio. EUR / 2,5 %]
Eskalationspfad: <Rolle, Erreichbarkeit, Freigabematrix>
Risikoeinstufung: 🟢 / 🟡 / 🔴
Nächster Schritt: <…>
Risks / typical errors
- Deadline start set incorrectly — the 24 hours run from becoming aware, not from internal confirmation, management approval or completion of the forensics. Shifting the start of the deadline is the most common and most costly error in practice.
- 72-hour deadline calculated from the early warning — it expires at the same point in time as the 24-hour deadline. After the early warning, 48 hours effectively remain, not 72.
- Final report deadlines swapped — vulnerability: 14 days from availability of the security update or the workaround; incident: 1 month from the initial report. The reference points are different.
- Time of update provision not documented — without it, compliance with the 14-day deadline cannot be evidenced.
- Severity confused with exploitation — Art. 14 CRA is tied to active exploitation , not to a CVSS score. A critical but unexploited vulnerability is not reportable under Art. 14 CRA, but remains subject to vulnerability management under Annex I Part II.
- Separate ENISA report submitted — ENISA receives the information in parallel via the single reporting platform. An additional report is neither required nor provided for.
- Wrong CSIRT addressed — the addressee is the CSIRT of the Member State of the main establishment, not of the country in which the incident occurred.
- Platform access applied for only in an emergency — access and authorizations must be set up and tested before the 11.09.2026 .
- Approval tied to management — an early warning that waits for a board decision is regularly late. Approval authority must be delegated downward.
- User notification forgotten — reporting to authorities and informing affected users are separate obligations.
- Parallel obligations overlooked — a single event can trigger CRA, NIS2, GDPR and DORA simultaneously; no report replaces another.
- Scheduled for 11.12.2027 — the reporting obligation already applies from 11.09.2026, irrespective of the fact that the essential requirements apply later.
- ⚠️ Article numbers adopted without verification — in particular, the reference to the single reporting platform is
[unverifiziert - prüfen]and must be verified against the Official Journal text of Regulation (EU) 2024/2847 before use in a client-facing context.