Guides · Updated 27 July 2026

What actually happens on 11 September 2026

The Article 14 reporting obligation starts. Here is precisely what it requires, what it does not, and why most manufacturers over-estimate it.

The obligation in one paragraph

Article 14 of Regulation (EU) 2024/2847 requires manufacturers to notify ENISA of any actively exploited vulnerability contained in their product, and of any severe incident having an impact on the security of that product. Three stages: early warning within 24 hours of becoming aware, full notification within 72 hours, and a final report. For a vulnerability the final report is due 14 days after a corrective or mitigating measure becomes available. For a severe incident it is due one month after the full notification.

What "actively exploited" means, and what it excludes

This is the part that gets misread. Article 14(1) covers vulnerabilities that are actively exploited, not every vulnerability in your SBOM. A CVE published against a component you ship is not, on its own, an Article 14 report. It becomes one when there is reliable evidence that someone has used it against a real system.

That distinction is the difference between filing four reports a year and filing four hundred. You still have to fix the rest under Annex I Part II, and you still have to disclose fixed vulnerabilities when a security update ships. But the 24-hour clock does not start for them.

The 24-hour early warning is smaller than you think

ENISA published the Single Reporting Platform field set in its FAQ. At the 24-hour stage the obligatory fields are: notification type, notification level, name of manufacturer, product, and title. For an incident, add whether you suspect the incident was caused by unlawful or malicious acts. Member States where the product is available is obligatory only if you have that information.

The CVE ID is marked optional at 24 hours. There is no CVSS field at any stage of any notification. If you have been holding off filing because you were assembling a severity score, you were solving a problem the form does not have.

There is no API

ENISA states in its FAQ that no Application Programming Interfaces will be provided at this stage. Submission is manual entry into a web portal, reached through EU Login. Any vendor claiming to file on your behalf system-to-system is describing something that does not exist. What a tool can honestly do is prepare, validate and stage the notification so manual entry takes minutes rather than hours.

Register with EU Login before you need it

Access to the platform is through EU Login. The coordinating CSIRT validates your authority to report for a manufacturer after first access, in parallel with reporting, so validation does not gate your ability to submit. ENISA advises registering only when you need to file, to avoid overloading CSIRT validation queues.

That advice is about their queue, not your readiness. Knowing which CSIRT coordinates for you under Article 14(7), and having someone in your company who has actually seen EU Login, are things to sort out before a clock is running.

What to do this month

• Name a single point of contact for vulnerability reports and publish it. A security.txt on your website is the standard way to serve the contact address.
• Publish a coordinated vulnerability disclosure policy. Annex I Part II point 5 requires one and it is a technical documentation item under Annex VII.
• Produce an SBOM. You cannot tell whether a newly exploited CVE affects you if you do not know what is in your firmware.
• Run a rehearsal. Draft all three notifications against a fake incident, once, while nothing is on fire. Templates cannot be written while a 24-hour clock runs.