Cyber Resilience Act from September 2026: What Software Developers Need to Know About 24- and 72-Hour Vulnerability Reporting
From 11 September 2026, one of the Cyber Resilience Act’s most time-sensitive duties will begin to apply across the European Union. Article 14 of Regulation (EU) 2024/2847 requires manufacturers of in-scope products with digital elements to report certain actively exploited vulnerabilities and severe security incidents on a strict timetable: an early warning within 24 hours and a more complete notification within 72 hours after becoming aware of the event. For software teams, this is not simply a legal department issue. Developers, security engineers, product owners and incident responders may be the first people to see evidence that starts the reporting clock. The practical challenge is therefore to recognise which events are reportable, preserve enough information to support a defensible decision and move from technical triage to a regulatory notification without delaying remediation.
What Changes for Software Teams on 11 September 2026
The CRA entered into force on 10 December 2024, but its obligations do not all begin at the same time. Most of the Regulation will apply from 11 December 2027, while Article 14 starts earlier, on 11 September 2026. That distinction matters because a company cannot assume it has until the end of 2027 to build its vulnerability-reporting process. The early reporting rules also have a broad transitional reach. Article 69 states that Article 14 applies to all products with digital elements that fall within the CRA’s scope, including products placed on the EU market before 11 December 2027. A legacy desktop application, firmware branch or commercial library may therefore create a reporting duty in September 2026 even though the product is not yet subject to the CRA’s full set of 2027 product requirements.
For developers, the first task is to understand whether the software is part of a “product with digital elements”. The CRA uses this term for software or hardware products, including software and hardware components supplied separately, where the intended or reasonably foreseeable use includes a direct or indirect connection to a device or network. It can also cover remote data processing that is necessary for a product to perform one of its functions and that is designed or developed by, or under the responsibility of, the manufacturer. This means the assessment can extend beyond the executable installed on a customer’s machine. A mobile application that depends on a manufacturer-controlled API or database, for example, may need to be considered together with that remote functionality. By contrast, unrelated websites or cloud services that do not support the product’s functionality are not automatically brought into scope by the CRA.
The legal duty sits with the “manufacturer”, which the Regulation defines more broadly than a factory-style meaning of the word might suggest. It can be a natural or legal person that develops a product with digital elements, has it developed, and markets it under its own name or trade mark, whether the product is paid for, monetised in another way or supplied free of charge. A software developer working inside such an organisation may not personally file the notification, but the developer’s observations can determine when the organisation is considered aware of an event. Free and open-source software also needs careful classification. Non-commercial open-source development is treated differently, while commercial open-source products can bring manufacturer duties and certain organisations supporting open-source projects on a sustained basis can qualify as open-source software stewards. Teams should therefore map legal responsibility to actual products rather than assuming that a particular licence, business model or development method decides the issue by itself.
What the 24- and 72-Hour Deadlines Actually Mean
The 24-hour rule is an early-warning deadline, not a requirement to complete an investigation or release a patch within one day. For an actively exploited vulnerability, the clock starts when the manufacturer becomes aware that the product contains a vulnerability for which there is reliable evidence of malicious exploitation without the system owner’s permission. The early warning must be sent without undue delay and, in any event, within 24 hours. Where applicable, it should identify the Member States in which the manufacturer knows the affected product has been made available. For a severe security incident affecting the product, the same 24-hour outer limit applies, and the early warning should at least state whether the incident is suspected of being caused by unlawful or malicious acts, as well as the relevant Member States where applicable.
The 72-hour stage is a fuller notification, but it is still an initial regulatory account rather than a finished forensic report. For an actively exploited vulnerability, the manufacturer should provide available general information about the affected product, the nature of the vulnerability and exploit, corrective or mitigating steps already taken, measures users can take, and an indication of the sensitivity of the information where relevant. For a severe incident, the notification should describe the nature of the incident, provide an initial assessment and set out corrective or mitigating measures taken or available to users. Both deadlines are measured from awareness of the reportable event. Waiting for a CVE identifier, a complete root-cause analysis, a public advisory or a final patch can therefore create avoidable compliance risk if the organisation already has enough evidence to know that Article 14 has been triggered.
There is also a later reporting stage. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. It should describe the vulnerability, including its severity and impact, provide available information about the malicious actor exploiting it, and explain the security update or other corrective measure made available. For a severe incident, the final report is due within one month after the 72-hour incident notification and should cover the incident in detail, its severity and impact, the likely threat or root cause, and mitigation measures applied or still in progress. The designated CSIRT may also request an intermediate status report. Developers should therefore view the 24- and 72-hour stages as the start of a reporting sequence, not as the end of the incident record.
How to Decide Whether a Vulnerability or Incident Must Be Reported
One of the most important distinctions in Article 14 is the difference between a vulnerability that is technically serious and a vulnerability that is actively exploited. The CRA defines an actively exploited vulnerability by reference to reliable evidence that a malicious actor has actually exploited it in a system without permission. A high severity score, a proof-of-concept published by a researcher, a theoretical attack path or a scanner alert does not automatically establish that threshold. Those signals can justify urgent investigation and remediation, but the Article 14 reporting trigger for vulnerabilities focuses on real exploitation. A sensible internal process therefore separates three questions: does the weakness exist in an in-scope product, is there reliable evidence that it has been exploited maliciously, and when did the manufacturer become aware of that evidence?
The incident route is different. Article 14 requires reporting of a “severe incident having an impact on the security of the product with digital elements”. An incident is considered severe where it 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 where it has led, or is capable of leading, to malicious code being introduced or executed in the product or in a user’s network and information systems. This definition means that teams should look at the security effect on the product and its users, not only at whether the company itself suffered an internal security event. A compromise of a build or update process, for example, could become highly relevant if it is capable of affecting code delivered to customers.
Because the reporting clock turns on awareness, companies need a documented method for making and recording the threshold decision. A developer who receives a credible customer report, an abuse team that sees exploitation telemetry and a security researcher who provides evidence may all create information that needs rapid escalation. The organisation should record what was known, when it was known, how the evidence was assessed and who made the reportability decision. This does not mean every alert should be sent to lawyers before engineering can act. It means the technical and compliance tracks should run in parallel. Remediation should continue immediately while a small decision group determines whether the event is an actively exploited vulnerability, a severe incident, both, or neither. A written record is especially useful when the evidence is incomplete at first and the classification changes as the investigation develops.
Evidence Developers Should Preserve During the First Hours
The first hours of an investigation often determine whether the company can meet the legal timetable without sacrificing technical accuracy. Developers and incident responders should preserve the basic product identity, affected versions, distribution channels, suspected vulnerable component, dates and times of relevant observations, and the evidence supporting active exploitation or incident severity. Logs, customer reports, crash data, indicators of compromise, researcher communications and internal test results can all be important, but teams should avoid flooding the reporting process with unverified material. The goal at the early-warning stage is to establish a reliable factual core. It is better to state clearly what is known and what remains under investigation than to delay because every technical detail has not yet been confirmed.
Product inventory is equally important. A vulnerability can be found in a shared dependency that appears in several products, versions or editions, while the reporting duty concerns the manufacturer’s affected products with digital elements. Teams need a way to identify where the component is used, which versions remain in circulation, whether the affected software is still being made available in the EU and which Member States are relevant. This is one reason dependency records and a software bill of materials can be valuable even before the CRA’s broader 2027 obligations apply. They shorten the time between “we have a problem in this library” and “we know which supported products may contain it”. For older products, the challenge can be greater because build systems, repositories, dependencies or staff knowledge may no longer be readily available.
Open-source dependencies require a second line of communication as well. A manufacturer can find that the weakness is not in code it wrote but in a component maintained by another project or supplier. The immediate Article 14 question remains whether the manufacturer’s own in-scope product contains an actively exploited vulnerability or is affected by a severe incident. At the same time, teams should have a responsible process for contacting the component maintainer and coordinating remediation where appropriate. Developers should not assume that an upstream project will make the CRA notification on behalf of every company that embeds its code. Each manufacturer needs to understand its own product, evidence and legal role. This is particularly important for widely reused libraries, where the same underlying flaw may create different levels of exposure and different facts across downstream products.
How to Build a Reporting Process That Works Under Real Incident Pressure
The CRA reporting process is designed so that manufacturers make a single submission through the CRA SRP managed by ENISA. The notification is directed to the CSIRT designated as coordinator for the relevant Member State and is normally made available simultaneously to ENISA. For a manufacturer with a main establishment in the EU, the relevant Member State is generally the one where decisions relating to the cybersecurity of its products are predominantly taken. The Regulation contains further rules for manufacturers without an EU main establishment, so companies operating across several countries should resolve this routing question before an incident occurs. A 24-hour deadline leaves little room for determining during a live breach which entity owns the product or which national CSIRT should receive the report.
ENISA’s August 2026 guidance gives software companies a useful picture of how access to the CRA SRP is expected to work at launch. Assigned representatives authenticate through a personal EU Login account with two-factor authentication; ENISA advises against using a functional mailbox for that registration. A manufacturer can have one Primary Assigned Representative and up to 20 Secondary Assigned Representatives. ENISA also states that validation of the relationship between an assigned representative and the manufacturer is handled by the relevant CSIRT and is not intended to prevent a required notification from being submitted. Because the service is scheduled to become operational by 11 September 2026 and guidance is still being updated, organisations should check the latest ENISA instructions when they prepare or file their first report rather than relying on an old internal screenshot or draft procedure.
Reporting also does not replace communication with affected users. Article 14 requires manufacturers, after becoming aware of an actively exploited vulnerability or severe incident, to inform impacted users and, where appropriate, all users about the vulnerability or incident and any corrective or risk-reduction measures they can take. That customer communication needs to be coordinated with engineering so that instructions are accurate, useful and safe. It also needs to be coordinated with the regulatory submission because premature disclosure of exploit details can create additional risk. The CRA allows sensitive information to be identified as such, and EU rules provide limited circumstances in which dissemination between national CSIRTs can be delayed on cybersecurity grounds. This makes a disciplined disclosure plan more valuable than either secrecy by default or immediate publication of every technical detail.
A Practical Readiness Checklist for Development and Security Teams
Before 11 September 2026, every organisation that may be a manufacturer under the CRA should be able to answer a few operational questions without starting a new legal research project during an incident. It should know which software products are in scope, which legal entity is the manufacturer, who can declare that evidence is sufficient to trigger Article 14, who records the awareness time, who drafts the early warning, who submits it, and who can act if the normal owner is unavailable. The process should include older products, not just current releases, because Article 14 also reaches in-scope products placed on the market before the CRA becomes fully applicable in December 2027. A simple product register with owners, supported versions, EU availability and escalation contacts can remove hours of uncertainty when the deadline is already running.
Teams should also rehearse the 24- and 72-hour sequence using a realistic scenario. A useful exercise begins with a credible report of active exploitation late in the working day, followed by incomplete evidence, an affected third-party dependency and customers in several Member States. The exercise should test whether engineers can preserve evidence, identify affected versions, determine what users can do immediately and produce a concise early warning without waiting for the final root cause. It should then test whether the 72-hour notification can be updated with a clearer product description, exploit information, initial impact assessment and mitigation status. The objective is not to produce a perfect document in advance. It is to make sure that technical triage, legal assessment, management approval, customer communication and submission can happen in parallel rather than in a slow sequence.
Finally, software teams should keep the September 2026 reporting duty separate from the broader compliance programme for December 2027. The CRA will later require a wider set of cybersecurity, vulnerability-handling, documentation and conformity measures, but Article 14 arrives first. That makes reporting readiness an immediate operational priority even for companies that are still working through their longer-term CRA programme. The most useful preparation is practical: maintain a clear product inventory, define the event-classification path, make the awareness time visible, nominate primary and backup reporting owners, prepare short templates for the 24- and 72-hour stages, and connect the reporting process with patching and customer communication. When a real incident occurs, the organisation should already know the trigger, the clock, the responsible people and the evidence it needs to preserve.
