CRA Reporting Requirements: 24-Hour Deadlines Now Live

Since 11 September 2026, manufacturers of products with digital elements sold in the EU have had to report actively exploited vulnerabilities and severe incidents under Article 14 of the CRA (the EU’s Cyber Resilience Act, Regulation (EU) 2024/2847). An early warning is due within 24 hours of becoming aware and a fuller notification within 72 hours, with a final report within 14 days of a fix being available or, for incidents, a month after the notification. The duty covers products already on the EU market, and it applies 15 months before most of the regulation does on 11 December 2027.

Article 14 covers two kinds of events. The first is an actively exploited vulnerability, where there is reliable evidence that a malicious actor has exploited it in a system without the owner’s permission. The second is a severe incident: one that affects, or could affect, a product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led, or could lead, to malicious code running in the product or in a user’s network.

Both are notified at the same time to the CSIRT (Computer Security Incident Response Team) designated as coordinator in the Member State of the manufacturer’s main establishment and to ENISA (the EU Agency for Cybersecurity), through ENISA’s Single Reporting Platform (SRP). The coordinating CSIRT then passes the notification to CSIRTs in the other Member States where the manufacturer has indicated the product is available.

The three-stage timeline

The first two deadlines run from the moment the manufacturer becomes aware, and the final report depends on the event type. The European Commission’s reporting obligations page sets out the sequence.

The early warning is short by design. For a vulnerability, it indicates where applicable the Member States in which the manufacturer knows the product has been made available; for an incident, it also states whether the incident is suspected of being caused by unlawful or malicious acts. The 72-hour notification adds general information about the product, the nature of the exploit or incident, and the corrective or mitigating measures available.

When the clock starts

Awareness is the trigger. As Hogan Lovells sets out, a manufacturer becomes aware once it has a reasonable degree of certainty that a vulnerability in its product is being actively exploited, or that a severe incident has compromised the product’s security. That point usually lands while the investigation is still running.

A researcher’s tip-off on its own tends to sit below the threshold, and a confirmed exploit in a customer environment tends to sit above it. Most of the difficult calls happen between those two, so it helps to agree in advance who makes the call and what evidence they need to make it.

Who has to report

Manufacturers carry the duty. Under Article 21, an importer or distributor is treated as the manufacturer, and picks up Articles 13 and 14, when it places a product on the market under its own name or trademark or makes a substantial modification to a product already on the market. Open-source software stewards follow from 11 December 2027.

Older products are included. Article 69(3) applies Article 14 to every in-scope product placed on the market before 11 December 2027, and reporting continues after a product’s support period has ended. There’s one carve-out on timing. ENISA’s FAQ confirms manufacturers don’t have to retrospectively report active exploitation they already knew about before 11 September 2026.

Registering on the Single Reporting Platform

Notifications go in through the SRP portal, which opened on 11 September 2026. Each manufacturer submits through Assigned Representatives (ARs): one Primary AR who manages the account, and up to 20 Secondary ARs who can file notifications. Every AR needs their own EU Login account with multi-factor authentication (MFA) enabled.

The coordinating CSIRT validates each AR’s link to the manufacturer in parallel with reporting, so a pending validation won’t hold up a submission. The EU Login and MFA setup is the part to finish first.

An early warning depends on four steps happening in sequence, and often outside office hours. Your team has to:

1. Recognise that the event meets the CRA’s definition of a reportable vulnerability or incident

2. Escalate it to someone with the authority to notify a regulator

3. Submit through the SRP using a registered Assigned Representative account

4. Keep a record of what was sent, when, and on what evidence

Each step tends to break in a different place. Triage is usually the slowest, because security and product teams can read the same evidence differently. Escalation often stalls when nobody on call has authority to notify. And the platform step fails quietly if the only registered AR is on leave.

The pressure can also stack up. A second reportable event may arrive while the team is still preparing the first one’s 72-hour notification, and each event runs on its own clock.

Users need to hear from you too

Article 14(8) adds a separate duty. The manufacturer informs impacted users of the product, and where appropriate all users, about the vulnerability or incident and any risk mitigation and corrective measures they can deploy.

For a product sold across several Member States, this usually works best as a pre-approved communications plan, with templates and sign-off routes agreed before anything goes wrong.

Teams already reporting under NIS2 (the EU’s revised Network and Information Security Directive) or DORA (the EU’s Digital Operational Resilience Act) will likely recognise the shape of the CRA’s clock. What changes is who reports. NIS2 places the duty on essential and important entities and DORA on financial entities, while the CRA places it on the manufacturers of the products those organisations use.

Sources: NIS2 Directive, Article 23; FMA guidance on DORA major incident reporting.

One event can start more than one of these clocks. A software vendor that is itself an essential entity under NIS2 could find a single exploited vulnerability triggering its CRA duty as manufacturer and its NIS2 duty as an entity, while its financial services customers assess the same event under DORA. Each regime asks for different content in a different format. Teams that log the event once and track every deadline against that single record usually find the second and third notifications quicker to produce.

For UK organisations, the Cyber Security and Resilience Bill would bring in a 24-hour initial notification and a 72-hour full report for operators of essential services and some digital suppliers, such as managed service providers. It was at report stage in the House of Lords in September 2026. Its scope is operators and their suppliers, so a UK manufacturer selling into the EU still reports under the CRA wherever it’s based.

Reporting is the first CRA obligation to apply. From 11 December 2027, products placed on the EU market must also meet the essential cybersecurity requirements in Annex I, complete the relevant conformity assessment and carry CE marking, as the Commission’s summary of the regulation describes.

Much of the reporting work carries straight into that. The triage protocol, escalation path and evidence trail built for Article 14 are the kind of records a market surveillance authority is likely to ask about once the wider obligations apply. Mapping CRA duties against controls you already run for NIS2, DORA or ISO 27001 (the international information security management standard) also tends to show where the product-security gaps sit.

The readiness work can start this quarter:

1. Scope: list which products fall under the CRA and who the manufacturer is for each, including white-label and substantially modified products.
2. Access: register EU Login accounts with MFA, a Primary AR and at least one Secondary AR, so notifications keep moving when one person is away.
3. Threshold: write down what evidence moves an event from “reported to us” to “reasonably certain”, and who decides.
4. Rehearsal: run the 24-hour path end to end, including out of hours, and time it.
5. User notices: prepare notification templates and approval routes for impacted users.

In SureCloud’s governance, risk and compliance (GRC) platform, that sequence runs as a workflow. Gracie AI Agents with Personas and Skills builds a process from a description of it, including its trigger, stages, skills and notifications, so the escalation path above can be set up directly. CRA obligations can be mapped as a custom framework with Gracie, and in Compliance Management a control mapped once counts towards every standard it supports, including NIS2 and DORA.

Incidents are logged, linked to risks and tracked to remediation in Risk Management. Business Continuity and Resilience tracks incidents and contacts for communication planning, and those contact lists can feed the user notifications Article 14(8) requires. For the December 2027 obligations, Continuous Controls Monitoring replaces point-in-time control tests with continuous, automated monitoring and a 75% reduction in audit prep time.

A timed drill is usually the quickest way to find out which of those steps would slow a live notification down.