Article 14 is the one that starts the clock

Not sure the CRA even applies to your product? Check your risk class in four steps.

1. What Article 14 requires

Article 14 imposes on the manufacturer of a product with digital elements a duty to report two kinds of events: any actively exploited vulnerability contained in the product, and any severe incident that has an impact on the security of that product. The duty is directed at the CSIRT designated as coordinator and, in parallel, at ENISA, through the single reporting platform.

The obliged party is the manufacturer, not the reseller and not the end user: whoever develops or manufactures the product, or has it developed or manufactured and markets it under their own name or trademark, carries the duty. The scope is the product placed on the market, regardless of when it was first sold. A product on the market for years is fully within scope.

2. The three deadlines, on two parallel chains

Each notifiable event goes through three steps: an early warning, the 72-hour notification — a vulnerability notification on one chain, an incident notification on the other — and a final report. The first two deadlines are the same on both chains — 24 hours for the early warning, 72 hours for that notification — but the final report has two different deadlines depending on what you are reporting. Confusing the two is the most frequent mistake in the internal procedures we are shown.

Chain one, actively exploited vulnerabilities: early warning within 24 hours of becoming aware; vulnerability notification within 72 hours; final report within 14 days of a corrective or mitigating measure becoming available. The final deadline hangs on the availability of the fix, not on the calendar.

Chain two, severe incidents affecting the security of the product: early warning within 24 hours, incident notification within 72 hours, and then a final report within one month of the incident notification. Same first two steps, different anchor for the last one. Because the calculation of the final deadline depends on how the event was qualified at step one, the qualification has to be recorded together with the article applied.

3. Exploited is not the same as reported

The vulnerability chain does not start with every vulnerability. It starts only when there is reliable evidence that someone has exploited the vulnerability in a system without the owner's authorisation. A researcher's responsible disclosure, an academic paper, a scanner flagging an old library: none of these, on its own, triggers the 24-hour clock, because none of them is evidence of an unauthorised exploitation in the wild.

This distinction cuts both ways. Reporting too little exposes you to a sanction; reporting everything burns credibility with the CSIRT and consumes time you will need for the real cases. The decision that a given report is not, or not yet, an actively exploited vulnerability must be taken quickly and, above all, written down: a reasoned "no" is a defence, an implicit "no" leaves no trace when an inspector asks why you did not file.

4. The clock starts from awareness, not from Monday

The 24 hours run from the moment the company becomes aware of the event. Not from when the manager opens the email, not from Monday morning, not from the alignment meeting. If a report lands at the public address at 23:40 on a Saturday, that is the instant you will have to defend before the CSIRT and, if it comes to it, before the market surveillance authority.

This moves the problem from the technical domain to the organisational one. Three things follow directly: a single, staffed intake channel that someone actually watches; a written qualification rule that says who decides whether the clock has started and on what criteria; and an on-call chain with hourly thresholds and named substitutes. The companies we have seen in trouble did not have a competence problem — they had an availability problem.

5. Two duties almost everyone forgets

The first is the notice to users. After notifying the authorities, and without undue delay, the manufacturer informs the users of the product about the incident or vulnerability and, where appropriate, about the corrective or mitigating measures they can take. A copy of what was circulated, and when, must be kept: the notice to users is an obligation in its own right, not a courtesy.

The second is upstream reporting. If the vulnerability sits in a third-party component — including an open source one — the manufacturer must report it to the person or entity that maintains the component and cooperate with them. This duty, set by Art. 13(6), is materially impossible without an up-to-date software bill of materials: without an SBOM you know neither which of your products embed the component nor whom to write to.

6. Sanctions: how much, and what mitigates them

Breaches of the obligations under Articles 13 and 14 — which include the reporting duties we have described — are subject to administrative fines of up to 15 million euro or, if the offender is an undertaking, up to 2.5% of its total worldwide annual turnover for the preceding financial year, whichever is higher. This is the top band of the regulation's penalty scheme, and it applies to the reporting duties, not only to product non-conformity.

The amount is not automatic. When setting a fine the authority weighs the nature and gravity of the breach, its duration, whether it was intentional or negligent, and the degree of cooperation with the authorities. In practice this is where documented due diligence pays off: a written qualification decision, a timestamped intake log and evidence of prompt cooperation change the outcome of the same underlying event.

7. What to do before 11 September 2026

Three operational things, in order of urgency. A public intake channel for receiving reports, paired with a coordinated vulnerability disclosure policy published where researchers look for it — a security.txt file on your domain. A written qualification rule stating who decides whether the clock has started and on what criteria. An on-call chain with hourly thresholds and named substitutes, so the Saturday-night case has an owner.

Then two administrative prerequisites that run on timelines that are not yours: the EU Login credentials needed to reach the reporting platform, and the designation of your contact point to the national CSIRT — in Italy, CSIRT Italia at ACN. Requesting them on the day of the emergency means arriving late for a reason that has nothing technical about it. Identify in advance the people who can act as your designated representative (Assigned Representative) on the platform, and complete registration and association to the Single Reporting Platform following ENISA's guidance in force at the time of notification — the procedure may evolve, so do not treat it as fixed. CRAnotify prepares the filing but does not automate the final submission on the SRP: there is no automatic SRP API, and the deposit stays an act of the manufacturer, performed with its own credentials. We set out the how-to on the dedicated page.

The rest — the product register, the software bill of materials, the integrations — is built in the months that follow. But without these five things ready, the first real report will catch you exposed, and that first report can arrive the day after 11 September 2026.

This article describes our reading of the regulatory text and does not constitute legal advice.