Article 14 step by step: 24 h, 72 h, 14 days — how reporting through the ENISA platform works

The reporting duty under Article 14 is the first thing from the Cyber Resilience Act that applies for real — from 11 September 2026, and it applies even to products you placed on the market long ago. The hard part isn't filling in a form, it's making the deadline: 24 hours leaves no room to improvise. Let's break the whole procedure down step by step so nothing catches you out.

What gets reported

Two events are reported: an actively exploited vulnerability in your product (someone is really using it, not merely "a CVE exists") and a severe incident affecting the product's security. The difference between "a vulnerability exists" and "it is actively exploited" is covered in the CVE, CVSS, EPSS and KEV article — a listing in the KEV catalogue is a typical signal that Article 14 is triggered.

The three deadlines

The first two deadlines run from the moment you become aware of the matter; the third (the final report) runs from a later event:

1. Within 24 hours of becoming aware — an early warning. Briefly: who you are, which product, what it concerns. Without waiting for complete details.
2. Within 72 hours of becoming aware — a vulnerability/incident notification. The nature of the problem, its severity, the corrective measures taken or planned, and any affected Member States.
3. The final report. For a vulnerability, within 14 days of a corrective or mitigating measure being made available (Art. 14(2)(c)). For a severe incident, within one month of submitting the 72-hour notification (Art. 14(4)(c)). So this deadline does not run from awareness, but from that later event.

The deadlines are not "either/or" — they are successive steps for the same event. The early warning buys time, the full notification completes the picture, the final report closes it.

Where the report goes

The report is filed through ENISA's Single Reporting Platform (SRP) and goes simultaneously to the coordinating CSIRT and to ENISA. The competent one is the CSIRT designated as coordinator in the Member State of your main establishment (Art. 14(7)); for Slovakia no designation had been published as of the date of this article — the national CSIRT SK-CERT is the assumed candidate. The platform is a single place that fans the report out to wherever it needs to go — you don't have to report to several authorities separately.

Important: the platform has no API

This is the detail that shapes your preparation. The SRP has no API — no tool can send the report for you automatically. You sign in via EU Login (the European sign-in account), and after your first sign-in your account is verified by your national CSIRT. Verification takes a while and differs by country. The practical consequence: register in advance, while things are calm — not at the moment your 24-hour clock is already running.

Vulnerability vs incident — two tracks

Although both go through the same platform, they differ in the final deadline. For an actively exploited vulnerability, the final report is within 14 days after a corrective or mitigating measure is available. For a severe incident (e.g. a breach that affected the product's security) the final report is within one month of submitting the 72-hour notification. The first two steps (24 h and 72 h) are the same in both cases. So at the very start, be clear which of the two tracks you're on — it sets the final deadline.

Note too that Article 14 reporting is a different duty from publishing an advisory or a GDPR personal-data-breach notification. They can run in parallel, but they have their own recipients and deadlines — don't conflate them.

How to prepare so you make it

You'll manage 24 hours only if most of the work is done ahead:

1. A platform account. Create the EU Login and get the account verified now, not during your first incident.
2. Know who's affected. With an SBOM and monitoring you can quickly say whether a new vulnerability hits your versions — that's half of the early warning.
3. Assigned roles. Who watches vulnerabilities, who decides, who files the report — plus a deputy. On one page.
4. Pre-filled fields. Have what doesn't change (manufacturer, contact, products) pre-filled, so during an incident you only add the facts.

FAQ

1. When does "become aware" start? The deadlines run from the moment you become aware — which is why it matters to have a channel and monitoring so you learn in time, not by accident.
2. Must we report every vulnerability? No — Article 14 concerns actively exploited vulnerabilities and severe incidents, not every CVE.
3. Who verifies the account in Slovakia? The coordinating CSIRT of the Member State of your main establishment; for Slovakia no designation had been published as of the date of this article (SK-CERT, the national CSIRT, is the assumed candidate). Verification takes a while — do it in advance.
4. Doesn't the platform have an API for automation? No, the SRP has no API — you file manually via EU Login.

The most common mistake: preparing only at the incident

Companies that come unstuck on Article 14 share one thing: they only tackled the platform once the clock was already running. You won't get the account verified by the national CSIRT in a few hours, and without an SBOM you can't quickly say whether a new vulnerability affects you. So registration, an SBOM and pre-filled fields are things that belong to "calm" time — not to the first incident.

Key point

Article 14 reporting is the first CRA duty that bites — from 11 September 2026, including products placed on the market long ago. You report actively exploited vulnerabilities and severe incidents (not every CVE) through ENISA's Single Reporting Platform, simultaneously to the coordinating CSIRT and ENISA. Deadlines: a 24 h early warning and a 72 h notification from becoming aware, then a final report — for a vulnerability within 14 days of a corrective measure being made available (Art. 14(2)(c)), for an incident within one month of the 72-hour notification (Art. 14(4)(c)). The key detail for preparation: the platform has no API, you sign in via EU Login, and your account is verified by the national CSIRT (SK-CERT in Slovakia) — which takes a while. So register in advance and keep pre-filled fields and an SBOM ready, so you can quickly say whether a new vulnerability affects you. You'll only manage 24 hours if most of the work is done in calm times, not during the incident.

How CRAguard helps

CRAguard can't file for you (the platform doesn't allow it), but it does the hardest part around it: it watches your components daily, raises a "possible Article 14" flag on a KEV listing, counts down the 24/72 h and 14-day deadlines, and prepares a bundle of fields to copy into the platform. You just review and submit. Find out whether the CRA applies to you, or join the waitlist.

This article is informational and not legal advice. It is based on Regulation (EU) 2024/2847 (Art. 14), ENISA's FAQ on the Single Reporting Platform and the European Commission's guidance of 27 July 2026. The platform procedure may be refined — follow ENISA's current guidance.