Skip to content
EU AI Stack

CRA Article 14 starts 11 September: the 24 hour, 72 hour and 14 day reporting chain

Fryderyk Pryjma6 min read
Minimal navy illustration of three gold outlined circles containing the numerals 24, 72 and 14, connected by arrows, representing the CRA Article 14 reporting chain

From 11 September 2026, Article 14 of Regulation (EU) 2024/2847, the Cyber Resilience Act, becomes the first part of the regulation to bite. Manufacturers of products with digital elements must notify actively exploited vulnerabilities and severe security incidents through a single reporting platform run by ENISA, on a three-step clock: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days for a vulnerability or one month for an incident. The duty sits on the manufacturer, not on the customer, and it applies more than a year before the rest of the regulation lands on 11 December 2027. If you ship an on-prem AI appliance, a virtual appliance, or software a customer installs, you are in scope now.

What changes on 11 September 2026

The Cyber Resilience Act entered into force on 10 December 2024 and applies in full from 11 December 2027. Article 14, the reporting obligation, was pulled forward deliberately: it applies from 11 September 2026. The reasoning is that supervisors wanted visibility into exploitation in the wild before the conformity regime switched on, so the reporting channel goes live first and the CE marking regime follows.

Practically, that means a manufacturer can be fully compliant with nothing else in the regulation and still be in breach on 12 September for failing to file an early warning. There is no grace period written into Article 14, and there is no de minimis for small manufacturers.

The three deadlines

StepDeadlineContent expectedFiled with
Early warning24 hours from awarenessThat it happened, the member states affected if known, and whether the vulnerability is under exploitationSingle reporting platform, routed to the designated CSIRT and ENISA
Vulnerability or incident notification72 hours from awarenessGeneral information on the product, the nature of the exploit or incident, severity and impact, plus any corrective or mitigating measures availableSame platform, updating the earlier warning
Final report14 days after a corrective measure is available for a vulnerability; one month after the 72 hour notification for a severe incidentDescription of the vulnerability including severity and impact, root cause, applied fix, and technical details enabling identification and mitigationSame platform
Article 14 reporting chain. The clock starts when the manufacturer becomes aware, not when the issue began.

Awareness is the word that decides everything. For a vulnerability it means you know it is being exploited, not that you know it exists. For an incident it means you know the security of the product has been compromised. Both are judgements a named person has to make quickly, which is why the definition belongs in your incident plan rather than in a lawyer's memo.

Who files, and where

The obligation falls on the manufacturer: the party that develops or has a product with digital elements developed and markets it under its own name or trade mark. An importer or distributor has narrower duties. A customer running your appliance has none under the CRA, although the same event may trigger its own NIS2 Article 23 duty on a parallel clock.

  • Reporting goes through a single reporting platform established by ENISA, so one submission reaches the CSIRT designated as coordinator and ENISA together.
  • The coordinating CSIRT is normally the one in the member state where you have your main establishment in the Union.
  • Non-EU manufacturers report through their authorised representative or importer chain, which needs naming in advance rather than during the first 24 hours.
  • You must also inform affected users about the incident or vulnerability and, where relevant, about corrective measures they can deploy.

What an AI vendor needs in place before Friday

  1. A named reporter and a deputy, with the platform registration completed in advance. Registering during an incident costs hours you do not have.
  2. A written definition of awareness for both triggers, tied to a specific signal: an exploit confirmation from your detection stack, a credible third party report, or a customer notification.
  3. A product inventory that maps each shipped artefact to a manufacturer entity, a version range and a support end date, so the 72 hour notification can name the product precisely.
  4. A build-generated SBOM per release, in CycloneDX or SPDX, so root cause in a dependency can be traced without a code archaeology exercise.
  5. A user notification template and channel, since informing affected users is a separate obligation from the platform filing.
  6. A drafted 24 hour message with blanks. The early warning is short by design; writing it from scratch under pressure is what causes the deadline to slip.
  7. An alignment clause with your customers, so your factual account and their NIS2 filing do not contradict each other.

Where AI products differ

Two questions come up repeatedly with AI systems. First, is a model weight file a product with digital elements? On its own, distributed without any software placed on the market, generally no. Shipped as part of an appliance or an installable inference stack, the product is the whole thing and the weights are a component of it. Second, is a prompt injection a reportable vulnerability? If it is being exploited in the wild and it compromises the security of the product rather than merely producing poor output, treat it as reportable and document the reasoning either way.

Purely hosted services are outside the CRA's product scope, but the boundary is thinner than vendors assume: a remote data processing solution integral to the functioning of a product with digital elements is pulled in with it. A SaaS control plane that an on-prem appliance cannot operate without is not obviously outside.

The regulation does not ask you to have no vulnerabilities. It asks you to notice exploitation within a day and to be able to say something useful about it within three.

Frequently asked questions

Does Article 14 apply before the rest of the Cyber Resilience Act?
Yes. Article 14 reporting applies from 11 September 2026, while the remaining obligations, including CE marking and conformity assessment, apply from 11 December 2027. A manufacturer can therefore breach the reporting duty long before the product regime applies.
When does the 24 hour clock start?
When the manufacturer becomes aware of an actively exploited vulnerability or a severe incident affecting the security of the product. Awareness of a vulnerability alone, with no evidence of exploitation, does not start it.
Do we file with our national authority or with ENISA?
One submission through the single reporting platform reaches both the coordinating CSIRT and ENISA. There is no need to file separately with each member state affected.
We only offer a hosted API. Are we in scope?
Not for a standalone hosted service. If the service is a remote data processing solution without which a product you place on the market cannot perform its function, it is treated as part of that product and the duty follows.
Does an Article 14 filing satisfy our customer's NIS2 reporting?
No. The two duties sit on different parties. Your filing does not discharge your customer's Article 23 early warning and notification, and your contract should commit you to giving them the facts inside their own 24 hour window.
ShareLinkedInXEmail

Related articles

Next step

Need this as an outcome, not an article? Sovereign deployment.

Sovereignty is a buyer's problem stated as a hosting question. We answer it as an architecture decision: which layer must stay in your jurisdiction, what that costs over three years, and what an auditor accepts as proof.

Explore Sovereign deployment