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 72-hour notification?
Updated
The CRA 72-hour notification is an Article 14 vulnerability or incident notification to the CSIRT designated as coordinator and to ENISA via the single reporting platform, without undue delay and in any event within 72 hours of the manufacturer becoming aware.
CRA 72-hour notification guide, last verified 8 September 2026 against Regulation (EU) 2024/2847 Articles 14(2)(b) and 14(4)(b), 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), 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 GDPR Article 33 notice, not a 24-hour early warning, not a determination that the manufacturer has become aware, and does not start a clock.
This is the 72-hour notification, not YOUR clock
Audience: an incident responder, CISO, 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 you have become aware, 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)(b), 14(3), 14(4)(b), 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, 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 GDPR breach-notification guide on this site is Articles 33–34 — a different instrument. The CRA-cluster Article 14 overview on this site is the cluster reporting page. The ENISA-workflow guide on this site is the platform-flow page. A dedicated 24-hour early warning and final-report guide is not on this site yet. Naming them is not a link.
- The signed-in CRA ladder tracks the 72-hour stage from recorded awareness for findings the organisation classified as CRA-in-scope. 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 triggers, one 72-hour limb — do not collapse them
Article 14 has two mandatory tracks. They share a 72-hour notification limb. They are not one trigger. This page does not collapse an actively exploited vulnerability into a severe incident, or the reverse. Last verified 8 September 2026. Not legal advice.
- The 72-hour band is the same length on both tracks. The statutory content of the notification is not the same. Article 14(2)(b) names the product, the general nature of the exploit and of the vulnerability, measures taken, measures users can take, and, where applicable, sensitivity. Article 14(4)(b) names the nature of the incident, an initial assessment of the incident, measures taken, measures users can take, and, where applicable, sensitivity.
- Do not paste GDPR 'awareness' or a 'discovery' test onto Article 14. The regulation's words are 'the manufacturer becoming aware of the actively exploited vulnerability' and 'the manufacturer becoming aware of the incident'. This page does not convert those words.
- This page does not round 72 hours to three days. Seventy-two hours is seventy-two hours.
| Limb | What the cited text says | Kind of text | What this page does not do |
|---|---|---|---|
| Actively exploited vulnerability — Article 14(1) and 14(2)(b) | 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)(b): unless the relevant information has already been provided, a vulnerability notification, without undue delay and in any event within 72 hours of the manufacturer becoming aware of the actively exploited vulnerability, which shall provide general information, as available, about the product with digital elements concerned, the general nature of the exploit and of the vulnerability concerned as well as any corrective or mitigating measures taken, and corrective or mitigating measures that users can take, and which shall also indicate, where applicable, how sensitive the manufacturer considers the notified information to be. | Legal requirement — Articles 14(1) and 14(2)(b). Only if the CRA applies. | Does not find that YOUR CVE is an actively exploited vulnerability. Does not start the 72 hours. |
| Actively exploited vulnerability — definition | Article 3(42): a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner. | Legal requirement — Article 3(42). | Does not treat a KEV listing, a scanner alert, or a customer report as, by itself, that finding. |
| Severe incident — Article 14(3) and 14(4)(b) | 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)(b): unless the relevant information has already been provided, an incident notification, without undue delay and in any event within 72 hours of the manufacturer becoming aware of the incident, which shall provide general information, where available, about the nature of the incident, an initial assessment of the incident, as well as any corrective or mitigating measures taken, and corrective or mitigating measures that users can take, and which shall also indicate, where applicable, how sensitive the manufacturer considers the notified information to be. | Legal requirement — Articles 14(3) and 14(4)(b). | Does not score YOUR incident as severe. Does not start the 72 hours. |
| Severe — Article 14(5) | An incident having an impact on the security of the product with digital elements shall be considered to be severe where: (a) 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 (b) it has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product with digital elements. | Legal requirement — Article 14(5). Qualitative. | Does not apply that test to YOUR facts. |
Clock-start — the manufacturer becoming aware
Article 14(2)(b) and Article 14(4)(b) start the 72 hours from the manufacturer becoming aware of the actively exploited vulnerability, or of the incident. That is the statutory clock-start. It is the same start event as the 24-hour early warning — not a second, later start when the early warning is filed. This page does not find that minute. It does not start the 72 hours. Last verified 8 September 2026. Not legal advice.
| Event | What the cited text says | Kind of text | What this page does not do |
|---|---|---|---|
| Manufacturer becoming aware — actively exploited track | Article 14(2)(b): without undue delay and in any event within 72 hours of the manufacturer becoming aware of the actively exploited vulnerability. | Legal requirement — Article 14(2)(b). | Does not find that YOU have become aware. Does not convert 'becoming aware' into 'discovery'. |
| Manufacturer becoming aware — severe-incident track | Article 14(4)(b): without undue delay and in any event within 72 hours of the manufacturer becoming aware of the incident. | Legal requirement — Article 14(4)(b). | Does not paste a GDPR Article 33 awareness test onto Article 14. |
| Same start as the 24-hour early warning | Article 14(2)(a) and Article 14(4)(a) also run from the manufacturer becoming aware. The 24-hour band and the 72-hour band are not averaged into one number. Filing the early warning does not restart 72 hours. | Legal requirement of both limbs. A dedicated 24-hour early-warning guide is not on this site yet. Naming it is not a link. | Does not start 24 hours. Does not treat the early warning as discharging the 72-hour notification. |
| Recorded awareness in the signed-in ladder | The product tracks a human-recorded aware-at for findings the organisation classified as CRA-in-scope. 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 awareness. |
| ENISA SRP 72-hour counter | ENISA SRP FAQ 26 (updated 8 September 2026) states that, in the current release, the 72-hour counter displays a due date/time 48 hours after submission of the 24-hour early warning, and that this logic will be updated in a future release to use the date/time of becoming aware. FAQ 26 also states those counters do not replace the Article 14 obligation to report upon becoming aware. | Agency guidance / platform counter — not Article 14. | Does not treat the platform's 48-hours-after-early-warning display as the statutory 72-hour clock. |
Delta versus the 24-hour early warning
The 72-hour notification is not the 24-hour early warning. Article 14(2)(a) and Article 14(4)(a) are a different limb. A dedicated 24-hour early-warning guide is not on this site yet. Naming it is not a link. Last verified 8 September 2026. Not legal advice.
| Point | 24-hour early warning | 72-hour notification | Kind of text |
|---|---|---|---|
| Paragraph | Article 14(2)(a) or 14(4)(a). | Article 14(2)(b) or 14(4)(b). | Legal requirement — different points of Article 14. |
| Clock-start | The manufacturer becoming aware. | The manufacturer becoming aware — the same event, not a later start. | Legal requirement. This page does not start either band. |
| Unless already provided | Not in those words in Article 14(2)(a) or 14(4)(a). | Article 14(2)(b) and 14(4)(b) open with 'unless the relevant information has already been provided'. That clause does not delete the 72-hour limb. | Legal requirement. This page does not find that YOUR early warning already provided the 72-hour content. |
| Statutory content — actively exploited track | Article 14(2)(a): indicating, where applicable, the Member States on the territory of which the manufacturer is aware that their product with digital elements has been made available. | Article 14(2)(b): general information, as available, about the product; the general nature of the exploit and of the vulnerability; corrective or mitigating measures taken; measures users can take; and, where applicable, sensitivity. | Legal requirement. Do not blend the two limbs. |
| Statutory content — severe-incident track | Article 14(4)(a): including at least whether the incident is suspected of being caused by unlawful or malicious acts, and Member States where applicable. | Article 14(4)(b): general information, where available, about the nature of the incident; an initial assessment of the incident; measures taken; measures users can take; and, where applicable, sensitivity. | Legal requirement. An initial assessment is a 72-hour field on this track, not a 24-hour statutory minimum. |
| Not this page | The 24-hour early warning is a different rung. A dedicated 24-hour guide is not on this site yet. Naming it is not a link. | This page. Not the 14-day actively-exploited final report (Article 14(2)(c)) and not the one-month severe-incident final report (Article 14(4)(c)). A dedicated final-report guide is not on this site yet. Naming it is not a link. | This page does not file either rung. |
This 72 hours is not GDPR Article 33
A GDPR Article 33 72-hour notice is a different instrument, with a different start and a different recipient. Filing a GDPR notice does not discharge CRA Article 14. Filing a CRA 72-hour notification does not discharge GDPR. The GDPR breach-notification guide on this site is Articles 33–34. Last verified 8 September 2026. Not legal advice.
- Do not paste EDPB Guidelines 9/2022's 'reasonable degree of certainty' awareness discussion onto Article 14. Those guidelines are regulator guidance on GDPR, not the CRA.
- Do not treat a 72-hour DPA portal filing as a CRA Single Reporting Platform filing. The live GDPR page on this site is /docs/breach-reporting/gdpr.
| Point | CRA Article 14(2)(b) / 14(4)(b) | GDPR Article 33(1) | Kind of text |
|---|---|---|---|
| Instrument | Regulation (EU) 2024/2847 — Cyber Resilience Act. | Regulation (EU) 2016/679 — GDPR. | Two regulations. Not one 72-hour rule. |
| Who | Manufacturer of a product with digital elements (Article 3(13)), if the CRA applies. | Controller of personal data, if GDPR applies. A processor notifies the controller without undue delay (Article 33(2)) — that is not a 72-hour DPA filing. | Legal requirement of each instrument. This page does not classify YOU. |
| Trigger | An actively exploited vulnerability contained in the product, or a severe incident having an impact on the security of the product. | A personal data breach, unless unlikely to result in a risk to the rights and freedoms of natural persons. | Legal requirement of each instrument. CRA Article 14 does not copy GDPR's risk exception. |
| Clock-start words | The manufacturer becoming aware of the actively exploited vulnerability, or of the incident. Article 14(2)(b) and 14(4)(b). | After having become aware of it — the personal data breach. Article 33(1). | Legal requirement of each instrument. This page does not paste GDPR awareness onto Article 14. |
| Recipient | The CSIRT designated as coordinator and ENISA, via the single reporting platform (Articles 14(7) and 16). | The supervisory authority competent in accordance with Article 55. | Legal requirement. A DPA is not a CSIRT designated as coordinator, and ENISA is not a GDPR supervisory authority for Article 33. |
| Discharge | Filing a CRA 72-hour notification does not discharge GDPR Article 33. | Filing a GDPR Article 33 notice does not discharge CRA Article 14. | Two duties, two files. Counsel maps YOUR facts to each instrument. |
Recipients — CSIRT designated as coordinator and ENISA
Article 14(1) and Article 14(3): simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7, and to ENISA, via the single reporting platform established pursuant to Article 16. Article 14(7): the notifications referred to in paragraphs 1 and 3 of this Article shall be submitted via the single reporting platform referred to in Article 16 using one of the electronic notification end-points referred to in Article 16(1). The notification shall be 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 shall be simultaneously accessible to ENISA. Last verified 8 September 2026. Not legal advice.
Article 16(1): for the purposes of the notifications referred to in Article 14(1) and (3) and Article 15(1) and (2) and in order to simplify the reporting obligations of manufacturers, a single reporting platform shall be established by ENISA. That is the legal requirement. ENISA's SRP FAQ (updated 8 September 2026) is agency guidance on that platform, not the regulation. ENISA FAQ 15 (guidance) states that no API will be provided at the initial release.
Required-content checklist — statute versus ENISA platform fields
The statutory minimum of the 72-hour notification is what Article 14(2)(b) and Article 14(4)(b) name. ENISA's SRP FAQ 16 table (updated 8 September 2026) lists additional platform fields at the 72-hour step. Those extra fields are agency guidance, not the regulation. Last verified 8 September 2026. Not legal advice. This table is not YOUR filing.
| Field | What the cited text says | Kind of text | What this page does not do |
|---|---|---|---|
| Recipients | Simultaneously to the CSIRT designated as coordinator and to ENISA, via the single reporting platform. | Legal requirement — Articles 14(1), 14(3), 14(7) and 16. | Does not name YOUR CSIRT. Does not submit. |
| Timing | Without undue delay and in any event within 72 hours of the manufacturer becoming aware of the actively exploited vulnerability, or of the incident. | Legal requirement — Article 14(2)(b) or 14(4)(b). | Does not start that 72 hours. Does not round 72 hours to three days. |
| General information about the product (actively exploited track) | Article 14(2)(b): general information, as available, about the product with digital elements concerned. | Legal requirement — Article 14(2)(b). | Does not inventory YOUR product. |
| General nature of the exploit and of the vulnerability | Article 14(2)(b): the general nature of the exploit and of the vulnerability concerned. | Legal requirement — Article 14(2)(b). Not an Article 14(2)(a) field. | Does not invent a CVE as the trigger. |
| Nature of the incident and initial assessment (severe-incident track) | Article 14(4)(b): general information, where available, about the nature of the incident, an initial assessment of the incident. | Legal requirement — Article 14(4)(b). An initial assessment is not named in Article 14(2)(b). | Does not write YOUR initial assessment. |
| Corrective or mitigating measures taken, and measures users can take | Article 14(2)(b) and Article 14(4)(b): any corrective or mitigating measures taken, and corrective or mitigating measures that users can take. | Legal requirement — both 72-hour limbs. | Does not decide that a measure is available. Measure availability starts the 14-day final-report limb on the actively-exploited track (Article 14(2)(c)), which is not this page. |
| Sensitivity of the notified information (where applicable) | Article 14(2)(b) and Article 14(4)(b): which shall also indicate, where applicable, how sensitive the manufacturer considers the notified information to be. Recital 71 discusses why that indication exists. Recital 71 is a recital, not an operative article. | Legal requirement — Article 14(2)(b) and 14(4)(b), where applicable. | Does not find that YOUR notification is sensitive. Does not invoke particular exceptional circumstances for YOU. |
| Notification type, notification level, title, summary, manufacturer name, product name, product version | ENISA SRP FAQ 16 table lists these as required at the 24-hour early warning and then copied or updated at the 72-hour notification. FAQ 16 also lists date/time when you become aware as required on each track at the early-warning step and copied forward. | Agency guidance — ENISA SRP FAQ 16 (updated 8 September 2026), not Article 14(2)(b) or 14(4)(b). | Does not treat an ENISA required-field mark as rewriting Article 14(2)(b) or 14(4)(b). |
| Corrective or mitigating measures taken / that users can take — FAQ 16 | ENISA SRP FAQ 16 marks these Required at the 72-hour notification (optional at the 24-hour early warning). That required mark lines up with the Article 14(2)(b) and 14(4)(b) statutory words. | Agency guidance aligning with a legal requirement. The article is still the article. | Does not treat the FAQ table as a substitute for the article. |
| General information / nature of incident / initial assessment — FAQ 16 | ENISA SRP FAQ 16 marks 'General information' Required at 72 hours on the actively-exploited track, and 'General information about nature of incident' plus 'Initial assessment of the incident' Required at 72 hours on the severe-incident track. | Agency guidance aligning with Article 14(2)(b) and 14(4)(b). | Does not invent extra statutory fields from the FAQ. |
| Considered sensitivity of information — FAQ 16 | ENISA SRP FAQ 16 marks this Required if such information available at the 72-hour notification (optional at 24 hours). | Agency guidance aligning with 'where applicable' in Article 14(2)(b) and 14(4)(b). | Does not treat a platform 'required if available' mark as deleting 'where applicable'. |
| Particular Exceptional Circumstances (PEC) and PEC Delay Reason | ENISA SRP FAQ 16 lists PEC and PEC Delay Reason as optional at the 72-hour notification only (N/A at 24 hours and at the final report). FAQ 21 discusses Article 16(2) delay grounds. Article 16(2) is not Article 14(2)(b). | Agency guidance on a different article. Commission Delegated Regulation (EU) 2026/881 specifies delay terms — not Article 14 itself. | Does not find that YOUR notification meets a delay ground. |
| CVE ID, EUVD ID, attack vector, product class | ENISA SRP FAQ 16 table lists these as optional at the 72-hour notification. | Agency guidance — ENISA SRP FAQ 16. Not the statutory minimum. | Does not invent a CVE as the Article 14(2)(b) trigger. |
Worked timing example — illustration, not YOUR clock
The table below is an illustration. It uses a hypothetical recorded-awareness instant. It is not YOUR clock. It is not a determination that anyone has become aware. It does not start 72 hours. Last verified 8 September 2026. Not legal advice.
| Instant (illustration) | What it represents | Kind of text | What this page does not do |
|---|---|---|---|
| 15 September 2026, 09:00 UTC | A hypothetical recorded-awareness instant after Article 14 applies (Article 71(2): Article 14 shall apply from 11 September 2026). | Illustration — not a filing, not a finding. | Does not find that YOU became aware at this instant. Does not start the statutory clock. |
| 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 72-hour notification. | Illustration of the 24-hour band — not a due-date for YOU. A dedicated 24-hour guide is not on this site yet. Naming it is not a link. | Does not file an early warning. Does not treat that filing as restarting 72 hours. |
| 18 September 2026, 09:00 UTC | Seventy-two hours later than that hypothetical instant. Article 14(2)(b) and 14(4)(b) say without undue delay and in any event within 72 hours of the manufacturer becoming aware. That is not three calendar days rounded, and it is not 48 hours after the early warning. | Illustration of the statutory 72-hour band — not a due-date for YOU. | Does not file a 72-hour notification. Does not run a countdown widget. Does not treat ENISA FAQ 26's 48-hours-after-early-warning counter as this instant. |
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 3(42), 14(1), 14(2)(b), 14(3), 14(4)(b), 14(5), 14(7), 16, 71(2) | Legal requirement — the regulation, only if it applies. | Does not apply those articles to YOU. |
| Regulation (EU) 2016/679 Article 33 | A different legal requirement — GDPR. Not Article 14. | Does not paste Article 33 onto Article 14. Filing one does not discharge the other. |
| European Commission CRA reporting page | Commission materials. Guidance, not the regulation. | Does not treat a Commission summary as a substitute for Article 14(2)(b) or 14(4)(b). |
| ENISA Single Reporting Platform FAQ (updated 8 September 2026), SRP Glossary, 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)(b) and 14(4)(b) statutory minimum. FAQ 26 describes a 72-hour counter that currently displays 48 hours after the early warning — not the statutory clock. | Does not treat an ENISA required-field mark as the article. Does not treat the platform counter as Article 14(2)(b). |
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 GDPR breach-notification guide on this site is Articles 33–34. 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.
- Awareness (UTC): the minute the organisation currently records as the manufacturer becoming aware, in Article 14's words. Do not treat reading this page as becoming aware. An in-scope mark is not awareness. Do not paste GDPR awareness onto that minute.
- Notification: 72 hours from becoming aware — Article 14(2)(b) or 14(4)(b). Recipients: the CSIRT designated as coordinator and ENISA via the single reporting platform. Same start as the 24-hour early warning. Do not round 72 hours to three days.
- Statutory content: product / exploit / vulnerability, or nature of the incident plus initial assessment; measures taken; measures users can take; sensitivity where applicable. ENISA FAQ 16 extra fields are guidance.
- Is this a GDPR Article 33 notice? No. Different instrument, different start, different recipient. Filing GDPR does not discharge CRA.
- Is this the 24-hour early warning? No. The CRA-cluster Article 14 overview on this site is the cluster reporting page. The ENISA-workflow guide on this site is the platform-flow page. A dedicated 24-hour and final-report guide is not on this site yet. Naming them is not a link.
- Document the assessment, including a no-notification 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 72-hour stage from recorded awareness 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 awareness is a human determination the platform must not backdate. An in-scope mark is not awareness. A KEV match timestamp is disclosure, not the 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 awareness. 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 72-hour 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 3(42), 14(1), 14(2)(b), 14(3), 14(4)(b), 14(5), 14(7), 16 and 71(2), is a legal requirement only if it applies. Article 14 applies from 11 September 2026 (Article 71(2)). Regulation (EU) 2016/679 Article 33 is a different instrument. 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, 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 CRA Article 14 reporting guide on this site is the live ladder. The GDPR breach-notification guide on this site is Articles 33–34. 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 CRA-cluster Article 14 overview on this site is the cluster reporting page. The ENISA-workflow guide on this site is the platform-flow page. A dedicated 24-hour early warning and final-report guide is not on this site yet. Naming them is not a link.
Frequently asked questions
Is this legal advice?
No. It is a second-rung guide distilled from Regulation (EU) 2024/2847 Articles 14(2)(b) and 14(4)(b), with ENISA Single Reporting Platform materials labelled as guidance, not the regulation. Whether the CRA applies, whether you have become aware, 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 72h notification?
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 72-hour stage from recorded awareness for findings the organisation classified as CRA-in-scope. A named human still submits.
Is this GDPR 72h?
No. GDPR Article 33(1) is a controller notice to a supervisory authority, from having become aware of a personal data breach, under Regulation (EU) 2016/679. CRA Article 14(2)(b) and 14(4)(b) are a manufacturer notification to the CSIRT designated as coordinator and to ENISA via the single reporting platform, from the manufacturer becoming aware of an actively exploited vulnerability or a severe incident, under Regulation (EU) 2024/2847. Different instrument, different start, different recipient. Filing GDPR does not discharge CRA.
Is this the 24h early warning?
No. Article 14(2)(a) and Article 14(4)(a) are the 24-hour early warning from becoming aware. Article 14(2)(b) and Article 14(4)(b) are the 72-hour notification from the same becoming-aware event, unless the relevant information has already been provided. Those two marks are not averaged. A dedicated 24-hour early-warning guide is not on this site yet. Naming it is not a link.
Does the product's 72h ladder start the statutory clock?
No. The signed-in Compliance → CRA reporting tracker runs the 72-hour stage from recorded awareness for findings the organisation classified as CRA-in-scope actively exploited. Recorded awareness is a human determination the platform must not backdate. Opening the ladder, classifying a finding as CRA-in-scope, or reading this page does not start the Article 14 clock. An in-scope mark is not awareness.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.