EU Cyber Resilience Act: How Do You Operationalise the 24-Hour Article 14 Vulnerability and Incident Reporting Deadline Before 11 September 2026?

Most CRA obligations do not bite until 11 December 2027. One does not wait.

Article 14 of the Cyber Resilience Act, Regulation (EU) 2024/2847, applies from 11 September 2026. That is roughly seven weeks from today. It is the first hard reporting deadline in the entire regulation, and it lands more than a year before the rest of the framework.

If your product has digital elements and you become aware of an actively exploited vulnerability, you have 24 hours to file an early warning. Not 24 business hours. 24 hours from awareness.

This article walks the mechanism control by control, grounded in the parsed source text, so your compliance, security, and legal functions can stand up a workflow that survives regulator scrutiny before the clock starts.

What exactly does CRA Article 14 require, and why is 11 September 2026 the first hard deadline?

Article 14 sets out the reporting obligations of manufacturers. It runs on two parallel tracks: actively exploited vulnerabilities, and severe incidents having an impact on the security of the product with digital elements.

For each track, the CRA obliges the manufacturer to notify simultaneously to the CSIRT designated as coordinator and to ENISA, via the single reporting platform established under Article 16.

The application date is unusual. The regulation as a whole applies from 11 December 2027. But the text carves out an early start: "Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026."

So the reporting engine is switched on 15 months ahead of the substantive product requirements. The legislator wants the incident and vulnerability signal flowing into ENISA and the CSIRT network before CE marking and conformity assessment obligations mature.

Who does this bind? A manufacturer, defined as a person who develops or manufactures products with digital elements, or has them designed, developed or manufactured, and markets them under its own name or trademark. That definition catches products marketed "whether for payment, monetisation or free of charge." Free distribution is not a carve-out.

If you ship software or connected hardware into the Union market, assume Article 14 reaches you. The manufacturer obligations under the CRA do not turn on revenue from the product.

Which events trigger the 24-hour clock: actively-exploited vulnerabilities versus severe incidents?

Two distinct triggers start two distinct clocks. Confusing them is the first operational failure mode.

The first trigger is an actively exploited vulnerability. The CRA defines this precisely: "a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner." A theoretical or merely exploitable flaw does not qualify. The threshold is reliable evidence of real-world exploitation.

The second trigger is a severe incident having an impact on the security of the product. The CRA sets two alternative severity tests. An incident is severe where it "negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions," or where it "has led or is capable of leading to the introduction or execution of malicious code" in the product or in a user's network and information systems.

Note the phrase "capable of." The severity test is forward-looking. You do not wait for realised damage. Capability of negative impact is enough to meet the bar.

Both triggers fire the same 24-hour early-warning obligation. But the content differs, and so does the downstream cadence. Get the classification right at intake, because it routes everything after it.

The trigger is "becoming aware." The 24-hour countdown does not start at disclosure, patch, or root-cause confirmation. It starts the moment the manufacturer becomes aware. Your detection-to-awareness pipeline is now a compliance control, not just an engineering one.

Who receives the report - how do the ENISA single reporting platform and your national CSIRT split the duty?

The report does not go to one recipient. It goes to two, at the same time.

Article 14 requires the manufacturer to notify "simultaneously to the CSIRT designated as coordinator... and to ENISA," and to submit that notification "via the single reporting platform established pursuant to Article 16."

The ENISA single reporting platform is the delivery mechanism. Article 16 obliges ENISA to establish it and manage its day-to-day operations, with an architecture that lets Member States and ENISA stand up their own electronic notification end-points.

Which CSIRT is yours? The notification is submitted "using the electronic notification end-point of the CSIRT designated as coordinator of the Member State where the manufacturers have their main establishment in the Union," and is made "simultaneously accessible to ENISA." A CSIRT designated as coordinator is the one designated under Article 12(1) of the NIS2 Directive, Regulation (EU) 2022/2555.

Main establishment is defined functionally. It is the Member State "where the decisions related to the cybersecurity of its products with digital elements are predominantly taken." If that cannot be determined, it falls to the Member State with the highest number of employees in the Union. Manufacturers with no Union establishment follow a cascade through authorised representative, importer, distributor, and then user location.

You do not fan the report out to every affected Member State yourself. That is the platform's job. After receiving your notification, the receiving CSIRT "shall, without delay, disseminate the notification via the single reporting platform to the CSIRTs designated as coordinators" in the territories where you indicated the product is available. Your duty is to file once, correctly, into the right end-point.

Answer once. Assess everything.

There is one more downstream party. The CSIRTs designated as coordinators pass the notified information to their national market surveillance authorities so those authorities can discharge their CRA duties. Your report is the seed of a supervisory record. Write it as if the market surveillance authority will read it, because it will.

What does the early-warning, then 72-hour, then final-report cadence actually demand from a manufacturer?

The cadence is a three-stage escalation. Each stage has a deadline and a defined payload. The two triggers share the shape but differ on the final stage.

Stage one is the early warning. For a vulnerability, it is due "without undue delay and in any event within 24 hours" of the manufacturer becoming aware, indicating where applicable the Member States where the product has been made available. For a severe incident, the same 24-hour early warning applies, and it must state "at least whether the incident is suspected of being caused by unlawful or malicious acts."

Stage two is the substantive notification, due "within 72 hours." For a vulnerability, it provides general information about the product, the general nature of the exploit and the vulnerability, and any corrective or mitigating measures taken or available to users. For an incident, it provides the nature of the incident, an initial assessment, and mitigations. In both cases the manufacturer indicates how sensitive it considers the information to be. That sensitivity flag matters: it can justify a delayed dissemination under Article 16.

Stage three is the final report, and here the two tracks diverge.

For a vulnerability, the final report is due "no later than 14 days after a corrective or mitigating measure is available." It must describe the vulnerability including severity and impact, name any malicious actor where known, and detail the security update or corrective measures.

For a severe incident, the final report is due "within one month after the submission of the incident notification." It must give a detailed description including severity and impact, the type of threat or root cause, and applied and ongoing mitigation measures.

Two more obligations sit inside the cadence. The CSIRT designated as coordinator "may request manufacturers to provide an intermediate report" on status updates. And separately from the regulator-facing reports, the manufacturer must inform impacted users, and where appropriate all users, of the vulnerability or incident and the mitigations they can deploy, where appropriate in a structured, machine-readable format.

That user-notification duty is not the same document as the CSIRT report. Plan for both.

How does CRA Article 14 overlap with NIS2 and DORA incident reporting, and where can you reuse evidence?

The CRA did not invent its reporting model in isolation. It is deliberately wired into the NIS2 architecture.

The single reporting platform, the CSIRTs designated as coordinators, and the coordinated vulnerability disclosure hooks all reference Directive (EU) 2022/2555. The CSIRT you report to under the CRA is the same coordinator designated under NIS2 Article 12(1). The 24 / 72 / final structure will feel familiar to anyone who has built a NIS2 significant-incident process or a DORA major-ICT-incident process.

That overlap is an evidence-reuse opportunity, not a reason to merge the pipelines. The triggers are different. NIS2 turns on significant incidents affecting an essential or important entity's services. DORA turns on major ICT-related incidents at a financial entity. The CRA turns on the product: an actively exploited vulnerability in, or a severe incident impacting the security of, a product with digital elements you manufacture.

A financial entity that also ships software can face all three at once for a single event. The event data is shared. The classification logic, deadlines, and recipients are not.

The practical model is a single source-grounded incident record with three classification overlays. Capture the raw facts once - detection time, awareness time, affected product, exploitation evidence, impact assessment - and let each regime draw the fields it needs. This is where a control platform earns its place: regulatory intelligence that keeps each regime's thresholds distinct while letting the underlying evidence serve all of them. The audit pack is a query, not a project.

What operational gaps stop most manufacturers from hitting 24 hours, and how do you close them in seven weeks?

The 24-hour deadline exposes gaps that a slower regime forgives. Here are the ones that fail first.

Awareness is undefined. If "becoming aware" is not an operational event with a timestamp and an owner, your clock start is arguable and your report is late by default. Define, in writing, what constitutes manufacturer awareness and who holds it.

Triage cannot distinguish an actively exploited vulnerability from an exploitable one. Support and security triage must apply the reliable-evidence-of-exploitation test the CRA sets, not a generic severity score. Mis-triage either floods the CSIRT with non-reportable events or misses a real one.

Nobody knows the correct CSIRT end-point. Determining your main establishment and pre-registering the right electronic notification end-point is a one-time task that becomes a crisis if left to hour 20. Do it now.

The user-notification path does not exist. The regulator report and the user notification are separate duties on separate channels. Most manufacturers have the first in some form and not the second, especially not in a machine-readable format.

The coordinated vulnerability disclosure policy is missing. Annex I, Part II requires manufacturers to "put in place and enforce a policy on coordinated vulnerability disclosure." Article 16 lets a CSIRT delay dissemination where a vulnerability is under a coordinated vulnerability disclosure procedure. A functioning CVD process is both a substantive requirement and a lever that shapes how your report is handled.

Seven weeks is enough to close these if you treat the deadline as a control, not a policy. Name the owner. Fix the awareness definition. Register the end-point. Write the two report templates. Dry-run one event end to end.

Aegis GRC's incident reporting workflow is built to make each of those a configured control rather than a scramble.

How do you build a source-grounded, audit-ready reporting workflow that survives regulator scrutiny?

Scrutiny here has teeth. Non-compliance with the obligations in Articles 13 and 14 is subject to administrative fines of up to EUR 15 000 000 or, if the offender is an undertaking, up to 2.5% of its total worldwide annual turnover for the preceding financial year, whichever is higher.

There is narrow relief. The fines do not apply to microenterprises or small enterprises with regard to any failure to meet the 24-hour early-warning deadline in Article 14(2), point (a), or Article 14(4), point (a). That derogation is deadline-specific and size-specific. It is not a general exemption from Article 14.

An audit-ready workflow rests on four things the source text demands you be able to prove.

First, timestamps. You must be able to show when you became aware and when each of the three reports was filed. The deadlines are measured from awareness, so the awareness timestamp is your most contested evidence.

Second, classification traceability. Every report should trace to the specific trigger - the actively exploited vulnerability definition or the severe-incident criteria - with the evidence that met the threshold. No AI hallucinations. A regulator asking "why did you classify this as severe" needs the Article 14(5) test and your facts, not a narrative.

Third, recipient proof. Evidence that the notification reached both the correct CSIRT end-point and ENISA simultaneously via the single reporting platform.

Fourth, the user-notification record and the coordinated vulnerability disclosure policy, retained alongside the regulator reports.

Build the record source-grounded - every field tied to the article that requires it - and the audit pack assembles itself. That is the whole point of a control-level platform: you answer the obligation once and every downstream question is a query against evidence you already hold. See how Aegis GRC operationalises vulnerability management and Article 14 reporting as one connected control set, and read the deeper regulatory tooling at agrc.ai.

Seven weeks. Set the clock now, not on 11 September.

FAQ: CRA Article 14 reporting scope, timelines, and penalties

When does CRA Article 14 start to apply? Article 14 applies from 11 September 2026. The bulk of the CRA applies from 11 December 2027, and Chapter IV applies from 11 June 2026. The regulation enters into force on the twentieth day following its publication in the Official Journal.

What is the 24-hour deadline exactly? The manufacturer must submit an early warning of an actively exploited vulnerability, or of a severe incident, "without undue delay and in any event within 24 hours" of becoming aware. It runs from awareness, not from disclosure or patch availability.

What counts as an actively exploited vulnerability? A vulnerability "for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner." An exploitable-but-unexploited flaw does not meet the bar for the mandatory 24-hour report.

When is an incident "severe"? Where it negatively affects, or is capable of affecting, the product's ability to protect availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or where it has led or is capable of leading to the introduction or execution of malicious code in the product or a user's systems.

Who receives the severe incident notification and vulnerability report? Both go simultaneously to the CSIRT designated as coordinator and to ENISA, via the single reporting platform under Article 16. You file into the end-point of the CSIRT in your Member State of main establishment.

What are the later deadlines? A 72-hour notification, then a final report. For a vulnerability the final report is due no later than 14 days after a corrective or mitigating measure is available; for a severe incident, within one month after the incident notification.

What are the penalties for non-compliance? Infringements of Article 14 can attract administrative fines of up to EUR 15 000 000 or up to 2.5% of total worldwide annual turnover, whichever is higher. Microenterprises and small enterprises are shielded specifically from fines for missing the 24-hour early-warning deadline.

Is there a voluntary reporting route? Yes. Article 15 lets manufacturers and others voluntarily notify vulnerabilities, cyber threats, incidents, and near misses to a CSIRT designated as coordinator or ENISA, processed under the same Article 16 procedure.