Cyber Resilience Act: the 24 hours start today

Cybersecurity

CISO-as-a-service consulting: posture, remediation roadmap, ongoing support.

Discover →

Artificial Intelligence

EU AI Act consulting: system classification, policies, AI governance, training.

Discover →

At the end of July, writing about the Commission’s guidance, we said there were six weeks left before the first deadline carrying applicable obligations. They are up. From today, 11 September 2026, Article 14 of Regulation (EU) 2024/2847 applies.

The dates are set by Article 71, which is worth rereading because it is counterintuitive: the regulation “shall apply from 11 December 2027”, but Article 14 applies from 11 September 2026 and Chapter IV (Articles 35 to 51) from 11 June 2026. So today one piece of a regulation comes into operation while the rest of it lands in fifteen months.

What starts the clock

This is the part most summaries skip, and it is the one that decides whether you have to do anything today.

The obligation is not triggered by the existence of a CVE. It is not triggered by a high CVSS score. Article 3 defines an actively exploited vulnerability as one “for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner”.

That is a test of evidence of exploitation, not of theoretical severity. On one side it narrows the field considerably, and anyone who feared having to notify every advisory can relax. On the other it moves the problem onto a harder question: how do you know something is genuinely being exploited, and know it early enough to still have 24 hours in front of you.

The second track is a severe incident having an impact on the security of the product, defined in paragraph 5: one that 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 that 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.

The three clocks, which are not the NIS2 ones

Here are the windows, reported with their starting points, because that is where people get it wrong.

Actively exploited vulnerability (Art. 14(2)):

• Early warning within 24 hours of the manufacturer becoming aware, indicating the Member States where the product has been made available.
• Vulnerability notification within 72 hours of becoming aware, with the general nature of the exploit and the vulnerability, corrective or mitigating measures taken and those users can take.
• Final report within 14 days of a corrective measure being made available. Not from discovery and not from the notification: from the moment the remedy exists.

Severe incident (Art. 14(4)): early warning within 24 hours, which must state at minimum whether the incident is suspected to result from unlawful or malicious acts; notification within 72 hours; final report within one month of the 72-hour notification.

Anyone planning to reuse their NIS2 flows should look closely here. The first two windows coincide, the third does not. Under NIS2 the final report is due one month after the incident notification; under the CRA the vulnerability one is due 14 days anchored to the availability of the fix, which is an event under your own control and therefore has to be tracked as such. They are two different timers starting from two different facts.

Then there is paragraph 6: the coordinating CSIRT that received the notification first may request an intermediate report with relevant status updates. Worth factoring in when sizing whoever staffs the channel.

The duty towards users, which is separate

Paragraph 8 is the one we see cited least in this week’s discussions and the one that weighs most on the product.

From the moment it becomes aware of the exploited vulnerability or the severe incident, the manufacturer informs the impacted users and, where appropriate, all users, together with the measures they can take, “where appropriate in a structured, machine-readable format that is easily automatically processable”.

Two concrete consequences. First, you need a channel to your users that already exists and is reachable the same day, meaning a security advisory feed rather than a news page. Second, the machine-readable format is not cosmetic: whoever receives the advisory has to be able to ingest it automatically, which is why formats like CSAF and VEX exist.

The closing subparagraph adds an incentive worth reading in full: if the manufacturer does not inform users promptly, the coordinating CSIRTs that received the notification may do it in its place, where they consider it proportionate and necessary. Control over how your own market is told, if you do not exercise it, someone else does.

Where to report and why registration has to happen first

Notifications go through the single reporting platform established by Article 16, built and operated by ENISA, using the electronic notification endpoint of the CSIRT designated as coordinator in the Member State of the main establishment.

The main establishment, says paragraph 7, is the Member State “where the decisions related to the cybersecurity of its products with digital elements are predominantly taken”; where that cannot be determined, the one with the largest number of employees in the Union. For those not established in the Union there is a four-step cascade: authorised representative, importer, distributor, and finally the State with the largest number of users. For an Italian manufacturer the counterpart is CSIRT Italia, inside the National Cybersecurity Agency.

Here is the operational detail that makes the rest executable or not. The ENISA platform opens today, the same day the obligation becomes enforceable, and it requires advance registration of the representatives authorised to submit notifications. Registration is not something you complete in twenty-four hours while handling an incident. If your organisation is in scope and does not yet have a working account, this is the thing to do today, before anything else.

If you do open source

Article 24 covers open-source software stewards, defined in Article 3 as legal persons other than the manufacturer whose purpose or objective is “systematically providing support on a sustained basis” for the development of specific products qualifying as free and open-source software and intended for commercial activities, and that ensure the viability of those products. Individual volunteer developers stay out of scope.

Paragraph 3 says something precise and worth quoting at length, because the idea that stewards are exempt from reporting is circulating. The obligations in Article 14(1) apply to stewards “to the extent that they are involved in the development of the products with digital elements”. The obligations in paragraphs 3 and 8 apply “to the extent that severe incidents having an impact on the security of products with digital elements affect network and information systems provided by the open-source software stewards for the development of such products”.

In plain terms: a steward supporting a commercially used project notifies actively exploited vulnerabilities in the part it develops, and notifies severe incidents when they hit the development infrastructure it provides. The second case is precisely the compromised forge, the scenario we have watched materialise more than once this summer. ENISA’s own platform documentation indeed names manufacturers and open source software stewards among its users.

Anyone integrating open source components into their own product remains a manufacturer in full on the finished product, whatever the origin of the code. It is the point we had already brought into focus in SBOM and CRA reporting.

The Italian knot and the thing that does not apply yet

On Italy there is a simplification circulating that is worth correcting. Law 36 of 17 March 2026, the 2025 European delegation law, contains at Article 15 a delegation to the Government to adapt national legislation to the cyber resilience regulation. It is a delegation, not a designation: formally identifying the market surveillance authority and setting the national penalty regime come with the delegated legislative decree, which as of today does not appear to have been published.

This suspends nothing, because a regulation is directly applicable and Article 14 holds from today regardless of what Rome does. But it explains the asymmetry of the moment, and it is the same pattern we found looking at the Italian AI Act decrees: the European obligation bites while national implementation is still in transit.

On penalties, one thing needs stating precisely. Article 64 sets fines of up to 15 million euro or 2.5% of total worldwide annual turnover, whichever is higher, for breaches of Articles 13 and 14. Article 64, however, is not among the exceptions listed in Article 71: the only items brought forward are Article 14 and Chapter IV. The textual reading is therefore that the duty to report is enforceable from today while the penalty apparatus follows the general calendar of 11 December 2027. That is not a postponement of the obligation, and the distinction is there to help you plan rather than relax: notifications missed today remain documented facts when market surveillance starts looking backwards.

A technical objection that should not be filed away

During the work on the regulation a group of researchers and civil society organisations raised a point that still stands: concentrating in a single system the actively exploited and not yet fixed vulnerabilities of every European manufacturer creates an archive of considerable offensive value, because it describes in real time what is attackable and where.

The final text does give an answer, in Article 16(2): dissemination of a notification to the other CSIRTs may be delayed for cybersecurity reasons, for as long as strictly necessary, in particular at the manufacturer’s request and where the vulnerability is under coordinated disclosure. That mitigates propagation, not accumulation: the data still sits in the platform and in the national CSIRTs. From today that infrastructure is, in practice, one of the most sensitive targets in Europe, and the level of protection to demand of it is the one the regulation demands of manufacturers.

What to do today, in order

For anyone placing products with digital elements on the European market, the list is short and ordered by dependency.

1. Register on the platform. Appoint the authorised representatives and check the account works, today, in cold blood. Without this, the three clocks cannot be met.

2. Write down who decides that a vulnerability is “actively exploited”. You need a name, a deputy and a decision rule. The 24 hours run from when the organisation became aware, not from when the committee meets.

3. Connect the sources that give you evidence of exploitation. In practice CISA KEV, threat intelligence feeds, your own logs and the reports reaching you from the field. CVSS is no help here: what you need is whether somebody is using it.

4. Prepare the channel to users, in machine-readable form. An advisory you can publish the same day, with a stable structure.

5. Keep a register of the two different timers. The 14-day one hangs off the release date of the fix: it belongs in the release process, not in the incident response process.

6. Use the inventory you should already have. Without knowing which components run inside your products, the question “does this exploited vulnerability concern us?” has no answer within 24 hours. It is the same argument as the numbers we lined up in 432 Linux kernel CVEs in two days.

What we think

What makes this deadline interesting is that it shifts the axis of compliance from documentation to responsiveness. The essential requirements of 2027 are prepared by writing; Article 14 is met only if on a Monday morning somebody sees a thing, recognises it and gets it onto a platform by the evening. It is the part of the regulation that cannot be delegated to a document.

There is also an aspect we think is underrated in the debate: the reliable-evidence-of-exploitation test makes evidence the real object of the rule. Knowing you have a vulnerability is not enough, you have to know whether it is being used, and that is a problem of telemetry and sources rather than of documentary compliance. Anyone without visibility over their own perimeter is not behind on paper: they are practically unable to know whether the obligation has been triggered.

That is the ground we work on. CyberAgent keeps the attack surface under continuous observation and correlates every vulnerability with CVE, EPSS and CISA KEV as well as with the context of the environment, which is precisely the signal Article 14 starts counting from. With automated pentesting it then verifies what is genuinely exploitable, rather than handing over a list sorted by CVSS. DataGovern holds the documentary side: it maps obligations onto real processes, has notification modules on the 24 and 72-hour windows, and keeps the audit trail and the memory of decisions, meaning the evidence needed to show when you knew something and what you did. It runs on-premise with open weight LLMs, which for data on unfixed vulnerabilities is an architectural property rather than a preference.

As we write every time, neither produces automatic compliance: they cut manual work and make the part you have to demonstrate repeatable, while formal responsibility stays with whoever places the product on the market. The full picture of our solutions and the CISO advisory are there to help decide which of the two pieces you are actually missing.

One piece stays open and it is worth knowing while you build the process. Article 14(10) leaves the Commission the option of specifying, by implementing acts, the format and the procedures for submitting notifications, for this article as well as for Articles 15 and 16. Anyone standing up the internal flow this week would do well to keep what they record separate from how they transmit it: the fields needed to reconstruct when you knew something will not change, the form you hand them over in can.

The work that makes a deadline like this one survivable all sits upstream, and we have been following it with our clients since June, when we started reading the regulation article by article: an inventory of dependencies, sources that give evidence of exploitation, named roles with a deputy, an advisory channel that works within the day. The next milestone is 11 December 2027, with the essential requirements and the SBOM in the technical documentation. The inventory built today to answer within 24 hours is the same base needed then: it is the part worth doing properly once.

Sources

• Regulation (EU) 2024/2847, full text
• ENISA, Single Reporting Platform
• European Commission, CRA reporting obligations
• Law 36 of 17 March 2026, 2025 European delegation law
• Cyber Security 360, what changes from 11 September
• ICT Security Magazine, the hidden risk in the reporting obligation
• Cyber Resilience Act: a practical guide after the Commission’s clarifications
• Cyber Resilience Act: SBOM and vulnerability reporting on the way