CRA Article 14: manufacturer ransomware ≠ automatic severe incident

What Articles 3(44), 14(3)/(5) and Recital 68 actually say

Article 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 coordinating CSIRT and ENISA — via the Article 16 Single Reporting Platform. Article 3(44) defines an “incident having an impact on the security of the product with digital elements” as an incident that 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 data or functions.

Article 14(5) then marks that product-security incident as severe where either: (a) it negatively affects or is capable of negatively affecting the product’s ability 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 the product or in the network and information systems of a user. Note the “capable of” language — actual user harm is not required once the product-security path is real.

Recital 68 explains the severe-incident track as situations where a cybersecurity incident affects the manufacturer’s development, production or maintenance processes in such a way that it could result in an increased cybersecurity risk for users or other persons — including where an attacker has successfully introduced malicious code into the release channel used for security updates. That is product-lifecycle compromise, not every laptop encryption ticket in the helpdesk queue.

Corporate ransomware without a product path

Typical non-CRA shapes: ransomware encrypts accounting shares, HR mailboxes or a marketing CMS; production firmware signing is offline and untouched; update CDN credentials and CI runners stay out of the blast radius; shipped products keep their ability to protect data and functions. Those facts may still trigger NIS2 (if you are an essential or important entity), GDPR Article 33/34 (if personal data is at stake), insurer notice clauses or national criminal reporting — none of which is an Article 14 early warning. See Article 14 vs NIS2 and Article 14 vs GDPR breach notification.

When ransomware does start the Article 14 clock

Map the blast radius to the product. Indicators that usually meet Article 3(44) / 14(5): attackers reached code-signing or release-signing keys; CI/CD or firmware build hosts that feed shipped images; the update or package distribution channel users pull from; product backend remote data processing that the shipped SKU needs (Article 3(2)); or evidence the campaign can introduce or execute malicious code in the product or user networks. Recital 68’s poisoned update channel is the textbook case — run the severe track: 24-hour early warning, 72-hour incident notification, final within one month after that 72-hour submission (severe incident notification; clocks in reporting deadlines).

If the same campaign later exploits a flaw in products already made available, with Article 3(42) reliable evidence of malicious exploitation without permission, that second pattern can open the actively exploited vulnerability track with its own final (corrective or mitigating measure available + 14 days). Do not blend the finals: AEV vs severe incident (Recital 68).

The trap: malware name as the reporting rule

Two failure modes show up in triage. First: IR playbooks say “ransomware → file CRA” and burn the 24-hour clock on every corporate encryption event, flooding the SRP and confusing CSIRTs while the real product-security question is still unanswered. Second: teams treat “it was only our corporate network” as a holiday even after signing keys or the update path were in the ransomware operator’s hands — exactly when Article 14(5)(b) and Recital 68 expect the severe chain. Record the product-impact assessment in the evidence log: what was hit, whether development / production / maintenance or shipped product security was capable of being affected, and when that assessment finished (awareness timing: becoming aware).

Decision table

Questions people ask

Is ransomware at our company automatically reportable under Article 14?

No. Article 14(3) requires notification of a severe incident having an impact on the security of the product with digital elements. Article 3(44) defines that product-security impact; Article 14(5) then asks whether the incident is “severe.” Corporate ransomware that encrypts finance systems, email or unrelated servers — without touching the product’s ability to protect data or functions, and without a path to malicious code in the product or user systems — is not automatic Article 14. Other regimes (for example NIS2 or GDPR) may still apply.

When does ransomware become a CRA severe incident?

When the facts meet Article 3(44) and at least one Article 14(5) limb: the incident negatively affects or is capable of negatively affecting the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or it has led or is capable of leading to the introduction or execution of malicious code in the product or in a user’s network and information systems. Recital 68’s severe-incident picture is a cybersecurity incident that affects development, production or maintenance processes so user cyber risk could rise — for example malicious code in the security-update release channel.

Our signing keys / CI / update CDN were hit. Do we report?

That shape usually points at Article 14(3)–(5), not at “ignore it because it started as ransomware.” A compromised build pipeline, code-signing key or update distribution path is the Recital 68 example class: capable of introducing or executing malicious code in the product or user systems. Start the 24-hour / 72-hour chain from awareness and use the severe-incident final (one month after the 72-hour notification). See our severe-incident and AEV-vs-severe guides.

Does filing NIS2 or a cyber-insurance claim replace the SRP?

No. Article 14 has no NIS2- or insurer-substitution limb. Significant-entity filings under NIS2 Article 23, DORA major ICT reports, GDPR breach notices and insurer claims sit beside Article 14 when the product-security test is met. Parallel-regime walkthroughs: our NIS2, DORA and GDPR comparison guides.

Could the same ransomware campaign also be an actively exploited vulnerability?

Sometimes, as a second fact pattern. Recital 68’s AEV track is a malicious actor using a flaw in a product you made available to breach users or others, with Article 3(42) reliable evidence of exploitation without permission. If ransomware only hits your corporate estate, that is not an AEV. If the same campaign later exploits a product flaw in customer systems with that evidence, open the AEV track from that awareness moment — different final clock (measure available + 14 days).

When did this duty start?

Article 14 has applied from 11 September 2026 (Article 71(2)), including for in-scope products already on the market (Article 69(3)). The product-security filter for severe incidents is live now — it is not part of the December 2027 Annex I conformity package.