Witnium logo
WITNIUM. Chain.
← News

Rules · 2026-10-10 · 5 min read

Cyber Resilience Act, Article 14: who must report actively exploited vulnerabilities

From September 2026, manufacturers of IP cameras, routers, PLCs and connected software must report actively exploited vulnerabilities to ENISA within strict timelines.

VeraBy Vera

Share
Abstract timeline showing sealed incident steps
Illustration: AI-generated

The rule

Article 14 of the Cyber Resilience Act (EU) 2024/2847 sets out reporting obligations for manufacturers of products with digital elements [1]. These are products that connect to a network, process data or communicate digitally: IP cameras, routers, smart thermostats, industrial PLCs, connected medical devices outside the scope of the Medical Devices Regulation, and software distributed commercially [1].

The rule applies from 11 September 2026 [1]. Medical devices under the MDR and vehicles with type approval are exempt [1].

Two types of event trigger the duty: actively exploited vulnerabilities and severe incidents affecting the security of the product [1]. An actively exploited vulnerability is one the manufacturer knows is being used in the wild to compromise products already on the market. A severe incident is one that has caused, or could cause, widespread harm or operational disruption.

The timelines

For an actively exploited vulnerability, the manufacturer must submit an early warning within 24 hours of becoming aware [1]. That early warning is followed by an incident notification within 72 hours and a final report within 14 days [1].

For a severe incident, the manufacturer must submit the incident notification within 72 hours and the final report within 14 days [1].

The clock starts when the manufacturer becomes aware, not when it decides the event is worth escalating. That distinction matters, because in a dispute about whether a deadline was met, the question is when the first person inside the organisation knew enough to trigger the duty.

What must be reported

The early warning at 24 hours is brief: the vulnerability, which products are affected, whether it is being exploited and any immediate measures the manufacturer has taken [1].

The 72-hour incident notification adds detail: the nature of the vulnerability or incident, affected products and versions, estimated impact, ongoing mitigations and whether the manufacturer has informed customers [1].

The final report at 14 days includes a root cause analysis, the full scope of the impact and the measures taken to prevent recurrence [1].

All notifications go through ENISA's common reporting platform [1]. ENISA distributes the information to the relevant national authorities and, where it judges necessary, to other EU agencies and member states [1].

The evidence question

The duty to report is one thing; showing that you met the deadlines is another.

In September 2026, an IP camera manufacturer detects unusual traffic patterns suggesting a vulnerability is being exploited. The security team investigates. Two days later, an engineer confirms active exploitation and escalates to management. A lawyer reviews the finding and, after further questions, the early warning goes out 28 hours after the first detection.

A year on, a supervisor asks why the warning was late. The manufacturer says it became aware when the engineer escalated, not when the security team first noticed the unusual traffic. The supervisor asks for the timeline.

If every step was documented as it happened, the manufacturer can show when each person knew what. If the timeline was written later, or if key entries were edited along the way, the record is harder to defend.

Sealing the timeline as it happens

Here, the thing to seal is each step in the incident timeline: the first detection note, the escalation decision and each report as it is sent to ENISA.

Sealing takes a fingerprint of the record, not the record itself, so sensitive details never leave the manufacturer's systems. The fingerprint goes to WitniumChain through the REST API, the SDK or the MCP server, and the manufacturer gets a witness ID back. To check, the manufacturer calculates the fingerprint again and compares it with the sealed one. Change a single word in the escalation note, and the fingerprints won't match.

Anyone the manufacturer shares the timeline with—a supervisor, an auditor or an insurer—can run the same check. The first 2,000 witnesses a month are free. Read the docs.

What it shows is when each step was recorded, in a way nobody can quietly rewrite afterwards. What it doesn't show is that the report was complete, that the response was adequate, or that the manufacturer met every requirement in Article 14. That judgement is still for the supervisor.

How it would work

  1. When the security team logs the detection, seal the detection note.
  2. When the engineer escalates, seal the escalation record.
  3. When each report is sent to ENISA, seal a copy.

Who this affects

The duty sits with the manufacturer, the entity that places the product on the market or puts it into service under its own name or trademark [1].

For software, that includes the developer who releases the software commercially, even if it is distributed through an app store or bundled with hardware [1].

For hardware, it includes the company that designs and sells the product, and in some cases the importer if the manufacturer is outside the EU [1].

Distributors and retailers are not directly subject to Article 14, but they may be asked to forward information about incidents to the manufacturer [1].

Organisations that deploy or operate the products—a factory running an industrial control system, a municipality installing IP cameras, a hospital using networked diagnostic equipment—are not the manufacturer for the purposes of Article 14. They have their own incident reporting duties under the Cybersecurity Act (NIS2) and, in some sectors, under DORA, but those are separate rules with different triggers and timelines.

What this means for you

If you manufacture or sell products with digital elements, three questions are worth asking now.

First, who in your organisation is responsible for detecting that a vulnerability is being exploited, and do they know the 24-hour deadline starts when they become aware?

Second, do you have a process for logging when you first knew, when you decided to escalate and when you sent each report, in a way that can be checked later?

Third, if a supervisor questioned your timeline a year from now, could you show it unchanged?

If you deploy or operate such products, you are not the manufacturer for Article 14, but you may still need to document when you detected an incident and when you reported it under NIS2 or sector-specific rules. The same timeline question applies.

What to watch

The Cyber Resilience Act's basic security requirements in Annex I, which include logging and vulnerability handling, apply from 11 December 2027 [2]. Article 14's reporting duty comes earlier, on 11 September 2026 [1].

ENISA is expected to publish guidance on the common reporting platform and the information manufacturers must provide. Watch for that in the first half of 2026.

Penalties for failing to meet the reporting duty can reach €15 million or 2.5 per cent of global annual turnover, whichever is higher [1].

Sources

  1. [1]Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), Article 14, EUR-Lex, 2024-10-23
  2. [2]Regulation (EU) 2024/2847, Annex I: Essential cybersecurity requirements, EUR-Lex, 2024-10-23
Pass it on

Know someone who should read this?

Share it with a colleague, your compliance team or your network.

Email

Sealed with WitniumChain

Seal pending. This article will be sealed shortly, and the seal details will appear here.

Written with AI assistance and reviewed by Vera.

Related