Article 14, step by step: from "we became aware" to the final report

Article 14 of the Cyber Resilience Act (Regulation (EU) 2024/2847) is the part of the law that already applies. Since 11 September 2026 a manufacturer of a product with digital elements must report two kinds of event to the authorities on a fixed clock (Article 71(2), EUR-Lex text checked 8 October 2026). This guide walks the clock from the moment you become aware to the final report. It is a documentation aid, not legal advice.

Does this apply to products already on the market?

Yes. Article 69(3) applies the Article 14 obligations to every in-scope product placed on the market before 11 December 2027. A device you shipped in 2024 is covered today.

Reporting also continues after the support period ends. The Commission's guidance (C(2026) 5252, Annex, point 210; a draft, not yet formally adopted and not binding: its point 8) says: "unlike the vulnerability handling obligations, which continue only for the length of a product's support period, the reporting obligations continue to apply after a product with digital elements is no longer supported." Our reading of that (argument): an actively exploited vulnerability in a product you no longer support is still one you report.

What happened before 11 September 2026

Article 14 has applied since 11 September 2026 (Article 71(2)). The Commission's guidance (C(2026) 5252, Annex, point 217; a draft, not yet formally adopted and not binding: its point 8) reads that start date in two halves:

• Exploitation you already knew of before that date is not reported. The guidance says "the manufacturer is not required to report vulnerabilities of whose active exploitation it had already become aware before 11 September 2026", and that the CRA "does not require the retroactive reporting of such vulnerabilities".
• A vulnerability you already knew of, whose exploitation you learn of afterwards, is reported. The duty "does apply where the manufacturer was aware of a vulnerability before 11 September 2026 but was not, at that time, aware of any active exploitation of it". If exploitation happens after that date, or you become aware of it after that date, "the vulnerability is deemed an actively exploited one subject to the reporting obligation". Our reading (argument): the clock then runs from when you become aware of the exploitation, as it does for any other.

Point 217 speaks of actively exploited vulnerabilities only. It does not say the same of a severe incident you became aware of before 11 September 2026, and we do not stretch it to cover one (argument).

The two things you report

An actively exploited vulnerability. The CRA defines it as "a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner" (Article 3(42)). Our reading (argument): a theoretical flaw, or a proof of concept nobody has used against a real system, is not one; a flaw you learn is being used in the wild is.

A flaw found in good faith is not one. Recital 68 (law, as an aid to reading Article 14): vulnerabilities "discovered with no malicious intent for purposes of good faith testing, investigation, correction or disclosure" should not be subject to mandatory notification. The Commission's FAQ (version 1.4, §5.2; guidance, not binding) gives two examples: a zero-day reported to you through your bug-bounty programme, and one found by a lab testing the product for you, are not actively exploited vulnerabilities when there is no evidence that anyone exploited them maliciously. You may still report them voluntarily (Article 15). ENISA's platform does not accept voluntary reports yet: its FAQ calls voluntary reporting a future phase of the platform (ENISA guidance, not law; SRP FAQ questions 6 and 27, page updated 3 October 2026). A zero-day that a malicious actor has exploited is reportable even though no patch exists yet (FAQ §5.2).

A vulnerability in a component you build in. Article 14(1) covers any actively exploited vulnerability "contained in the product", and a component is part of it. The Commission's FAQ (§5.4; guidance, not binding) reads it this way: where the exploited vulnerability comes from an integrated component, you as the product's manufacturer notify it, and the component's own manufacturer notifies it too if that component was placed on the market. If the component's vulnerability cannot be exploited in your product, it is not actively exploited in your product and mandatory reporting does not apply. The Commission's guidance (C(2026) 5252, Annex, point 218; a draft, not yet formally adopted and not binding: its point 8) names two cases, not one: where you are aware that a third-party component contains a vulnerability, but it "either (i) cannot be exploited in its product with digital elements (e.g. because the vulnerable code is not reachable) or (ii) has not been exploited in its product with digital elements", it "does not qualify as an actively exploited vulnerability contained in its product with digital elements" and is not subject to mandatory reporting for you. In both cases you may notify it voluntarily (Article 15), and you must report it to whoever manufactures or maintains the component (Article 13(6)); point 218 adds that the vulnerability handling requirements of Annex I Part II still apply to it. The platform cannot take a voluntary report yet; see "A flaw found in good faith is not one" above.

A severe incident having an impact on the security of the product (Article 14(3) and (5)). In short: an incident that harms or could harm the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led or could lead to malicious code being introduced or run in the product or in a user's systems.

Where the reports go

Every report goes through ENISA's Single Reporting Platform (SRP), at the same time to the CSIRT designated as coordinator and to ENISA (Article 14(1) and (3)). The CSIRT is the one in the Member State of your main establishment in the EU; the CRA treats that as the place where decisions about the cybersecurity of your products are predominantly taken (Article 14(7); ENISA FAQ). Article 14(7) also sets the order to follow when you have no main establishment in the EU.

What the platform does (law): ENISA establishes and runs the single reporting platform "in order to simplify the reporting obligations of manufacturers" (Article 16(1)). You submit each notification once, through the electronic notification end-point of the CSIRT designated as coordinator for you (Article 14(7); it calls them the end-points "referred to in Article 16(1)"), and that one submission reaches both the CSIRT and ENISA (Article 14(1) and (3)).

Four platform facts from ENISA's FAQ (ENISA guidance, not law) shape how you prepare:

• Submissions are made by an Assigned Representative with an EU Login account with multi-factor authentication. There is one Primary Assigned Representative per manufacturer and up to 20 Secondary ones (question 9).
• There is no API at launch; notifications are entered in the platform's web interface (question 15).
• The platform is available in English only at launch (question 24; ENISA guidance, not law). Our advice (argument): prepare the text of every report in English. The FAQ does not say which language the fields must be written in.
• The platform shows no counter for the final report of an actively exploited vulnerability, because that deadline depends on when a corrective or mitigating measure becomes available (question 26; ENISA guidance, not law). Our reading (argument): the FAQ says the platform's reminder emails and overdue alerts work from its counters, so expect none for this report. Your own record of when the fix became available is the only clock.

Our advice (argument): the people, their EU Login accounts and their MFA devices should exist before the first incident, not during it. The FAQ (question 9) says an EU Login account can be created in advance. On when to register with the platform itself, the FAQ advises waiting until you have something to report; step 1 of "Preparing before the first report" sets both out.

The clock

The clock starts when you become aware. Article 14 does not define that moment. The Commission's guidance on applying the CRA (C(2026) 5252, Annex, section 9.1) says how the Commission reads it. That guidance is a draft: its content was approved on 27 July 2026, it is not yet formally adopted, and it is not binding (its point 8).

A first assessment, then a reasonable degree of certainty (point 213 of the draft, non-binding guidance). When you detect a suspicious event, or a customer, an authority, the press or anyone else brings one to your attention, the manufacturer "should assess the suspicious event immediately". It is then "to be regarded as having become aware when, after such an initial assessment, it has a reasonable degree of certainty that: (i) a vulnerability contained in its product with digital elements is being actively exploited; or (ii) a severe incident has occurred and has led to the security of its product with digital elements being compromised." In plain words (our reading, argument): the clock does not start at the first unchecked report, and it does not wait until you are sure beyond doubt. It starts when your first look leaves you reasonably certain.

The first assessment is not spare time (point 214 of the same draft, non-binding guidance). How long it takes depends on the case: sometimes it is clear from the outset, and sometimes it takes time to establish that your product is affected and that a malicious actor is exploiting the flaw. Either way, "the emphasis should be on prompt action to carry out the initial assessment", particularly where the vulnerability may pose a significant risk.

Our advice (argument): record the moment in UTC with the evidence that made you aware, because the 24-hour and 72-hour deadlines are counted from it. Record also when a fix or mitigation became available and when you submitted the notification, because the two final reports are counted from those (Article 14(2)(c) and (4)(c)). Record when the first assessment started too (argument, ours; the guidance does not ask for it): that time and the moment of awareness together show how promptly you assessed, which is where point 214 puts the emphasis.

Hour 0 to 24: early warning

Due without undue delay and in any event within 24 hours of becoming aware, for both kinds of event (Article 14(2)(a) and (4)(a)). The hours are the outer limit, not the time you are given: the article asks for the early warning without undue delay, and 24 hours is the point past which it is late in any event.

• For an exploited vulnerability it states, where known, the Member States where the product has been made available.
• For a severe incident it also states whether the incident is suspected of being caused by unlawful or malicious acts.

Keep it short. The early warning exists to be fast, not complete.

Platform down? See "If the platform is down" below; the deadline keeps running.

Hour 24 to 72: notification

Due without undue delay and in any event within 72 hours of becoming aware, unless the information has already been provided (Article 14(2)(b) and (4)(b)). Here too the 72 hours are the outer limit, not the time you are given.

• For an exploited vulnerability: general information about the product concerned, the general nature of the exploit and of the vulnerability, any corrective or mitigating measures taken, measures users can take, and how sensitive you consider the information you are notifying.
• For a severe incident: the nature of the incident, an initial assessment, corrective or mitigating measures taken and those users can take, and how sensitive you consider the information.

The platform's 72-hour counter is not the legal clock (ENISA guidance, not law; SRP FAQ question 26, page updated 3 October 2026). The legal deadline is 72 hours after you became aware (Article 14(2)(b) and (4)(b)). The platform does not count from there: in its current release the 72-hour counter shows a due time 48 hours after the early warning was submitted. The two agree only when the early warning went in at exactly hour 24.

• Early warning submitted after hour 24 (already past its own deadline): the platform shows more time than the law gives. Submitted at hour 30, the counter runs to hour 78; the legal deadline is still hour 72.
• Early warning submitted before hour 24: the platform shows less time than the law gives. The FAQ says a notification "may be displayed as overdue before 72 hours have elapsed" since you became aware.

Count from when you became aware, not from the platform's counter. The FAQ says the counters give visibility and "do not replace" the manufacturer's responsibility to report within the Article 14 timelines, and that a future release will count from the time you became aware. Our reading (argument): the FAQ says the platform's reminder emails and overdue alerts work from this counter, so when the counter runs past hour 72 the overdue alert comes after the legal deadline has already passed.

Platform down? See "If the platform is down" below; the deadline keeps running.

In between: an intermediate report, if asked

Where necessary, the CSIRT that first received your notification may ask you for an intermediate report on relevant status updates (Article 14(6)). It is not a fixed stage with its own clock; it comes only on request. Article 14(6) does not say how the request reaches you or how you answer it, and ENISA's FAQ does not mention intermediate reports (read 11 October 2026). Our advice (argument): answer the way the CSIRT asks you to, and keep the final-report deadline in view, because the request does not move it (argument: Article 14(6) sets no new deadline).

The final report

The deadline depends on the kind of event (Article 14(2)(c) and (4)(c); ENISA FAQ):

• Actively exploited vulnerability: no later than 14 days after a corrective or mitigating measure is available (Article 14(2)(c)), and never before the 72-hour notification deadline (a fix can predate the moment you became aware). The floor is our reading (argument), not text of the Article: a fix, often upstream's, can exist before you knew the flaw was being exploited, 14(2)(c) does not say what happens then, and we do not read it as putting a report overdue before the duty to send it began. It describes the vulnerability with its severity and impact, any information about the malicious actor, and the security update or other measure made available.
• Severe incident: within one month after the incident notification was submitted. It gives a detailed description with severity and impact, the type of threat or root cause that likely triggered it, and the mitigation applied and ongoing.

Note the difference. The vulnerability final report has no date until a fix or mitigation exists; the incident final report runs from the notification, not from awareness.

How we count (argument): we count 14 days and one month to the same clock time, on whichever of the UTC calendar and your own ends earlier, so the date we show is never later than the Article allows. The one exception is the floor above: when a fix predates the moment you became aware, the date we show is the notification deadline, later than a literal reading of 14(2)(c) gives.

Like the notification, neither final report is owed again for information you have already provided: Article 14(2)(c) and (4)(c) carry the same "unless the information has already been provided" proviso. It excuses repeating what the CSIRT and ENISA already have, not the report itself.

Platform down? See "If the platform is down" below; the deadline keeps running.

If the platform is down

What ENISA says (ENISA guidance, not law; SRP FAQ question 25, read 11 October 2026): you report through the platform, and if it is temporarily unavailable you wait until it is back and then submit. If you judge that the CSIRT needs to hear from you sooner, you may contact your designated CSIRT directly. You still submit through the platform once it is back.

Our reading (argument): every deadline above keeps running while you wait. Article 14 sets them with no exception for the platform being unavailable, and the FAQ gives no extra time. The note of when you tried is your own record of what happened. Neither the CRA nor the FAQ says it makes a late report on time.

It has happened once already (evidence): by one published account, the platform had deployment problems on its first day, 11 September 2026, and was back within a few hours (Aikido Security, 23 September 2026).

Tell your users

Article 14(8) requires the manufacturer, after becoming aware, to inform the impacted users, and where appropriate all users, of the vulnerability or incident and, where necessary, of risk mitigation and corrective measures they can deploy. This duty is separate from the reports to the CSIRT and ENISA. Our reading (argument): a security advisory on your site and a message through your app or update channel are the usual routes. Annex I Part II(4) and (8) describe what an advisory should contain once a fix exists.

Informing users need not mean telling the public. The Commission's guidance (C(2026) 5252, Annex, points 220 and 221; a draft, not yet formally adopted and not binding: its point 8) reads Article 14(8) as a duty "to be applied in a risk-based and proportionate manner". Giving users the information "does not imply that such information must be made public or disclosed indiscriminately". Depending on the product, the users affected and the possible impact, manufacturers "may limit the disclosure of detailed information to the relevant users or customers concerned"; the guidance says this holds particularly for products used in sensitive or essential environments, where publishing technical details could itself raise the risk or help further exploitation. Once the vulnerability has been adequately addressed or mitigated, "broader disclosure may be appropriate" (point 221), with the detail and the timing kept proportionate to the risk that remains.

The public advisory for a fixed vulnerability is a separate duty under a different provision. Annex I Part II(4) (law; it applies with the rest of the CRA from 11 December 2027) requires manufacturers, once a security update has been made available, to share and publicly disclose information about fixed vulnerabilities; point 221 of the guidance recalls it. Our reading (argument): limiting who receives the detail while the event is live does not replace that later public disclosure.

A note for small companies

Article 64(10)(a) says the administrative fines do not apply to a manufacturer that qualifies as a micro or small enterprise for a failure to meet the 24-hour early-warning deadline (Article 14(2)(a) or (4)(a)). It reaches the fine for breaching Article 14, which is set in paragraph 2, because since the corrigendum of 2 July 2025 (Official Journal L 2025/90555) Article 64(10) opens "By way of derogation from paragraphs 2 to 9"; earlier printings read "paragraphs 3 to 9", and a copy that says so predates the correction. Recital 120 sits beside it: given that those fines do not apply, Member States "should not impose other kinds of penalties with pecuniary character" on those entities either. A recital explains how the article is to be read; it is not a rule of its own. The relief is from the fine and, by recital 120, other money penalties for lateness, not from the duty: send the early warning on time all the same. It covers that one deadline alone: the 72-hour notification and the final report have no such relief, and medium-sized companies have none at all.

Preparing before the first report

1. Name the people. Choose the Primary Assigned Representative and at least one Secondary, create their EU Login accounts with MFA, and register on the SRP. Registering takes time at the CSIRT's end: your designated CSIRT validates each representative's link to your company, and ENISA's FAQ (question 9) says the procedure and how long it takes vary from CSIRT to CSIRT. The one published account we know of reports three business days with Belgium's CSIRT (Aikido Security, 23 September 2026). That is one company's experience, not a published service level. ENISA's FAQ adds that a representative can submit while validation is pending, for up to 20 notifications, so the wait need not stop a report; the account itself must exist first. The same answer advises manufacturers to register and start validation "only when they need to submit a notification", to limit the CSIRTs' workload, and says registering takes a few minutes once the EU Login account exists. Our advice (argument): create the EU Login accounts and set up MFA now, which costs the CSIRT nothing; registering on the platform ahead of a first report goes against that advice, so weigh it against how much a 24-hour deadline leaves you. Aikido's account also reports that the platform supports passkey sign-in and advises registering a few backup devices so nobody is locked out.
2. Decide who decides. Write down who judges whether an event is an actively exploited vulnerability or a severe incident, and who can approve a submission at a weekend.
3. Keep the product facts ready. Product names and versions, the Member States where each product is sold, and current SBOMs; the early warning asks where the product has been made available.
4. Write the user notice template now, so Article 14(8) does not wait for a copywriter.
5. Rehearse once. Walk a fictional event through the three stages and time it.

The timeline on one screen

Stage	Exploited vulnerability	Severe incident
Early warning	24 h after awareness	24 h after awareness
Notification	72 h after awareness	72 h after awareness
Final report	14 days after a fix or mitigation is available, never before the 72-hour notification deadline	1 month after the notification is submitted
Inform users	Article 14(8)	Article 14(8)

These are the legal deadlines, except the vulnerability final report's floor at the notification deadline, which is our reading (see "The final report"). Every "after awareness" figure in the table is an outer limit rather than a target: Article 14(2) and (4) ask for the early warning and the notification "without undue delay and in any event" within the hours shown. The platform's own 72-hour counter is not one of these deadlines; see "Hour 24 to 72: notification".

What is settled and what is not

Settled (law): the stages, the deadlines and the recipients above, the intermediate report on request, the date Article 14 began to apply, its reach to products already on the market, and the exclusion of the fine for a micro or small manufacturer's late early warning (Article 64(10)(a), whose opening words the corrigendum of 2 July 2025 corrected to "paragraphs 2 to 9"). Our reading (argument): the vulnerability final report's floor at the notification deadline and how we count days and months (see "The final report"); and that the duty to send the early warning stays, so the clock is best met rather than missed cheaply.

Commission guidance (not binding, and the Commission says so in the FAQ itself): the good-faith-find examples and the component rule above. Only the Court of Justice interprets the CRA authoritatively.

Commission guidance that is still a draft (C(2026) 5252, content approved on 27 July 2026, not yet formally adopted, and not binding: its point 8): the test for "becoming aware" (points 213 and 214), what happened before 11 September 2026 (point 217), the two component cases (point 218), reporting after the support period ends (point 210), and the proportionate reading of the duty to inform users (points 220 and 221). The wording may change before adoption; we re-read it when it is adopted.

Open: the platform may add an API and voluntary reporting later, and ENISA says a future release will make the 72-hour counter count from when you became aware (ENISA FAQ, questions 15, 26 and 27), and the Commission's Digital Omnibus proposal (COM(2025) 837) could merge incident-reporting entry points across EU laws. Until anything is adopted, the rules above are the ones in force; we update this guide when they change.