Skip to content
folhas.io
secure by design for connected products· Articles

Articles

The 24h and 72h reports: how the obligation applicable since 11 September 2026 works

Since 11 September 2026, a manufacturer who learns of an actively exploited vulnerability in its product has 24 hours for the first alert. What gets reported, to whom, through where, and what to have ready.

Published
Updated

Update note (23 Oct 2026). Text revised after the obligation started to apply: the reporting platform has been running since 11 Sep 2026, the Commission guidance of 27 Jul 2026 is now the reference cited, and third-party components, informing users and products already placed on the market have been added.

Article 14 of the Cyber Resilience Act was the first major obligation on manufacturers to enter into application: on 11 September 2026, fifteen months before full application. Since that date, a manufacturer of products with digital elements that becomes aware of an actively exploited vulnerability, or of a severe incident having an impact on the security of the product, enters a timeline measured in hours.

What triggers the obligation

This is the most widely misunderstood point. Article 14 does not cover every vulnerability. It covers two things:

  • Actively exploited vulnerabilities: flaws in the product for which there is reliable evidence that a malicious actor has exploited them in a system without the owner’s permission (Art. 3(42));
  • Severe incidents having an impact on the security of the product: those that negatively affect, or are capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, and those that lead, or are capable of leading, to the introduction or execution of malicious code in the product or in a user’s systems (Art. 14(5)).

A vulnerability the team discovers and fixes before it is exploited follows the normal vulnerability handling process. It opens no 24-hour clock.

The clock starts the moment the manufacturer becomes aware. The Commission guidance of 27 July 2026 (C(2026) 5252, non-binding) clarifies what that means: awareness exists when, after an initial assessment of the suspicious event, the manufacturer has a reasonable degree of certainty that there is active exploitation or a severe incident. The deadline runs from the outcome of that triage, which makes triage a formal process, with an owner and a written criterion.

With third-party components (a library, a runtime, the web server behind an admin panel), the triage question is whether the flaw has been or is being exploited in the product itself. According to the same guidance (point 218), if the vulnerable code is not reachable in the product, or there has been no exploitation in it, that manufacturer has no mandatory report to make. Exploitation of the component in other systems is a signal for that triage. The vulnerability then follows the normal process, which for products placed on the market from 11 December 2027 includes reporting it to whoever maintains the component (Art. 13(6)). Article 09 applies this test to the PHP and Node.js flaws fixed on 21 October 2026.

The obligation also covers the installed base. By express derogation (Art. 69(3)), Article 14 applies to all products in scope, including those placed on the market before 11 December 2027, which are otherwise subject to the CRA only if they undergo a substantial modification. The Commission guidance adds that reporting continues to apply after the support period has ended.

The three deadlines

  1. 24 hours, early warning notification. Deliberately lean: an actively exploited vulnerability or a severe incident exists, which product is affected, and in which Member States the manufacturer knows the product has been made available.
  2. 72 hours, vulnerability notification (for severe incidents, incident notification). General information about the product, the nature of the exploit and of the vulnerability, corrective or mitigating measures already taken and those users can take.
  3. Final report. For vulnerabilities: within 14 days of a corrective or mitigating measure becoming available. For severe incidents: within one month of the incident notification. It includes a description, severity and impact, information about the malicious actor where available, and details of the fix.

There is also a fourth text, this one addressed to users. After becoming aware, the manufacturer must inform the impacted users (and, where appropriate, all users) of the vulnerability or incident and, where necessary, of the risk mitigation and corrective measures they can deploy, where appropriate in a structured, machine-readable format (Art. 14(8)). If it does not do so in a timely manner, the CSIRT designated as coordinator may do so instead.

Article 14 timeline: awareness, established by triage, starts the clock; early warning notification at 24 hours; vulnerability or incident notification at 72 hours; final report 14 days after a corrective or mitigating measure is available, or one month after the notification for severe incidents.
The Article 14 timeline. The clock starts with awareness, and that is what makes triage a formal process.

To whom and through where

You report once, through the Single Reporting Platform (SRP) provided for in Art. 16, which ENISA put into operation on 11 September 2026. The notification goes in through the endpoint of the CSIRT designated as coordinator in the Member State of the manufacturer’s main establishment (in Portugal, CERT.PT, at the National Cybersecurity Centre) and is simultaneously accessible to ENISA. That CSIRT then disseminates the notification to the CSIRTs of the other Member States where the product is available, and feeds the market surveillance authorities.

In exceptional circumstances, the coordinating CSIRT that receives the notification may decide to delay dissemination to the other CSIRTs, for the period strictly necessary and on cybersecurity-related grounds, in particular at the manufacturer’s request (Art. 16(2)). Delegated Regulation (EU) 2026/881 sets the conditions, for example an ongoing coordinated disclosure in which the CSIRT acts as trusted intermediary, or a mitigating measure the manufacturer expects to make available within 72 hours. The decision is the CSIRT’s, and it must inform ENISA immediately.

A detail with consequences: the “main establishment” is the Member State where decisions about the cybersecurity of the products are predominantly taken. If that cannot be determined, it is the one where the manufacturer has the establishment with the highest number of employees in the Union. Manufacturers with no main establishment in the Union follow a cascade, based on the information available to them: first the Member State of the authorised representative acting for the highest number of the manufacturer’s products, then that of the importer placing the highest number on the market, then that of the distributor making the highest number available and, finally, the Member State with the most users. It pays to settle this before any incident: according to ENISA’s FAQ, a notification sent to the wrong coordinating CSIRT may be invalidated and have to be resubmitted to the right one.

The platform, since 11 September 2026

ENISA opened the SRP on 11 September 2026, the same day Article 14 started to apply, in a first version it calls “initial operating capability” (logbook entry 004 recorded that day). It has limits worth knowing before you need it: it exists only in English, has no API and does not yet accept the voluntary notifications of Article 15.

Each person who will notify on the manufacturer’s behalf needs an EU Login account with multi-factor authentication. The manufacturer designates on the platform one primary representative and up to 20 secondary ones (assigned representatives, a platform role not to be confused with the authorised representative under the Regulation), and the coordinating CSIRT validates that association. ENISA advises registering only when there is something to notify; what gets prepared in advance is who will do it and with which CSIRT.

In the current version, the 72-hour countdown the platform displays starts from the submission of the early warning and shows 48 hours from then. The legal deadline runs from the moment of awareness, and that is the time the internal record has to keep. If the platform is down, you can contact the coordinating CSIRT directly, but submission through the SRP is still required once it is back. An active exploitation the manufacturer already knew about before 11 September 2026 is not reported retroactively; if it only becomes aware after that date, it reports, even if the vulnerability is older.

The practical conclusion stands: the internal process does not depend on the tool, and it has to say who does triage, who decides “we have become aware”, who drafts, who approves, and with which pre-written templates.

What this means for manufacturers

The 24-hour report is not a communication problem; it is a problem of readiness. Four pieces any manufacturer, of any size, can put in place, and that should have been ready by 11 September 2026:

  1. Signals that feed triage. Monitoring of the sources that raise the suspicion that a “known vulnerability” has become “actively exploited”: alerts from CERT-EU and the national CSIRT (in Portugal, CERT.PT), advisories from the maintainers of the components in the SBOM, including pre-announcements of security releases, CISA’s KEV catalogue, and the channel for receiving external reports (the coordinated vulnerability disclosure policy the CRA itself requires). The KEV is a US catalogue, with its own criteria, and can lag behind the first reports of exploitation: a CVE’s absence from the KEV does not prove there is no exploitation. The question triage answers is whether the flaw has been or is being exploited in the product.
  2. An awareness decision with an owner. Who may declare, and by what criterion, that the company “has become aware”. Without that written criterion, nobody knows for certain when the deadline started to run.
  3. The texts written in advance. The 24h early warning fits on half a page; writing it during the incident is the worst possible time. Fill-in templates for the three notifications and for the notice to users, approved beforehand.
  4. The rehearsal. One tabletop exercise per half-year, with a realistic scenario, measuring one thing: how much time passes between the signal and an early warning ready to submit.

In a micro-enterprise, all of this fits in half a dozen pages and an afternoon of exercise. What does not fit is improvising it at 3 a.m. on a Thursday.

Sources