Cyber Resilience Act: 24-hour vulnerability reporting is now live

On September 11, 2026, the reporting obligations of the EU Cyber Resilience Act (CRA) started to apply. From that day, manufacturers of products with digital elements made available in the EU must report actively exploited vulnerabilities and severe incidents affecting the security of their products, starting with an early warning within 24 hours of becoming aware. On the same day, the EU Agency for Cybersecurity (ENISA) launched the Single Reporting Platform (SRP), the portal through which those reports must be filed.

The obligation is not limited to new products. It covers products already on the market, more than a year before most of the regulation applies on December 11, 2027. For software vendors, device makers and any other manufacturer that places an app, firmware or connected product on the EU market under its own name, learning that a vulnerability in one of its products is being actively exploited now starts a regulatory clock measured in hours. Here is what changed, who is affected and what to do in the first weeks.

What happened

The CRA, Regulation (EU) 2024/2847, entered into force on December 10, 2024, with staggered application dates. The rules on notifying conformity assessment bodies have applied since June 11, 2026, and most of the regulation, including the essential cybersecurity requirements for products, applies from December 11, 2027. Article 14, which governs reporting, applies earlier: under Article 71(2), from September 11, 2026.

ENISA marked the date by deploying what it calls the "initial operating capability" of the SRP and said it will improve and expand the platform's functionality over the coming months. "Vulnerabilities in digital products are often exploited by threat actors to subvert or hamper critical services, such as healthcare, energy, transport or telecommunications," said ENISA Executive Director Juhan Lepassaar. "The streamlined reporting and sharing of information on actively exploited vulnerabilities and severe incidents helps to build a more resilient Digital Single Market."

What must be reported, and when

Two kinds of events trigger a mandatory notification. The first is an actively exploited vulnerability, which the CRA defines as "a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner". The second is a severe incident having an impact on the security of the product: 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 could lead, to the introduction or execution of malicious code in the product or in a user's network and information systems. The regulation's own example is an attacker planting malicious code in the channel a manufacturer uses to release security updates.

Each event is reported through the SRP in up to three stages, with later stages required unless the information has already been provided:

• Early warning within 24 hours

  Without undue delay and in any event within 24 hours of becoming aware, indicating where applicable the Member States in which the product has been made available. For incidents, the early warning must also say whether the incident is suspected of being caused by unlawful or malicious acts.

• Notification within 72 hours

  Without undue delay and in any event within 72 hours of becoming aware: general information about the product and the nature of the exploit and vulnerability, or about the nature of the incident with an initial assessment, together with the corrective or mitigating measures taken, those users can take, and how sensitive the manufacturer considers the information to be.

• Final report

  For a vulnerability, no later than 14 days after a corrective or mitigating measure is available: a description of the vulnerability, including its severity and impact, information on any malicious actor where available, and details of the security update or other corrective measures. For a severe incident, within one month after the 72-hour notification: a detailed description including its severity and impact, the type of threat or likely root cause, and the applied and ongoing mitigation measures.

The CSIRT receiving the notification may also ask for an intermediate status report, and manufacturers must inform the impacted users, and where appropriate all users, about the vulnerability or incident and any measures they can take to reduce its impact. As for when the clock starts, the Commission's draft guidance published on July 27 explains that a manufacturer becomes aware when, after an initial assessment, it has "a reasonable degree of certainty" that a vulnerability in its product is being actively exploited, or that a severe incident has compromised the product's security. Exploitation a manufacturer already knew about before September 11 does not have to be reported retroactively, but exploitation discovered from that date onwards must be reported, even if the vulnerability itself was known earlier.

Who is affected

The obligation falls on manufacturers: companies that develop or manufacture products with digital elements, or have them developed, and market them under their own name or trademark. The CRA covers hardware and software products, including components placed on the market separately, whose use involves a data connection to a device or network, such as mobile and desktop applications, firmware, connected devices and network equipment. Under Article 69(3), reporting also applies to products placed on the market before December 11, 2027, and the Commission's guidance notes that it continues after a product is no longer supported.

Medical devices, motor vehicles, certified civil aviation products and marine equipment are excluded because sector-specific rules already cover them, as are products developed exclusively for national security or defence. Standalone Software as a Service is not a product with digital elements. A cloud backend is in scope only as remote data processing: when the manufacturer designs and develops it, or has it developed under its responsibility, and the product needs it to perform its functions, such as the API behind the manufacturer's own mobile app. A vulnerability in a third-party component must be notified by the manufacturer of the final product if it has been actively exploited in that product, but not if it is unreachable or unexploited there. Reporting duties for open-source software stewards apply only from December 11, 2027.

How the Single Reporting Platform works

Manufacturers report once. The notification goes through the SRP to the CSIRT designated as coordinator in the Member State of the manufacturer's main establishment, where decisions on the cybersecurity of its products are predominantly taken or, if that cannot be determined, the Member State of its establishment with the most employees in the EU. Except in particularly exceptional circumstances, the notification is made simultaneously accessible to ENISA, and the CSIRT passes it on to the CSIRTs of the Member States where the manufacturer indicated the product is available, unless dissemination is delayed on justified cybersecurity grounds. Manufacturers without a main establishment in the EU follow a fixed order: the Member State of the authorised representative, importer or distributor handling the largest number of their products, in that order, and failing those, the Member State with the most users. ENISA lists 27 coordinating CSIRTs, one per Member State, and warns that if the wrong one is selected, "the notification may be invalidated and will need to be resubmitted".

The first release has clear limits. It accepts only mandatory reports, with voluntary reporting to follow in a later phase. There is no API, so notifications are entered through the web interface, and the platform is available in English only. Access requires a personal EU Login account with multi-factor authentication, and each manufacturer can register one primary and up to 20 secondary Assigned Representatives on the platform. ENISA also notes that the platform's 72-hour counter currently displays a due time 48 hours after the early warning, while the legal deadline runs from the moment of awareness.

Why leaders should care

A 24-hour deadline only works if the path from a customer report or threat intelligence alert to a filed notification is already defined. Exploitation of widely used products is not rare: between August 1 and September 11, CISA added 53 vulnerabilities to its Known Exploited Vulnerabilities catalogue, including flaws in products from Cisco, Apple, SonicWall, Google, Citrix, Fortinet, MikroTik and ConnectWise. That catalogue is a US list and not the CRA's legal test, but it shows how often exploitation of commercial products is confirmed. The SharePoint zero-day we covered in July is the kind of event that, from now on, starts a reporting clock for the manufacturer.

The stakes are high. Article 64 places breaches of the reporting obligations in the CRA's highest penalty tier, with administrative fines of up to €15 million or, for an undertaking, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. Micro and small enterprises are exempt from fines only for missing the 24-hour early warning. Like most of the regulation, the penalty provisions themselves apply from December 11, 2027, but the duty to report applies now.

Many organisations are not ready. In a survey of small and medium-sized enterprises that ENISA published in June, only 66% of the 194 respondents had heard of the CRA before taking part, and incident response and product life cycle management was the weakest area overall. Meanwhile, the pressure is growing. When it published its guidance in July, the Commission warned: "Recent developments in frontier AI models with cybersecurity capabilities render the swift and correct implementation of the Cyber Resilience Act even more imperative." Reporting readiness now belongs alongside NIS2, DORA and GDPR obligations in any compliance programme.

What to do now

1. Map your products and confirm scope

   List every product with digital elements you make available in the EU, including older and unsupported versions, the cloud services they depend on and the third-party components they contain. Decide which are in scope and record why.

2. Identify your coordinating CSIRT and prepare access

   Determine your main establishment under Article 14(7) and the CSIRT you will report to, and document the reasoning. Make sure the people who will file, and their deputies, have personal EU Login accounts with multi-factor authentication. ENISA advises registering on the platform only when a notification is needed and says registration takes just a few minutes once such an account exists.

3. Build a 24-hour triage runbook

   Define how reports reach you: your vulnerability disclosure contact, customer support, partners, threat intelligence and exploited vulnerability lists. Decide who assesses whether there is a reasonable degree of certainty of exploitation, who files, and who approves. Prepare templates for the early warning, the 72-hour notification, the final report and the user notice. The clock does not stop at weekends, so on-call coverage matters.

4. Find vulnerabilities before attackers do

   A vulnerability discovered through good-faith testing is not subject to mandatory notification; only an actively exploited one is. From December 11, 2027, the CRA will also require manufacturers to apply "effective and regular tests and reviews of the security" of in-scope products placed on the market from that date. Frequent Autonomous Penetration Testing of the web applications and backends behind your products, together with a security code review, shrinks the window in which an attacker can find a flaw first.

5. Rehearse before the first real case

   Run a tabletop exercise in which an exploited vulnerability is reported late on a Friday. Test whether the team can assess it, reach the right decision makers and file an early warning within 24 hours. Use the gaps you find to refine the runbook, and align it with your incident reporting duties under other regulations.

Pressing questions

• If a penetration test finds a vulnerability in our product, must we report it within 24 hours?

  Not on its own. Mandatory reporting covers actively exploited vulnerabilities only. Recital 68 of the CRA states that vulnerabilities discovered with no malicious intent for the purposes of good-faith testing should not be subject to mandatory notification, and the Commission's implementation FAQ confirms that a zero-day found by a testing laboratory working on the manufacturer's behalf, with no evidence of previous malicious exploitation, is not subject to mandatory reporting. If the test uncovers evidence that an attacker has already exploited the flaw, however, the 24-hour clock applies.

• We sell software as a service. Are we in scope?

  Standalone SaaS is not a product with digital elements under the CRA, and the regulation points to NIS2 for cloud computing services. However, if you also make a product, such as a mobile app or a connected device, and you design and develop the cloud backend it needs to perform its functions, that backend is remote data processing and falls within scope as part of the product.

• We are a small company. Are we exempt?

  No. Micro and small enterprises must report like everyone else. Their relief is that they cannot be fined for missing the 24-hour early warning deadline; the 72-hour notification and the final report still apply. ENISA has also set up a dedicated help desk for the platform.

• Will we soon report all incidents in one place?

  Possibly, but not yet. The Commission's November 2025 Digital Omnibus proposal would create a single entry point for incident reporting under several EU laws, which may build on the CRA platform. It is still a proposal under negotiation and does not change the CRA obligations that apply today.

Key takeaways

September 11, 2026, turned CRA reporting from a future compliance project into a live operational duty. A manufacturer that becomes aware of an actively exploited vulnerability or a severe incident affecting its product must now file an early warning within 24 hours, a full notification within 72 hours and a final report after that, through a platform that is still in its first release. The duty covers products already on the market, so the exposure exists today, not in 2027.

The organisations that cope best will be those that have mapped their products, know their coordinating CSIRT, rehearsed the 24-hour path and, above all, reduced the chance of exploitation in the first place. Findings from an authorised penetration test do not, on their own, start a reporting clock. Exploitation by an attacker does. Our GRC team can help you build the reporting process, and Autonomous Penetration Testing can help you find weaknesses before anyone else does.