Cyber Resilience Act Article 14: the 24-Hour Clock Has Started and It Covers Software Already Sold

On 11 September 2026, the first obligation of the EU Cyber Resilience Act became applicable. Most of the regulation does not apply until December 2027. Reporting of vulnerabilities and incidents did not wait.

For a company that sells software, the change is not in the legal text. It is in how long engineering takes to answer a simple question: which products, and which versions, contain the vulnerability that has just been exploited.

What changed on 11 September

Article 14 of Regulation (EU) 2024/2847 requires manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents affecting the security of those products. The sequence is fixed:

1. Early warning within 24 hours of the manufacturer becoming aware.
2. Notification within 72 hours, with the information available by then.
3. Final report no later than 14 days after a corrective measure is available, for vulnerabilities, or within one month of the 72-hour notification, for severe incidents.

Notifications go to the national computer security incident response team (CSIRT) of the Member State where the manufacturer has its main establishment, through the single reporting platform run by ENISA, which receives the same information.

A vulnerability counts as actively exploited when there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission, according to Freshfields' analysis of the Commission's guidance. The clock starts once the manufacturer has a reasonable degree of certainty that this has happened.

Who is a manufacturer, and what is in scope

The European Commission defines a manufacturer as a natural or legal person who develops or manufactures products with digital elements, or has them designed, developed or manufactured, and markets them under its own name or trademark, whether for payment, monetisation or free of charge.

Two points carry more weight than a first reading suggests.

Reporting covers products already on the market. The regulation's other obligations only reach older products if they undergo a substantial modification from December 2027. The reporting obligations, by contrast, apply to all products in scope, including those sold before that date. A version delivered three years ago is in scope today.

There are exclusions, but they are specific. Products already covered by other Union legislation fall outside its scope, as happens in some regulated sectors. Whether the regulation applies to software provided only as a remote service is a question this article does not address, and it is worth confirming with legal advice rather than assuming.

Why the deadline is an engineering problem, not a legal one

The early warning has to identify the affected product. That sounds trivial. It is not, when the same library lives in several versions of several products, installed at different customer sites.

The same report shows why the problem grows over time instead of shrinking.

Read alongside Article 14, the numbers describe a concrete situation. A product does not stop ageing when it is delivered. Dependencies fall behind, some lose their maintainers, and the team that built the original version has moved on. When a vulnerability in one of those dependencies starts being exploited, the 24-hour clock starts all the same.

The difference between meeting the deadline and missing it rarely lies in knowing the deadline exists. It lies in being able, within it, to match one vulnerability to every product and version that carries it.

What has to exist before the first alert

None of this can be built within 24 hours. It has to be ready beforehand.

1. A component inventory per product and per version. Without it, identifying the affected product is archaeology. With it, it is a query.
2. A defined route from alert to named owner. Who receives the exploitation signal, who confirms it and who has the authority to declare that the clock has started.
3. A written criterion for "actively exploited". The legal definition asks for reliable evidence. The team needs to know, before a real case, what kind of evidence counts.
4. Tested access to the single reporting platform. Credentials, owner and deputy, before there is any rush.
5. Prepared communication to affected users. Goodwin highlights that manufacturers must also inform affected users without undue delay. A template message and a contact list per product save hours.
6. A support period defined per product. The regulation asks the manufacturer to determine how long it will handle vulnerabilities for each product, with the end date clear at the point of purchase.

How it relates to NIS2

The Cyber Resilience Act applies to products. NIS2, transposed into national law across the EU, applies to entities and the services they provide. A software company can be subject to both, with different deadlines, authorities and platforms. For companies that also supply essential or important entities in Portugal, see NIS2 in Portugal: what changes for suppliers of essential entities.

Frequently asked questions

Does the Cyber Resilience Act already apply in full? No. It entered into force on 10 December 2024. The reporting obligations apply from 11 September 2026, and the remaining main obligations apply from 11 December 2027.

Does reporting apply to products sold before 2027? Yes. The reporting obligations cover all products in scope, including those already on the market, according to the European Commission.

What are the fines? Penalties are set at national level. Published legal analyses point to a ceiling of 15 million euros or 2.5% of total worldwide annual turnover, whichever is higher. The Commission notes that micro and small enterprises are exempt from fines for missing the 24-hour early warning deadline.

What needs to be in place first? The component inventory per product and version. Every other element, from the named owner to user communication, depends on knowing quickly what is affected.

Conclusion

Article 14 of the Cyber Resilience Act has turned vulnerability management into a commitment measured in hours, one that also covers software already sold. The legal text is short. The work that makes it achievable is engineering: inventory, owners, criteria and access defined before the first alert.

To discuss how to structure that inventory and the route from alert to owner, with senior capacity that reinforces the in-house team, book a Clarity Session, with no commitment.