Most companies are still preparing for the CRA as if it were a one-off certification — working backwards from a launch date to schedule testing, and treating the report, once issued, as compliance achieved. But Article 14 has never tested whether you have run the tests. It tests whether your organisation can catch what happens the moment an incident occurs. That is what this article is about: not the complexity of the text itself, but the question sitting behind it that most companies have not yet asked themselves.
When people talk about the CRA, the date they remember is 11 December 2027, the general application date. But on 11 September 2026, one obligation with explicit penalties attached comes into force ahead of it: Regulation (EU) 2024/2847 (Cyber Resilience Act) Article 14 — reporting obligations of manufacturers — applies from 11 September 2026.
For company leadership, that means Article 14 is not a technical detail for the cybersecurity or legal team to absorb on its own. It is a compliance matter that can surface directly in financial risk disclosure and on the board agenda.
Under Article 64(2), infringements of the essential requirements in Annex I and of the obligations in Articles 13 and 14 fall into the CRA’s highest penalty tier: fines of up to EUR 15,000,000 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.
It makes no difference which year a product was placed on the market, or whether it has ever been revised. If it falls within the scope of the CRA, then from 11 September 2026 the reporting obligation applies simultaneously to every product circulating on the EU market. Even if you have no intention of re-certifying a legacy product, as long as it is still on the EU market and is found to be under active attack, the 24-hour notification still has to be filed.
Article 14 is triggered by two scenarios, each with its own threshold. Not every vulnerability has to be reported.
The first is an actively exploited vulnerability.
(Art. 14(1)) A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA.
Everything turns on “actively exploited”. The legal definition in Article 3(42) requires reliable evidence that a malicious actor has actually exploited the vulnerability in a system without authorisation of the system owner — theoretical attackability is not enough. A CVE flagged high-risk by a scanner, but not yet actually attacked, will normally not start the Article 14 clock. The clock starts only once there is evidence of actual exploitation, whether detected by the manufacturer’s own monitoring, reported by a customer, or disclosed by an external researcher.
The second is a severe incident having an impact on the security of the product.
(Art. 14(3)) A manufacturer shall notify any severe incident having an impact on the security of the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA.
The threshold for “severe” is set out in Article 14(5); either limb is sufficient:
(Art. 14(5)) (a) it negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or (b) it has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product with digital elements.
What is being assessed here is not the technical severity of the vulnerability itself, but whether there has been an actual or potential negative effect on the availability, authenticity, integrity or confidentiality of data or functions, or whether malicious code has been introduced or executed. The emphasis in this limb is on what has happened, not on what might be exposed.
Put in terms a cybersecurity team will recognise: a vulnerability is closer to “could be attacked”, an incident is “has been attacked”. The CRA manages these two stages separately, and the reporting rhythm differs for each.
As for who reports — it is always the manufacturer. There is no exemption based on whether the product is classified as Default, Important or Critical. This is worth stressing in internal communications, because plenty of cybersecurity teams will assume their own product is low-risk and therefore out of scope. Whether Article 14 is triggered depends on the nature of the vulnerability or incident, not on the product classification.
The deadlines in Article 14 are one of the few places in the CRA where timing is written down precisely — and also one of the most frequently over-simplified. Summaries in circulation tend to merge the “vulnerability” and “incident” tracks into one, but the official text keeps them clearly apart, right down to the event the clock runs from.
Vulnerability track (actively exploited vulnerability):
Incident track (severe cybersecurity incident):
The first two milestones are the same on both tracks. The difference is what the final-report clock runs from: on the vulnerability track, the 14 days run from the day a corrective or mitigating measure becomes available; on the incident track, the month runs from the day the 72-hour notification is submitted. Neither has anything to do with when customers finally receive the update. This is where mistakes are easy, because companies internally treat “the update has shipped to customers” as the closing milestone of the process — Article 14 does not count time that way. Settling this in advance is what keeps the final report from going out late.
One carve-out worth noting: under Article 64(10)(a), micro and small enterprises are not fined for failing to meet the 24-hour early warning deadline alone. The reporting obligation itself, the 72-hour notification and the final report continue to apply to them in full. The relief is limited to fines, and only to that one deadline — the obligation is not waived.
One further rule allows no flexibility at all: every notification must be submitted through the single reporting platform (SRP) established by ENISA under Article 16, and must reach, at the same time, the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment. Email, telephone and other informal channels do not constitute recognised notification.
Memorising the deadlines is not the hard part. The hard part is that, at the moment of becoming aware, the organisation has to start several workstreams at once: engineering has to confirm the evidence, compliance and communications have to settle the external wording, sales or support may need to prepare customer messaging in parallel — and all of it has to be compressed into 24 hours to produce a first external document. Most companies’ current cybersecurity incident response processes are designed to restore service as fast as possible; very few are designed to produce an official, regulator-format notification in a very short window. That is precisely why 11 September 2026 is the gate many manufacturers will struggle to clear in time.
The real question that follows is how to build the internal process so that it can carry these deadlines when an incident actually happens. That is the subject of the next article, starting from the skeleton of the SOP.
You are also welcome to join the in-person seminar in Taipei on Friday 18 September, where you can put questions directly to a CRA expert from Spain and learn more about planning for 2027 compliance and estimating the time and cost of implementation. Registration: Register for the seminar
Q: When does CRA Article 14 take effect? 11 September 2026 — ahead of the CRA’s full application on 11 December 2027. It applies to every product circulating on the EU market, whenever that product was placed there.
Q: What are the two reportable situations under Article 14? The first is an actively exploited vulnerability — where there is clear evidence that a vulnerability in the product is being exploited. The second is a severe incident that has had an actual or potential impact on the product’s security, for example affecting the availability, authenticity, integrity or confidentiality of data.
Q: What are the Article 14 reporting deadlines? Both categories require an early warning within 24 hours and a detailed 72-hour notification. For vulnerabilities, the final report is due within 14 days of a corrective or mitigating measure becoming available; for incidents, within one month of the 72-hour notification being submitted.
Q: Through which channels must a CRA report be filed? Through the single reporting platform (SRP) established by ENISA under Article 16, delivered at the same time to the coordinating CSIRT designated by the Member State in which the manufacturer has its main establishment. Informal channels such as email and telephone are not recognised.
All legal provisions and dates cited in this article are based on the following official documents:
By the Secure Vectors Surveillance Inc. (SV Surveillance) × Applus+ Laboratories consulting team
* This article is regulatory commentary, not legal advice. Final compliance determinations for specific cases remain subject to official EU documents and the interpretations of the competent authorities.
