Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
What is the CRA Article 14 final report, and when is it due?
Updated
The CRA final report is Article 14's third rung: no later than 14 days after a corrective or mitigating measure is available on the actively-exploited track, or within one month after the 72-hour incident notification on the severe-incident track. Those two deadlines are not one number.
CRA final-report guide, last verified 8 September 2026 against Regulation (EU) 2024/2847 Articles 14(2)(c) and 14(4)(c), 14(1), 14(3), 14(7), 16 and 71(2), ENISA's Single Reporting Platform FAQ (updated 8 September 2026 — agency guidance, not the regulation), the SRP Glossary, and the European Commission's CRA reporting page. Article 14 applies from 11 September 2026. It is not legal advice, not a filing, not a 24-hour early warning, not a 72-hour notification, not a determination that a measure is available, and does not start a clock. Recipients are the CSIRT designated as coordinator and ENISA via the single reporting platform.
This is the final report, not YOUR clock
Audience: a CISO, incident responder, or counsel at an organisation that might be a manufacturer of products with digital elements under Regulation (EU) 2024/2847. This page is not legal advice. It does not start a clock. Reading it does not start a clock. Mapping a row is not a determination that the CRA applies, that you are a manufacturer, that a product with digital elements has been made available on the Union market, that a corrective or mitigating measure is available, that a 72-hour incident notification has been submitted, or that a filing is due.
The CRA is Regulation (EU) 2024/2847 of 23 October 2024, OJ L 2024/2847, 20.11.2024. ELI: http://data.europa.eu/eli/reg/2024/2847/2024-11-20. Article 71(2): this Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026. Last verified 8 September 2026. Not legal advice.
- Statute versus guidance: Articles 14(1), 14(2)(c), 14(3), 14(4)(c), 14(7), 16 and 71(2) are legal requirements only if they apply. ENISA's Single Reporting Platform FAQ (updated 8 September 2026), SRP Glossary, FAQ 16 field table, FAQ 26 counters, and the Commission's CRA reporting page are guidance, not the regulation. This page quotes which kind of text it is relying on.
- The live Article 14 reporting guide on this site is the CRA Article 14 page under breach reporting — the full ladder. The CRA overview on this site is the pillar page. The who-is-covered guide on this site is the economic-operator roles page. The CRA-cluster Article 14 overview on this site is the cluster reporting page. A dedicated 24-hour early warning, 72-hour notification, security-updates, and evidence-retention guide is not on this site yet. Naming them is not a link.
- The signed-in CRA ladder tracks the 14-day final-report stage from recorded measure-available time for findings the organisation classified as CRA-in-scope actively exploited. That tracker does not start an Article 14 clock, does not decide that the CRA applies, and does not file with a CSIRT or ENISA. A named human still submits.
Two tracks, two final-report deadlines — do not collapse them
Article 14 has two mandatory tracks. They share a 24-hour early warning and a 72-hour notification. They diverge at the final report. The 14-day mark on the actively-exploited track is not the one-month mark on the severe-incident track. This page does not average them. Last verified 8 September 2026. Not legal advice.
- The live Article 14 reporting guide on this site records the same split: the 14-day mark on the actively-exploited track is not the one-month mark on the severe-incident track.
- Do not paste NIS2's one-month final report onto CRA's 14-day actively-exploited final report. Do not paste CRA's 14-day mark onto the severe-incident one-month final report.
- This page does not convert 'one month' into a number of hours. Fourteen days is fourteen days. One month is one month.
| Limb | What the cited text says | Kind of text | What this page does not do |
|---|---|---|---|
| Actively exploited vulnerability — Article 14(1) and 14(2)(c) | Article 14(1): a manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA. The manufacturer shall notify that actively exploited vulnerability via the single reporting platform established pursuant to Article 16. Article 14(2)(c): unless the relevant information has already been provided, a final report, no later than 14 days after a corrective or mitigating measure is available, including at least: (i) a description of the vulnerability, including its severity and impact; (ii) where available, information concerning any malicious actor that has exploited or that is exploiting the vulnerability; and (iii) details about the security update or other corrective measures that have been made available to remedy the vulnerability. | Legal requirement — Articles 14(1) and 14(2)(c). Only if the CRA applies. | Does not find that YOUR CVE is an actively exploited vulnerability. Does not find that a measure is available. Does not start the 14 days. |
| Severe incident — Article 14(3) and 14(4)(c) | Article 14(3): a manufacturer shall notify any severe incident having an impact on the security of the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA. The manufacturer shall notify that incident via the single reporting platform established pursuant to Article 16. Article 14(4)(c): unless the relevant information has already been provided, a final report, within one month after the submission of the incident notification under point (b), including at least a detailed description of the incident including its severity and impact, the type of threat or root cause that is likely to have triggered the incident, and applied and ongoing mitigation measures. | Legal requirement — Articles 14(3) and 14(4)(c). | Does not score YOUR incident as severe. Does not find that a 72-hour incident notification has been submitted. Does not convert 'one month' into a number of hours. Does not treat 14 days as this mark. |
| Clock-start is not the same event | Article 14(2)(c) runs from measure availability — not from the manufacturer becoming aware. Article 14(4)(c) runs from submission of the incident notification under Article 14(4)(b) — not from awareness, and not from measure availability. The 24-hour early warning and the 72-hour notification run from becoming aware. Those three marks are not one number. | Legal requirement of the cited points. | Does not start 24 hours, 72 hours, 14 days, or one month. Does not average the two final-report marks. |
Clock-start — measure availability versus 72-hour submission
The final-report clock does not start from the manufacturer becoming aware. Article 14(2)(c) starts from a corrective or mitigating measure being available. Article 14(4)(c) starts from submission of the 72-hour incident notification. This page does not find either event. It does not start 14 days or one month. Last verified 8 September 2026. Not legal advice.
| Event | What the cited text says | Kind of text | What this page does not do |
|---|---|---|---|
| Corrective or mitigating measure is available — actively-exploited track | Article 14(2)(c): a final report, no later than 14 days after a corrective or mitigating measure is available. | Legal requirement — Article 14(2)(c). | Does not find that YOUR patch, workaround, or other measure is available. Does not start the 14 days. |
| Submission of the 72-hour incident notification — severe-incident track | Article 14(4)(c): a final report, within one month after the submission of the incident notification under point (b). | Legal requirement — Article 14(4)(c). | Does not find that YOUR 72-hour incident notification has been submitted. Does not convert 'one month' into hours. |
| Not becoming aware, and not the 24-hour or 72-hour marks | Article 14(2)(a) and 14(4)(a) are 24 hours from becoming aware. Article 14(2)(b) and 14(4)(b) are 72 hours from becoming aware. Article 14(2)(c) is 14 days after a measure is available. Those three marks are not averaged. A dedicated 24-hour early-warning and 72-hour notification guide is not on this site yet. Naming them is not a link. | Legal requirement of the cited points. | Does not start 24 hours or 72 hours. Does not treat the early warning or the 72-hour notification as the final report. |
| Recorded measure-available time in the signed-in ladder | The product tracks a human-recorded measure-available-at for findings the organisation classified as CRA-in-scope actively exploited. The 14-day stage runs from that recorded time. Without a recorded past measure-available time, that stage does not run in the tracker. A KEV match timestamp is disclosure, not the clock. | Product behaviour — not the regulation. | Does not start the statutory clock. Does not treat an in-scope mark as measure availability. Does not run Article 14(4)(c)'s one-month clock. |
| ENISA SRP final-report counters | ENISA SRP FAQ 26 (updated 8 September 2026) states that, for actively exploited vulnerabilities, no counter is currently implemented, as the final-report deadline depends on the date and time when a corrective or mitigating measure becomes available. For severe incidents, the counter displays a due date one month after submission of the 72-hour severe-incident notification. FAQ 26 also states those counters do not replace the Article 14 obligation. | Agency guidance / platform counter — not Article 14. | Does not treat the platform counter as Article 14(2)(c) or 14(4)(c). |
Required-content checklist — statute versus ENISA extras
Article 14(2)(c) and Article 14(4)(c) state the statutory minimum of the final report, unless the relevant information has already been provided. ENISA's SRP FAQ 16 and SRP Glossary add platform fields. Those extras are agency guidance, not the article. Last verified 8 September 2026. Not legal advice. This table is not YOUR filing.
| Item | What the cited text says | Kind of text | What this page does not do |
|---|---|---|---|
| Actively-exploited statutory minimum — Article 14(2)(c) | Including at least: a description of the vulnerability, including its severity and impact; where available, information concerning any malicious actor that has exploited or that is exploiting the vulnerability; and details about the security update or other corrective measures that have been made available to remedy the vulnerability. | Legal requirement — Article 14(2)(c). | Does not draft YOUR description. Does not find that a malicious actor is known. Does not find that a security update is available. |
| Severe-incident statutory minimum — Article 14(4)(c) | Including at least a detailed description of the incident including its severity and impact, the type of threat or root cause that is likely to have triggered the incident, and applied and ongoing mitigation measures. | Legal requirement — Article 14(4)(c). | Does not find YOUR root cause. Does not score severity. |
| Unless already provided | Article 14(2)(c) and Article 14(4)(c) open with 'unless the relevant information has already been provided'. That clause does not delete the final-report limb. | Legal requirement. | Does not find that YOUR 72-hour notification already provided the final-report content. |
| Recipients | The CSIRT designated as coordinator and ENISA, via the single reporting platform. Article 14(7) and Article 16. Notifications are simultaneously accessible to ENISA. | Legal requirement — Article 14(7) and Article 16. | Does not name YOUR CSIRT. Does not file. |
| ENISA FAQ 16 / SRP Glossary — AEV platform fields at the final report | ENISA marks as required at the final-report stage, among others: date when a corrective or mitigating measure has been available; full description of the severity of the vulnerability; full description of the impact of the vulnerability; and, if such information is available, the malicious actor. CVE ID, EUVD ID, product type, product class, product category, and attack vector are optional or carried forward. Corrective or mitigating measures taken, and measures users can take, are marked required and carried from the 72-hour stage. | Agency guidance — ENISA SRP FAQ 16 and SRP Glossary (updated 5 September 2026), not Article 14(2)(c). The article names one description including severity and impact; the platform splits those into two fields. | Does not treat an ENISA required-field mark as the article. Does not treat a CVE or EUVD identifier as a statutory minimum of Article 14(2)(c). |
| ENISA FAQ 16 / SRP Glossary — SI platform fields at the final report | ENISA marks as required at the final-report stage: applied and ongoing mitigation measures; detailed description of the severity of the incident; detailed description of the impact of the incident; and type of threat or root cause that is likely to have triggered the incident. Date/time the incident occurred is optional. The article names one detailed description including severity and impact; the platform splits those into two fields. | Agency guidance — ENISA SRP FAQ 16 and SRP Glossary, not Article 14(4)(c). | Does not treat an ENISA required-field mark as the article. |
| ENISA FAQ 7 deadline paraphrase | ENISA FAQ 7 (updated 8 September 2026) paraphrases: for actively exploited vulnerabilities, no later than 14 days after a corrective measure (for example a patch) becomes available; for severe incidents, within 1 month after the 72-hour notification. | Agency guidance — not a substitute for Article 14(2)(c) ('corrective or mitigating measure') or Article 14(4)(c) ('within one month after the submission of the incident notification under point (b)'). | Does not treat 'patch' as the only measure Article 14(2)(c) names. Does not treat '1 month' as a rewrite of 'one month'. |
Worked timing example — illustration, not YOUR clock
The instants below are hypothetical. They are not a finding that anyone became aware, that a measure is available, or that a 72-hour notification was submitted. They are not YOUR clock. Last verified 8 September 2026. Not legal advice. This page does not start a clock.
| Hypothetical instant | What it illustrates | Kind of text | What this page does not do |
|---|---|---|---|
| 15 September 2026, 09:00 UTC | A hypothetical recorded-awareness instant. The 24-hour early warning and the 72-hour notification run from becoming aware. That instant is not the final-report clock-start on either track. | Illustration — not a due-date for YOU. A dedicated 24-hour and 72-hour guide is not on this site yet. Naming them is not a link. | Does not start the statutory clock. Does not find that YOU have become aware. |
| 16 September 2026, 09:00 UTC | Twenty-four hours later than that hypothetical instant — the 24-hour early-warning band (Article 14(2)(a) or 14(4)(a)). Not the 14-day final report, and not the one-month final report. | Illustration of the 24-hour band — not a due-date for YOU. | Does not file an early warning. |
| 18 September 2026, 09:00 UTC | Seventy-two hours later than that hypothetical instant — the 72-hour notification band (Article 14(2)(b) or 14(4)(b)). On the severe-incident track, Article 14(4)(c) then runs from submission of that incident notification, within one month. That is not 14 days. | Illustration of the 72-hour band — not a due-date for YOU. | Does not file a 72-hour notification. Does not convert the later 'one month' into hours. |
| 20 September 2026, 12:00 UTC | A hypothetical instant when a corrective or mitigating measure is available. Article 14(2)(c) runs from this event on the actively-exploited track — not from awareness on 15 September. | Illustration of measure availability — not a finding that YOUR measure is available. | Does not start the 14 days. Does not treat a KEV match as this instant. |
| 4 October 2026, 12:00 UTC | Fourteen days later than that hypothetical measure-available instant. Article 14(2)(c) says no later than 14 days after a corrective or mitigating measure is available. That is not 24 hours, not 72 hours, and not the severe-incident one-month mark. | Illustration of the statutory 14-day band — not a due-date for YOU. | Does not file a final report. Does not run a countdown widget. |
| One month after the hypothetical 72-hour incident notification | Article 14(4)(c): within one month after the submission of the incident notification under point (b). If that hypothetical 72-hour filing were submitted at 18 September 2026, 09:00 UTC, the severe-incident final report would be within one month after that submission. This page does not convert 'one month' into a number of hours, and does not treat 4 October as that mark. | Illustration of the statutory one-month band — not a due-date for YOU. | Does not file. Does not average 14 days with one month. |
Legal requirement versus Commission and ENISA guidance
The table below labels each text. Do not treat guidance as the article, and do not treat the article as optional because a FAQ exists. Last verified 8 September 2026. Not legal advice.
| Text | What it is | What this page does not do |
|---|---|---|
| Regulation (EU) 2024/2847 Articles 14(1), 14(2)(c), 14(3), 14(4)(c), 14(7), 16, 71(2) | Legal requirement — the regulation, only if it applies. | Does not apply those articles to YOU. |
| European Commission CRA reporting page | Commission materials. Guidance, not the regulation. | Does not treat a Commission summary as a substitute for Article 14(2)(c) or 14(4)(c). |
| ENISA Single Reporting Platform FAQ (updated 8 September 2026), SRP Glossary, FAQ 7 deadlines, FAQ 16 field table, FAQ 26 counters | Agency guidance on the Article 16 platform. FAQ 16 adds required platform fields beyond the Article 14(2)(c) and 14(4)(c) statutory minimum. FAQ 26 describes platform counters that do not replace Article 14. | Does not treat an ENISA required-field mark as the article. Does not treat the platform counter as Article 14(2)(c). |
What to do now
As of last verification on 8 September 2026, Article 14 applies from 11 September 2026 — three days from that verification date. The list below is operational preparation. It is not a determination that the CRA applies to YOU, that a measure is available, or that a reporting clock has started. Walk it with counsel.
- Ask counsel whether YOU are a manufacturer of a product with digital elements made available on the Union market. This page does not run that test. Marking CRA in an obligation map is not that determination.
- If counsel says Article 14 may apply, separate the two tracks before you pick a final-report deadline. Actively exploited: 14 days after a corrective or mitigating measure is available (Article 14(2)(c)). Severe incident: one month after submission of the 72-hour incident notification (Article 14(4)(c)). Those two marks are not one number.
- Decide how the organisation will record the minute a corrective or mitigating measure is available, in UTC, separately from recorded awareness. Do not treat reading this page as measure availability. The signed-in ladder, if you use it, tracks recorded measure-available time — it does not decide that minute.
- Do not paste the 14-day mark onto the 24-hour or 72-hour bands. Do not paste it onto the severe-incident one-month mark. Do not treat ENISA FAQ 16 extra fields as Article 14(2)(c).
- The CRA-cluster Article 14 overview on this site is the cluster reporting page. A dedicated 24-hour early warning, 72-hour notification, security-updates, and evidence-retention guide is not on this site yet. Naming them is not a link. The live Article 14 reporting guide on this site is the full ladder.
Checklist
This is a question list, not a filing, and not YOUR notice. Walk it with counsel. The live Article 14 reporting guide on this site is the ladder. The reporting-deadlines page on this site is the statute table of clocks.
- Does the CRA apply? Manufacturer of a product with digital elements made available on the Union market. This page does not run that test.
- Actively exploited vulnerability under Article 3(42), or severe incident under Article 14(5)? Do not collapse the two tracks at the final report.
- Final report, actively-exploited track: 14 days after a corrective or mitigating measure is available — Article 14(2)(c). Not from awareness. Not 24 hours. Not 72 hours.
- Final report, severe-incident track: one month after submission of the 72-hour incident notification — Article 14(4)(c). Not 14 days. Do not convert 'one month' into hours.
- Statutory content: description including severity and impact; malicious actor where available, or threat/root cause; details of the security update or other corrective measures, or applied and ongoing mitigation measures. ENISA FAQ 16 extra fields are guidance.
- Recipients: the CSIRT designated as coordinator and ENISA via the single reporting platform. This page does not file.
- Is this the 24-hour early warning or the 72-hour notification? No. The CRA-cluster Article 14 overview on this site is the cluster reporting page. A dedicated 24-hour, 72-hour, security-updates, and evidence-retention guide is not on this site yet. Naming them is not a link.
- Document the assessment, including a no-final-report decision. This page does not keep YOUR file.
Where this shows up in ShipReady Metrics
The signed-in app does not decide that the CRA applies, does not decide that you are a manufacturer, does not decide that a finding is an actively exploited vulnerability or a severe incident, does not start an Article 14 clock, and does not submit to ENISA or a CSIRT. There is no CSIRT submit button and no ENISA API. None of the surfaces below is 'the clock has started' or an instruction to submit a filing.
If you already have a session: signed-in app → Compliance → CRA reporting tracks the Article 14 14-day final-report stage from recorded measure-available time for findings the organisation classified as CRA-in-scope actively exploited. That tracker does not start the statutory clock. It does not file. A named human still submits. Recorded measure-available time is a human determination the platform must not backdate. Without a recorded past measure-available time, the 14-day stage does not run in the tracker. An in-scope mark is not measure availability. A KEV match timestamp is disclosure, not the clock. The product does not run Article 14(4)(c)'s one-month severe-incident final-report clock.
The obligation map lists frameworks the organisation has marked in-scope, including cra if that mark is set. That mark is not a determination that the CRA applies and is not measure availability. The cyber risk register lives under Security. Named-reviewer drafts of ladder text are marked DRAFT; nothing in that surface has been sent to any authority.
This page does not invent a 14-day countdown widget. The signed-in ladder is a reporting-stage tracker, not a public countdown. This page does not document a public demo URL. There is no public CRA demo path.
Primary sources (last verified 8 September 2026)
Every regulatory or guidance claim on this page is taken from one of these. If a later revision of a source changes the rule, the date above is how you can see we have not re-checked yet.
Regulation (EU) 2024/2847 of 23 October 2024 (Cyber Resilience Act), Articles 14(1), 14(2)(c), 14(3), 14(4)(c), 14(7), 16 and 71(2), is a legal requirement only if it applies. Article 14 applies from 11 September 2026 (Article 71(2)). The European Commission's CRA reporting page is Commission materials, not the regulation. ENISA's Single Reporting Platform FAQ (updated 8 September 2026), SRP Glossary (version 1.1, last update 5 September 2026), FAQ 7, FAQ 16 field table and FAQ 26 counters are agency guidance on the Article 16 platform, not the regulation. These are not a complete world list. Not legal advice.
The CRA overview on this site is the pillar page. The who-is-covered guide on this site is the economic-operator roles page. The CRA Article 14 reporting guide on this site is the live ladder. The reporting-deadlines page on this site is the statute table of clocks. The NIS2 incident-reporting guide on this site is Article 23. The DORA incident-reporting guide on this site is Articles 18–19. The CRA-cluster Article 14 overview on this site is the cluster reporting page. A dedicated 24-hour early warning, 72-hour notification, security-updates, and evidence-retention guide is not on this site yet. Naming them is not a link.
Frequently asked questions
Is this legal advice?
No. It is a third-rung guide distilled from Regulation (EU) 2024/2847 Articles 14(2)(c) and 14(4)(c), with ENISA Single Reporting Platform materials labelled as guidance, not the regulation. Whether the CRA applies, whether a measure is available, whether a 72-hour notification has been submitted, and whether a clock has started are legal questions for counsel on your facts. This page does not start a clock.
Does ShipReady file the final report?
No. The signed-in app does not file with a CSIRT or ENISA, does not start an Article 14 clock, and does not decide that the CRA applies. There is no CSIRT submit button and no ENISA API. Compliance → CRA reporting tracks the 14-day final-report stage from recorded measure-available time for findings the organisation classified as CRA-in-scope actively exploited. A named human still submits.
Is 14-day the same as 24h or 72h?
No. Article 14(2)(a) is 24 hours from becoming aware (early warning). Article 14(2)(b) is 72 hours from becoming aware (vulnerability notification). Article 14(2)(c) is 14 days after a corrective or mitigating measure is available (final report on the actively-exploited track). Those three marks are not one number. This page does not start any of them. A dedicated 24-hour and 72-hour guide is not on this site yet. Naming them is not a link.
Is the actively-exploited 14-day the same as the severe-incident track deadline?
No. Article 14(2)(c) of Regulation (EU) 2024/2847 says a final report, no later than 14 days after a corrective or mitigating measure is available. Article 14(4)(c) says a final report, within one month after the submission of the incident notification under point (b). The live Article 14 reporting guide on this site records that those two final-report marks are not the same. This page does not average them, and does not convert 'one month' into a number of hours.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.