Updated on 3 September 2026: Article 14 obliges you to report an actively exploited vulnerability, not to patch it. We have added a clarification on what the final report actually turns on, plus a note that the handling obligation arriving in December 2027 does not reach legacy products (Article 69(2) EU CRA) while the reporting obligation does (Article 69(3)) — see “What Article 14 does not require”.
Updated on 27 July 2026: clarification of the component edge case and of the concept of awareness following the new EU Commission guidance C(2026) 5252 final (paras. 213 and 218) — we have summarised every chapter of the guidance in our overview. Thanks to the discussion on LinkedIn.
On 11 September 2026, Article 14 of the EU Cyber Resilience Act (EU CRA) becomes binding. From that day on, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents: within 24 hours, with a follow-up notification after 72 hours and a final report. This applies to products that are already on the market today.
The complete reporting chain on one page. Click the graphic to open the print-ready PDF version.
Getting it wrong is expensive. Violations of the reporting obligation carry fines of up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher. That puts Article 14 in the EU CRA's highest penalty bracket.
The good news: preparation is manageable once you know exactly what is being asked. This article walks through Article 14 paragraph by paragraph and maps every obligation to an action you can implement with the resources you already have. By the end, you will know what needs to be in place by the deadline.
The short answer: what must be in place by 11 September 2026
If you take away only one list, make it this one:
- Assign ownership. A named reporting owner plus a deputy, and your competent CSIRT documented.
- Compile product data. Per product: version history, the list of EU member states where it is sold, and up-to-date customer contact details kept available, so you can notify affected customers directly in an emergency.
- Build report templates. One each for the 24-hour early warning, the 72-hour notification, the final report, and user notification, so no precious time is lost drafting when it counts.
- Organise triage. One defined place where every tip lands, plus a short checklist your team uses to decide on the spot: reportable or not.
- Run one rehearsal. A dry run with a fictitious vulnerability, before it counts.
The rest of this article derives these five points from the legal text: what Article 14 requires, what it explicitly does not require, which deadlines apply, and how the process plays out when it matters.
What Article 14 requires: two triggers, two reporting chains
Article 14 defines two reportable events:
1. Actively exploited vulnerabilities (paragraphs 1 and 2). This covers cases where a vulnerability in your product is demonstrably being exploited by attackers. The Commission guidance of 27 July 2026 (C(2026) 5252 final) clarifies in para. 218 that what counts is exploitation in your own product. If the vulnerability stems from a third-party component and is exploited in your product, you are under a reporting obligation. If it cannot be exploited in your product, or has not been exploited there, your reporting obligation falls away, even if the same vulnerability is already being actively exploited in other products. What remains is voluntary notification under Article 15 and the duty to inform the component manufacturer under Article 13(6). A published CVE on its own does not start the clock anyway. Only your awareness of active exploitation in your product does. Conversely, this creates no duty to actively search for exploitation or to monitor exploitation reports: you do not have to scan your products for it. What matters is solely your actual awareness.
2. Severe incidents (paragraphs 3 to 5). An incident counts as severe if it affects, or is capable of affecting, the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data and functions. The same applies if it has led, or is capable of leading, to the introduction or execution of malicious code in the product or in a user's system.
You report both events simultaneously to the CSIRT designated as coordinator in your member state and to ENISA. The route is the single reporting platform under Article 16, which will be live by the deadline.
What Article 14 does not require
Many manufacturers read more into Article 14 than is actually in it. None of the following is required:
- Findings from vulnerability scanners. If your scanner flags a CVE in a dependency, that is a matter for your vulnerability management process, not a report to the CSIRT and ENISA. There is no active exploitation.
- Published CVEs without exploitation in your product. Even a critical CVE with a CVSS score of 9.8 does not trigger a deadline as long as you have no knowledge that it is being actively exploited in your product. Under the Commission guidance (para. 218), that holds even if the same vulnerability is already being exploited in other manufacturers' products.
- Reports from security researchers. A responsibly disclosed vulnerability from a coordinated disclosure needs to be handled. It becomes reportable only once active exploitation is established. Watch out for one special case: if the report shows that something has already happened, say, malicious code planted in your product or a compromised build pipeline, then you are no longer looking at a mere vulnerability but at an incident under paragraph 5(b). That is reportable even without established active exploitation. Always check incoming researcher reports against both triggers.
- Results from pentests and internal audits. Vulnerabilities you find yourself remain an internal matter as long as nobody is actively exploiting them.
- Incidents below the paragraph 5 threshold. An incident with no impact on the security of the product, such as a plain availability outage of your website, does not fall under Article 14.
- A fix for the reported vulnerability. Article 14 obliges you to report, not to remediate. The final report falls due once a corrective or mitigating measure is available (paragraph 2(c)), and the article leaves open what that measure looks like. A security update satisfies it, and so does an effective countermeasure on the user side — disabling the vulnerable feature, say, or running the device only behind a firewall.
Two qualifications belong here. First, alongside the reporting obligation there is a handling obligation: under Article 13 and Annex I, manufacturers must handle vulnerabilities and provide security updates. That obligation, however, applies only from 11 December 2027 (more on both dates in the EU CRA roadmap for 2026 and 2027), and only to products placed on the market from that day onwards or substantially modified afterwards — legacy products stay outside its reach under Article 69(2) of the EU CRA. The reporting obligation under Article 14, by contrast, bites on 11 September 2026, a full 15 months earlier, and under Article 69(3) it expressly covers legacy products as well. Until 11 December 2027 the handling obligation is not backed by fines; whether you should act anyway for business reasons, think customer contracts, reputational risk, or upcoming audits, is a judgement call you have to make yourself. Second, you can always report vulnerabilities and incidents voluntarily under Article 15 if you consider it sensible.
For day-to-day practice, this means your process needs a clean verification step. Only when a scanner finding, a researcher tip, or a suspicion turns into established active exploitation or a severe incident does the 24-hour clock start.
The reporting timeline: all deadlines at a glance
| Stage | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | within 24 hours of awareness | within 24 hours of awareness |
| Detailed notification | within 72 hours of awareness | within 72 hours of awareness |
| Final report | no later than 14 days after a corrective or mitigating measure is available | within one month of the 72-hour notification |
The 24 and 72 hours are calendar hours. They keep running through weekends and public holidays. If you verify on a Friday evening, you report by Saturday evening at the latest. Plan your on-call and deputy arrangements accordingly.
Every deadline starts with your awareness. But awareness is not the moment a tip lands in your inbox. The Commission guidance of 27 July 2026 (C(2026) 5252 final) clarifies in para. 213 that a manufacturer is considered aware only when, after an initial assessment, it can assume with a reasonable degree of certainty that a vulnerability in its product is being actively exploited or that a severe incident has affected the security of the product. So you are allowed to verify a suspicion first, before the clock starts. The Commission expressly ties the concept of awareness to the EDPB Guidelines 9/2022 under the GDPR and to recital 31 of Implementing Regulation (EU) 2024/2690 under NIS2 (para. 212), so the initial assessment follows a standard many companies already know from GDPR practice.
You are not allowed to sit on that initial assessment, though (paras. 213 and 214 of the guidance). The guidance requires you to evaluate every suspicious report without delay, whether it comes from a customer, a security researcher, an authority, or the press. Dragging out verification does not push back the deadline; it invites the accusation that you became aware too late. So document the time between intake and verification without gaps: when the tip arrived, when the assessment started, when the result was in. That is the only way to demonstrate, if challenged, that your 24-hour clock started at verification and that the assessment was nonetheless prompt. This is exactly why your internal detection and escalation chain determines whether 24 hours is plenty of time or far too little.
Every Article 14 obligation, mapped to a concrete action
The table below lists every requirement in Article 14 and pairs it with the action that satisfies it. None of them requires a major project.
| Obligation (Article 14) | What is required | Your action |
|---|---|---|
| Para. 1: Reporting actively exploited vulnerabilities | Report every actively exploited vulnerability you become aware of, simultaneously to the coordinating CSIRT and ENISA, via the single reporting platform. | Appoint a reporting owner plus a deputy. Define in writing what counts as "awareness" in your organisation and who triggers the report. Set up an internal reporting channel through which support, engineering, and external reporters escalate tips to that person. |
| Para. 2(a): Early warning within 24 hours | An early warning indicating the member states in which the product has been made available. | Prepare a pre-filled template per product: product name, version, point of contact, countries of sale. Keep the per-product list of member states current, and the 24-hour report becomes a few minutes of form-filling. The ENISA FAQ on the Single Reporting Platform lists the fields required at each reporting stage in a complete field table. |
| Para. 2(b): Vulnerability notification within 72 hours | General information about the product, the nature of the exploitation and the vulnerability, corrective or mitigating measures taken, and measures users can take. Plus a sensitivity assessment, if you have made one. | Create a 72-hour template with exactly these fields. A current SBOM per product is highly advisable: it is not required for the report itself, but it makes identifying affected components within the deadline far easier. Define a short playbook: who analyses, who drafts user workarounds, who signs off. |
| Para. 2(c): Final report no later than 14 days after a corrective measure is available | A description of the vulnerability including severity and impact, information on threat actors exploiting it (where available), and information on the security update or other corrective measure provided. Important: the 14 days do not run from awareness. The clock starts only once you have completed a patch or mitigating measure. Article 14 sets no deadline for how long developing the fix may take. | Standardise your severity scoring (e.g. CVSS) and document every fix in a security advisory. Record precisely when the measure became available, because that moment starts the clock. If patch notes and advisories are part of your release process anyway, the final report is nearly finished before the deadline even begins. |
| Para. 3: Reporting severe incidents | Report every severe incident with an impact on product security, simultaneously to the CSIRT and ENISA, via the reporting platform. | Use the same reporting chain as for vulnerabilities. Add a "check EU CRA reporting duty" step to your incident response playbook, referencing the paragraph 5 criteria. |
| Para. 4(a): Early warning within 24 hours (incident) | An indication of whether the incident is suspected to be caused by unlawful or malicious acts, plus affected member states. | Make "malicious act: yes / no / unclear" a mandatory field on your initial assessment checklist. The country list you already have from the paragraph 2(a) action. |
| Para. 4(b): Incident notification within 72 hours | The nature of the incident, an initial assessment, measures taken, and measures for users. According to the ENISA reporting template, the date and time of detection and of occurrence are additional mandatory fields at this stage. | Use the same template approach as for paragraph 2(b), just with incident fields. Capture detection and occurrence timestamps in your incident record from the start. One shared form for both report types reduces mistakes under time pressure. |
| Para. 4(c): Final report within one month | A detailed description including severity and impact, the type of threat or root cause, and remediation measures taken and ongoing. | Make the post-incident review a fixed process step with a date in the calendar. If the incident has been documented in a clean timeline, the final report is an hour's work. |
| Para. 5: The "severe" threshold | The definition of when an incident is reportable (protection objectives affected, or malicious code introduced/executed). | Translate the two criteria into an internal classification matrix with examples from your own product portfolio. That way the team decides in minutes during an emergency, not in meetings. |
| Para. 6: Interim report on CSIRT request | The CSIRT can request status updates. | Maintain a running case timeline (ticket or incident record) from the first report onwards. An interim report is then an export, not a reconstruction. |
| Para. 7: Determining the competent CSIRT | You report to the CSIRT of the member state of your main establishment. That is the state where cybersecurity decisions are predominantly taken. Manufacturers without an EU establishment follow a cascade via authorised representative, importer, distributor, and users. | Determine and document your competent CSIRT once, and store the reporting platform access alongside it. Nobody wants to make that decision at 2 a.m. during an incident. |
| Para. 8: Informing users | Inform affected users (or, where appropriate, all users) about the vulnerability or incident and possible countermeasures, where appropriate in a structured, machine-readable format. Otherwise the CSIRT can publish the information itself. The Commission's guidance is specific: customers with whom you have a direct relationship must be informed directly. A general public notice suffices only for the broader user base, and details may be limited to those affected, on a risk basis. | Run a two-track approach. Keep reachable customer contacts per product and prepare a notification template for directly addressing those affected. For broader machine-readable information, CSAF has established itself as the standard for security advisories. A CSAF feed alone does not replace directly notifying known affected customers. |
| Paras. 9 and 10: Delegated and implementing acts | The Commission will specify reporting formats and procedures. These obligations are addressed to the Commission, but they affect your templates. | Keep an eye on the implementing acts on format and procedure so your templates match the official format by the deadline. A specialist newsletter or a quarterly review appointment is enough. |
Often framed as an obligation, actually a recommendation: the public single point of contact through which users and security researchers can report vulnerabilities is frequently presented as if Article 14 required it from September 2026. It does not. That obligation comes from Article 13(17) (a single point of contact for users) and the coordinated disclosure policy under Annex I Part II, and both apply only from 11 December 2027. You do not have to set up a public reporting channel by 11 September 2026.
In practice, however, you will hardly be able to meet your reporting duties without one. Assessing every tip without delay presupposes that tips reach the right place at all. Without a defined intake point they end up scattered across support inboxes, get spotted too late, or are misprioritised, and that is precisely where the risk of verifying an active exploitation too late arises. Hence our clear recommendation: set up the reporting channel for 11 September 2026, even though the formal obligation only kicks in 15 months later.
The process map: from tip to closed report
Here is the complete flow when it matters. If your team knows these six phases and the preparation from the next section is done, there is never a moment where the next step is unclear.
For printing and sharing: the complete process map with all six phases, clock status, and deadlines is available as a one-page PDF.
Phase 1: Intake. The clock is not running yet. A tip arrives, whether from a security researcher, a customer, your own team, an authority, or the press. It lands in your defined reporting channel. Log the intake with a timestamp.
Phase 2: Initial assessment, without delay. The clock is not running yet, but you are under a duty to assess. Evaluate the tip immediately against both triggers:
- Neither active exploitation nor a severe incident under paragraph 5: no reporting obligation. Handle the finding as a normal vulnerability and document the decision. A voluntary report under Article 15 remains open to you.
- Active exploitation verified with reasonable certainty: vulnerability reporting chain (phases 3 to 6).
- Severe incident under paragraph 5 verified, say, planted malicious code: incident reporting chain (phases 3 to 6, with incident deadlines).
The moment of verification is your awareness. Record it with a timestamp; the clock is now running.
Phase 3: Hour 0 to 24. Early warning. Report via the single reporting platform to your CSIRT and ENISA: affected product, title, the countries of sale for vulnerabilities, the suspicion of malicious action for incidents. Your prepared template turns this into form-filling. Your technical emergency measures run in parallel.
Phase 4: Hour 24 to 72. Detailed notification. Submit the analysis: the nature of the vulnerability or incident, an initial assessment, measures taken, workarounds for users. From this point paragraph 8 applies as well: inform known affected customers directly and the broader user base via an advisory, as soon as this is possible without creating additional risk.
Phase 5: Develop the fix. No statutory deadline, but documented. Develop the patch or the mitigating measure. Article 14 sets no deadline for this. Record the moment the measure becomes available, because that starts the final clock.
Phase 6: Final report. For vulnerabilities, no later than 14 days after the measure becomes available; for incidents, within one month of the 72-hour notification. Your case timeline and the security advisory provide the content. Publish the advisory, machine-readable as CSAF where appropriate.
Throughout, from phase 1 to 6: document. Every step with a timestamp in the case timeline. That lets you answer CSIRT interim report requests with an export, and prove at any time what you knew and did, and when.
What this looks like in real life: a worked example
A fictitious but realistic case at a manufacturer of IoT gateways:
Tuesday, 2:32 p.m. A security researcher reports a vulnerability in your gateway's remote maintenance module through your reporting channel. He includes logs from one of your customers that point to ongoing exploitation. The intake is logged with a timestamp; the reporting owner is notified.
Tuesday, 3:10 p.m. The initial assessment begins. Your team reproduces the vulnerability and examines the logs. Start of assessment documented.
Wednesday, 9:40 a.m. The analysis confirms it: the vulnerability is being actively exploited. This is your awareness, documented with a timestamp. The clock is running; the early warning is due by Thursday, 9:40 a.m.
Wednesday, 4:05 p.m. The early warning goes to your CSIRT and ENISA via the single reporting platform, with product, title, and countries of sale from your prepared template. About 17 hours of buffer go unused, because the template was ready.
Friday, 8:30 a.m. The detailed notification goes out, comfortably within the 72-hour deadline: nature of the vulnerability, initial assessment, one workaround (disable the remote maintenance module). In parallel, you inform the known affected customers directly.
Nine days later. The patch is tested and available. The moment is documented; the 14-day clock for the final report starts now.
Three days after that. Final report submitted, security advisory published as CSAF. The case is closed, and the complete timeline sits there with timestamps.
The decisive point about this example: between the intake on Tuesday and the start of the deadline on Wednesday lie 19 hours of assessment time, cleanly documented. Without that documentation, it would look in hindsight as though the clock had started on Tuesday and the early warning had been an hour and a half late.
Preparation in five steps
Work through the table above and this roadmap to 11 September 2026 practically writes itself:
- Assign ownership. Reporting owner plus deputy, competent CSIRT documented. Set up your access to the reporting platform by 11 September 2026 at the latest, when the platform goes live. ENISA will publish the registration instructions in advance.
- Compile product data. Per product: version history, the list of member states, customer contacts. Plus a current SBOM: Article 14 does not require one (it only becomes mandatory from December 2027 via Annex I), but without it you will struggle to work out which products are affected by a component vulnerability within the deadlines. The SBOM guide shows how to build one.
- Build templates. One each for the 24-hour early warning, the 72-hour notification, the final report, and user notification.
- Organise triage. A defined intake channel for tips and the paragraph 5 classification matrix, so every suspicious report can be assessed without delay. Article 14 does not require active vulnerability monitoring; it is a sensible addition and becomes part of vulnerability handling under Annex I from December 2027 anyway.
- Run one rehearsal. A tabletop exercise with a fictitious vulnerability shows you where the chain breaks, while it still costs nothing.
For most manufacturers, the effort involved amounts to a few person-days. The 24-hour deadline only becomes a problem when product data, responsibilities, and templates have to be hunted down mid-incident.
What Kunnus takes off your plate
Everything described above you can build yourself. The real work, though, is not in the building but in the running: keeping templates current, documenting every case cleanly, keeping deadlines in view, permanently from 11 September 2026 onwards, and, when it comes to it, at 2 a.m. That is exactly the work Kunnus takes over, at the points where the 24-hour chain breaks in practice: a public URL is the single point of contact for incoming tips. A guided process separates suspicion from verification, and only verification starts the SLA tracking of the reporting stages. Every assessment, status change, and report is logged with a timestamp and is provable after the fact. User notification runs through security advisories as a CSAF stream.
Here is how Kunnus maps to the obligations from the table above:
| Obligation (Article 14) | How Kunnus solves it |
|---|---|
| Para. 1: Reporting actively exploited vulnerabilities | The public Kunnus URL is your single point of contact. Incoming tips land directly in the guided process and with the reporting owner, instead of in a support inbox. This also covers the single point of contact that Article 13(17) requires from December 2027. |
| Para. 2(a): Early warning within 24 hours | Kunnus prompts you in a template for exactly the details you must report and pre-fills what is already known from existing data in the system. The early warning becomes as light as it can be. |
| Para. 2(b): Vulnerability notification within 72 hours | Analysis, measures taken, and workarounds are documented in the case. The content of the 72-hour notification sits collected in one place. |
| Para. 2(c): Final report (vulnerability) | The moment a fix becomes available is recorded in the case and starts the 14-day SLA. The security advisory for the fix provides the content of the final report. |
| Para. 3: Reporting severe incidents | Incidents run through the same guided reporting chain as vulnerabilities, with their own fields per reporting stage. |
| Para. 4(a): Early warning within 24 hours (incident) | The initial assessment in the guided process asks for the mandatory details, including the suspicion of malicious action. |
| Para. 4(b): Incident notification within 72 hours | Detection and occurrence times are captured with timestamps from case creation and stand ready for the 72-hour notification. |
| Para. 4(c): Final report (incident) | The documented case timeline is the basis of the final report, and the one-month deadline is tracked as an SLA. |
| Para. 5: The "severe" threshold | Verification is a dedicated process step. Only when you classify the case as actively exploited or severe does the SLA clock of the reporting stages start. |
| Para. 6: Interim report on request | Every assessment, status change, and report is logged with a timestamp. The interim report is an export of the timeline. |
| Para. 7: Competent CSIRT | Competent CSIRT and platform access are documented once during Kunnus setup, per legal entity. In an emergency, the information sits where the case is being worked. |
| Para. 8: Informing users | You publish advisories from Kunnus as a CSAF stream. For directly addressing affected customers, the same advisories provide the ready-made content. |
| Paras. 9 and 10: Formats and procedures | The Kunnus team tracks the legal acts and keeps Kunnus up to date, from the reporting templates to the EU CRA knowledge base. The Kunnus newsletter keeps you informed of changes. |
The process decisions in the table above remain yours. Kunnus makes sure that intake, verification, deadlines, and documentation behind them are right at all times.
See the workflow live: get a demo. Or start by finding out where your company stands with the free CRA maturity assessment (15 to 20 minutes).
Is this guide available as a PDF whitepaper?
Yes. The Kunnus whitepaper “Article 14 Reporting Obligations: What Must Be in Place by 11 September 2026” condenses everything in this article into 14 pages: the deadlines, the decision tree, the process map, the worked example, and the preparation checklist, plus working aids in the appendix. Current as of the EU Commission guidance of July 2026.
Download the whitepaper (PDF, 14 pages) — free, no registration required. Also available in German.
Frequently asked questions about the reporting obligation
What exactly do I have to do by 11 September 2026? Five things: assign ownership (reporting owner, deputy, competent CSIRT), compile product data (versions, countries of sale, customer contacts), build templates for all three reporting stages, set up an intake channel with a triage process, and rehearse the flow once. Details in the five-step preparation above.
Do I have to report every CVE my scanner finds? No. Only actively exploited vulnerabilities and severe incidents under paragraph 5 are reportable. Scanner findings, published CVEs without exploitation, researcher reports, and pentest results belong in your internal vulnerability management, not with the CSIRT and ENISA.
Do I have to report when a vulnerability is only being exploited in other manufacturers' products? No. The Commission guidance of 27 July 2026 (C(2026) 5252 final) makes clear in para. 218 that a component vulnerability is not reportable for you as long as it cannot be exploited in your product or has not been exploited there, even if it is being actively exploited elsewhere. What remains is voluntary notification under Article 15 and notifying the component manufacturer under Article 13(6). As soon as you become aware of exploitation in your product, the 24-hour clock starts.
When does the 24-hour clock start? With verified awareness, not with the arrival of a tip. The initial assessment must start without delay, though, and be documented end to end; otherwise you risk the accusation of late awareness.
Who do I report to? Simultaneously to the coordinating CSIRT of the member state of your main establishment and to ENISA, via the single reporting platform under Article 16.
The full legal text of Article 14, with FAQ and cross-references, is available in the Kunnus CRA knowledge base. Only the wording of Regulation (EU) 2024/2847 as published in the Official Journal of the EU is legally binding. This article does not constitute legal advice.