CRA Incident Reporting Deadlines
The EU Cyber Resilience Act's Article 14 sets up two separate reporting duties, not one sequence: an actively exploited vulnerability and a severe incident share the same 24-hour and 72-hour stages but diverge at the final report deadline. Filing there does not satisfy the separate duty to inform affected users.
13 min read
50 views
Key takeaways: CRA incident reporting deadlines 5
Which of the two Article 14 clocks actually governs a given deadline, and why tracking them as one countdown gets the vulnerability track wrong every time.
- Two triggers, two clocks Article 14 covers actively exploited vulnerabilities and severe incidents separately. The early warning and notification stages look alike; the final report deadline does not.
- The vulnerability final report follows the fix, not the alert Fourteen days is measured from when a corrective measure becomes available, under Article 14(2)(c), which can be well after the initial 72-hour notification.
- The incident final report follows the calendar, not resolution One month from the 72-hour notification, under Article 14(4)(c), regardless of whether the incident is closed.
- Track both deadlines as separate fields, not one countdown A single field for final report due, built around a fixed number of days from detection, gets one of the two triggers wrong every time.
- Article 14 applies from 11 September 2026, over a year before the rest of the Act Reporting obligations are front-loaded ahead of the CRA's 11 December 2027 general application date, per Article 71(2); voluntary reporting under Article 15 stays on the later date.
Two clocks, not one
The Cyber Resilience Act, Regulation (EU) 2024/2847, requires manufacturers of products with digital elements to report certain events through a single online channel. Most coverage of that rule compresses it into one sequence: 24 hours, then 72 hours, then 14 days. That sequence exists, but it only describes half of Article 14. The regulation actually sets up two separate reporting obligations, triggered by different events.
In short: The EU Cyber Resilience Act, Regulation (EU) 2024/2847, requires manufacturers of products with digital elements to report certain events through the single reporting platform established under Article 16. Article 14 sets up two separate reporting duties on that platform, not one sequence. An actively exploited vulnerability, under Article 14(1) and (2), and a severe incident, under Article 14(3) and (4), share the same 24-hour early warning and 72-hour notification stages but diverge at the final report: 14 days after a corrective or mitigating measure becomes available for a vulnerability, under Article 14(2)(c), against one calendar month after the 72-hour notification is submitted for an incident, under Article 14(4)(c). Filing there never satisfies the separate Article 14(8) duty to inform affected users.
Here is how the European Commission itself summarizes the schedule: “They need to submit an early warning within 24 hours of becoming aware, and a full notification within 72 hours. A final report needs to be submitted no later than 14 days after a corrective measure is available for actively exploited vulnerabilities and within a month for severe incidents.”
Clock one: actively exploited vulnerabilities
Article 14(1) and 14(2) apply when a manufacturer becomes aware that a product with digital elements contains a vulnerability that is being actively exploited. The obligation is to notify both the CSIRT designated as coordinator under the Act and ENISA, at the same time, through the single reporting platform set up under Article 16. There is no sequential handoff between the two recipients. Both see the notification when it lands.
The first stage, under Article 14(2)(a), is an early warning within 24 hours of becoming aware of the exploitation. At this point the manufacturer typically knows little beyond the fact that something is being actively abused. The regulation still asks for a Member State breakdown where applicable, meaning the manufacturer needs to already know, or be able to determine quickly, which national markets the affected product reached.
The second stage, under Article 14(2)(b), is a vulnerability notification within 72 hours. This is where the substance shows up: general information about the product, the general nature of the exploit and of the vulnerability itself, any corrective or mitigating measures already taken, what actions users can take in the meantime and how sensitive the manufacturer considers the disclosed information to be. Seventy-two hours is not much time to produce an accurate technical description of an exploit while also deciding how much of that description is safe to circulate before a fix ships.
The third stage, under Article 14(2)(c), is the final report, and this is the one most write-ups get wrong. It is due no later than 14 days after a corrective or mitigating measure becomes available, not 14 days after the initial 24-hour warning and not 14 days after the 72-hour notification. If the fix takes six weeks to develop and ship, the 14-day clock for the final report has not even started until that fix exists. The final report itself needs a description of the vulnerability including its severity and impact, information about any malicious actor known to have exploited it and details of the security update or other corrective measures applied.
The first two stages on this track, the 24-hour early warning and the 72-hour notification, start the moment the manufacturer becomes aware, and becoming aware is doing a lot of work in that sentence. It is not the same moment as when a security researcher first files a report, or when a customer opens a support ticket describing odd behavior, or when an automated scanner flags an anomaly. It is the point at which the organization has enough signal to treat the event as an actively exploited vulnerability rather than noise. Product security teams need a documented triage step that records that moment, because the 24-hour clock is measured from it and a regulator asking when the manufacturer became aware expects a specific timestamp, not a range. The final report clock is different again: as the previous paragraph covers, it runs from when a corrective or mitigating measure becomes available, not from awareness at all.
Clock two: severe incidents
Article 14(3) and 14(4) cover a different trigger: a severe incident having an impact on the security of a product with digital elements, as opposed to a known vulnerability being exploited. The addressees and the platform are the same as clock one. So are the first two stages in shape: an early warning within 24 hours, followed by an incident notification within 72 hours that mirrors the structure of the vulnerability notification.
The divergence is the final report. For a severe incident, Article 14(4)(c) sets the deadline at within one month of submitting the 72-hour incident notification. That is a fixed, calculable date. It does not wait for a fix, a patch or a mitigation to exist. A manufacturer can, and often will, still be working the incident when the one-month final report comes due, and the report needs to reflect that state honestly rather than wait for resolution.
Content requirements track the shape of an incident response writeup rather than a vulnerability disclosure: a detailed description of the incident including its severity and impact, the type of threat or root cause that appears to have triggered it and the mitigation measures applied and still ongoing. Where clock one's final report closes out with a fix, clock two's final report is a status report on a fixed schedule, closed or not.
What counts as a severe incident is set out in Article 14(5), and a companion article on severe incident classification covers the two-limb test in full. The triage step matters here just as much as it does under clock one, and the same event can sometimes qualify under both Article 14(1) and Article 14(3) at once, if an actively exploited vulnerability is also the root cause of a severe incident. In that case the manufacturer is not choosing between the two clocks. Nothing in Article 14 makes the two duties mutually exclusive, so on the face of the text both can run in parallel against the same underlying event.
Why the final report deadline trips people up
The practical difference between the two clocks comes down to what the final deadline is a function of. Clock one's final report is a function of engineering output: it moves whenever the corrective measure ships, and building an incident response runbook around a static 14-day countdown from the initial alert will produce a report that is either premature and inaccurate or simply late, because the actual trigger has not happened yet. Clock two's final report is a function of calendar time from a fixed prior filing, one calendar month after the 72-hour notification is submitted, so it behaves like a normal SLA. A calendar month is not a fixed day count, though: a notification filed in March and one filed in April land their final report due dates a different number of days apart, even though both are described the same way as one month out.
The table below is a worked hypothetical, not a record of a real incident. It runs one event through both tracks at once, because a single exploited vulnerability that also degrades a product's security often qualifies as both an actively exploited vulnerability under Article 14(1) and (2) and a severe incident under Article 14(3) and (4), as the previous section covers. Times are shown in Central European Time only for the 24-hour and 72-hour stages; the final report dates fall after the EU's shift to summer time on 28 March 2027.
| Stage | Provision | Vulnerability track | Incident track |
|---|---|---|---|
| Awareness | Article 14(1) and Article 14(3) | 8 March 2027, 09:00 CET. The manufacturer confirms active exploitation of a vulnerability that also meets the Article 14(5) severe-incident test, so both clocks start from the same timestamp. | |
| Early warning | Article 14(2)(a) and Article 14(4)(a) | 9 March 2027, 09:00 CET (24-hour outer limit; without undue delay) | 9 March 2027, 09:00 CET (24-hour outer limit; without undue delay) |
| Notification | Article 14(2)(b) and Article 14(4)(b) | Submitted 11 March 2027, 09:00 CET, at the 72-hour outer limit (without undue delay) | Submitted 11 March 2027, 09:00 CET, at the 72-hour outer limit (without undue delay) |
| Final report | Article 14(2)(c) and Article 14(4)(c) | A corrective measure ships 22 April 2027. Final report due 6 May 2027, 14 days after the measure becomes available | Final report due 11 April 2027, one calendar month after the 11 March notification was submitted |
The two final report dates land 25 days apart even though every stage before them was identical. The incident track's final report falls due on 11 April 2027, one calendar month after the 72-hour notification, which works out to 31 days here because March runs 31 days long. The vulnerability track's final report does not move until a corrective measure exists, and only starts counting down 14 days after that measure ships, landing on 6 May 2027 in this scenario. A fix that takes six weeks to build and test after the 72-hour notification, the kind of timeline the earlier section on clock one describes, is exactly what pushes the two dates this far apart.
A useful way to represent this internally is to stop treating final report as one ticket type. An incident tracker built for CRA compliance needs two distinct deadline fields on any qualifying event: one that is null until a corrective measure ships and then becomes ship date plus 14 days, and one that is calculated the moment the 72-hour notification for a severe incident goes out. Merging them into a single final report due field, or worse, hardcoding 14 days from detection as a company policy, guarantees a wrong answer for one class of event or the other. Teams that ship long-lived embedded or industrial products, where a fix can take months to validate and roll out, are the ones most exposed to this mistake, because the gap between the moment we know about it and the moment a fix exists is exactly the gap the 14-day rule leaves open.
The user notification duty engineering teams forget
Article 14(7) governs how notifications reach the platform, including which CSIRT end-point a manufacturer with no main establishment in the Union has to use. Where necessary, the CSIRT designated as coordinator that initially received the notification can also request an intermediate report on relevant status updates under Article 14(6), and the Commission can refine the platform's submission format through implementing acts under Article 14(10); the rest of the platform's mechanics are covered in a companion article on the CRA Single Reporting Platform.
Article 14(8) is easy to miss because it sits alongside the regulator-facing obligations but points somewhere else entirely: manufacturers have a separate duty to inform impacted users, and where appropriate all users, about the vulnerability or incident and about any corrective or mitigating measures they should take. Notifying the CSIRT and ENISA does not discharge this. It is a distinct obligation with a distinct audience.
The regulation adds a detail that has direct engineering consequences: this user-facing disclosure should happen, where appropriate, in a structured machine-readable format that is easily automatically processable. That is not satisfied by a blog post or a support email. It points toward a security advisory feed with a stable schema, something that a customer's own vulnerability management tooling can ingest and correlate against a software bill of materials, in the same spirit as a CSAF or VEX document. Teams that only have a marketing-owned status page today have a gap to close before the user notification duty becomes routine.
Article 17(4) is worth stating alongside this because it removes a common internal objection to prompt reporting: the act of notifying under Article 14 does not by itself expose the manufacturer to increased liability. That does not make the underlying vulnerability or incident less serious, but it does mean the reporting obligation itself is not the thing that creates legal exposure. CRA reporting also sits alongside other EU incident reporting regimes rather than replacing them, so the same event can trigger more than one regulatory clock depending on the sector, a point a companion article covers in full for the overlap between the CRA, NIS2 and DORA.
When these obligations actually start
Article 71(2) staggers the CRA's application dates, and getting them right matters because the reporting rules described above do not take effect on the same day as the rest of the Act. The Commission's own summary states the headline dates clearly.
So Article 14, the reporting article this entire piece has been about, becomes enforceable well over a year before the rest of the CRA's product requirements apply. Chapter IV, Articles 35 to 51, which covers the notified bodies and conformity assessment infrastructure, applies from 11 June 2026, ahead of both of those dates, because that infrastructure needs to exist before anyone can be assessed against it. Everything else in the Act, including the core security requirements for products with digital elements, applies from 11 December 2027.
One correction is worth stating explicitly because it is commonly reported wrong: Article 15 is not a sub-threshold channel for events too minor to trigger Article 14. It lets manufacturers as well as other natural or legal persons voluntarily notify any vulnerability contained in a product with digital elements and any cyber threat that could affect a product's risk profile under Article 15(1), and any incident or near miss under Article 15(2), to a CSIRT designated as coordinator or ENISA. Article 15(4) expressly contemplates voluntary reports of the same actively exploited vulnerabilities and severe incidents Article 14 already covers, filed by someone other than the manufacturer, and Article 15(5) confirms that submitting a voluntary notification does not impose any additional obligation on the notifier. Article 15 is also not among the provisions carved out for early application: it applies from 11 December 2027, the general application date, not from 11 September 2026 alongside the mandatory Article 14 obligations. A manufacturer that wants to build a voluntary disclosure program ahead of the general deadline is free to do so, but Article 15 never compels voluntary reporting, and no deadline attaches to it the way one does to Article 14.
How Pharos Production helps
Teams building products that will eventually carry digital elements into the EU need incident response tooling that keeps the vulnerability deadline and the incident deadline as two distinct data structures, not one shared field with a single countdown. Our cybersecurity services build and integrate CSIRT and platform-facing notification pipelines, structured machine-readable advisory feeds that satisfy the Article 14(8) user notification duty and the internal tracking that keeps a corrective-measure-triggered deadline and a submission-triggered deadline from colliding in the same ticket. If your incident response process was designed around a single 24/72/14 mental model, we help rebuild it around the two triggers Article 14 actually defines, ahead of the 11 September 2026 application date.
None of this needs to wait for the 11 September 2026 application date to start. Standing up the triage step and wiring a draft integration against the platform's published field requirements can happen well ahead of time, along with building the machine-readable advisory format. Doing that turns the first real incident into a process that already exists rather than one being invented under a 24-hour deadline.
Sources: European Commission, Cyber Resilience Act reporting obligations (digital-strategy.ec.europa.eu/en/policies/cra-reporting); European Commission, Cyber Resilience Act policy overview (digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act); Regulation (EU) 2024/2847 of the European Parliament and of the Council, Articles 14, 15, 16, 17 and 71.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 7
No matches
Try a different keyword, change the topic or clear filters
-
Two. Article 14 defines two separate triggers, an actively exploited vulnerability under Article 14(1) and (2), and a severe incident under Article 14(3) and (4).
Both share the same 24-hour early warning and 72-hour notification stages, but the deadline for the closing final report is calculated differently for each one.
-
No later than 14 days after a corrective or mitigating measure becomes available, under Article 14(2)(c). The clock does not start at the moment of detection or at the 72-hour notification.
It starts when a fix exists, which can be weeks or months after the vulnerability was first reported.
-
Within one month of submitting the 72-hour incident notification, under Article 14(4)(c). Unlike the vulnerability track, this deadline is fixed and does not wait for the incident to be resolved or for a mitigation to be finished.
-
Article 64(1) leaves the actual penalty regime to Member States, who must set penalties that are effective, proportionate and dissuasive. Article 64(2) is the fine tier addressed to non-compliance with the essential requirements in Annex I and the obligations set out in Articles 13 and 14.
Article 64(10)(a) is written as a derogation from paragraphs 3 to 9, and names the deadlines in Article 14(2), point (a) and Article 14(4), point (a) for manufacturers qualifying as microenterprises or small enterprises. The derogation is written against paragraphs 3 to 9 while the tier that covers Article 14 is paragraph 2, so how far the carve-out reaches a missed 24-hour deadline is not settled on the face of the text. A manufacturer relying on it should check how its Member State implements Article 64(1).
-
No. Article 14(8) creates a separate obligation to inform impacted users, and where appropriate all users, about the vulnerability or incident and the measures they should take, where appropriate in a structured machine-readable format. Regulator notification and user notification are two different duties with two different audiences.
-
Article 14(2)(a) and Article 14(4)(a) both require the early warning without undue delay and in any event within 24 hours of becoming aware. Article 14 sets out no working-day or business-hours carve-out anywhere, so the 24 hours runs in calendar time, weekends and public holidays included.
The Regulation is silent on what happens specifically when awareness lands on a Friday evening or a holiday, so manufacturers should not assume an extension exists that the text does not grant.
-
No, and this is commonly reported wrong. Article 15 is not among the provisions given early application.
It applies from the general date, 11 December 2027, more than a year after the mandatory Article 14 reporting obligations take effect on 11 September 2026.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
