The CRA's September 11 Reporting Deadline: What to Report, When, and Where
| Interlynk
The first binding requirement under the EU Cyber Resilience Act takes effect on September 11, 2026. Here is who it applies to, what companies must report, and how the reporting process works.
Overview
Most of the Cyber Resilience Act will not apply until December 11, 2027. One important requirement arrives much earlier.
From September 11, 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents to EU authorities within hours.
This is the CRA's first firm deadline, and it covers products that are already on the market, not just products that launch after the deadline. This guide explains who is covered, what triggers a report, how quickly a company must act, where the report goes, and the two related duties that are easy to miss.
CRA Reporting at a Glance
Starting September 11, 2026, Article 14 requires manufacturers to report an actively exploited vulnerability or a severe incident in an in-scope product to the coordinating national CSIRT and ENISA through a single platform. The process has three stages: an initial warning within 24 hours, a more complete notification within 72 hours, and a final report within 14 days after a corrective measure becomes available. For a severe incident, the final report is due within one month after the incident notification. The requirement applies to products already placed on the EU market. Penalties for non-compliance can reach 15 million euros or 2.5 percent of worldwide annual turnover.
Legal Basis: Article 14 and the September 11 Deadline
The CRA is formally known as Regulation (EU) 2024/2847 [1]. It entered into force in December 2024 and will apply in full from December 11, 2027. The reporting obligation starts earlier, on September 11, 2026, under Article 14. This gives regulators early visibility into exploited weaknesses in digital products before the rest of the framework takes effect.
That distinction is important because it is often misunderstood. Article 14 creates a separate, time-sensitive reporting duty. The broader vulnerability-handling requirements in Annex I, together with conformity assessment, technical documentation, and CE marking, are addressed in Article 13 and generally apply from December 2027. A manufacturer does not need to be close to full CRA compliance to be subject to Article 14. If the reporting duty applies, the clock starts in September 2026 regardless of how far along the rest of the compliance program is.
Who Is in Scope
The obligation applies to manufacturers of products with digital elements. That is a broad category. It includes software, hardware, remote data-processing solutions, and software or hardware components that are placed on the market separately. The CRA applies across sectors to products made available in the EU, although some product categories are covered by other EU rules and are excluded.
Two details can bring a company within the rule sooner than expected.
Products already on the market count. Under Article 69(3), the reporting duty covers in-scope products that were already on the EU market before the deadline. It is not limited to products placed on the market after September 11, 2026. If a product shipped several years ago is still being sold or supplied in the EU, it may still fall within the Article 14 perimeter. Companies need reliable records showing what they shipped, which versions are involved, and where those products were made available.
Manufacturers outside the EU are not automatically exempt. If a company based outside the EU sells products into the European market, the obligation can reach it through its authorized representative, importer, or distributor. Selling from outside the EU does not, by itself, remove the reporting responsibility.
What Must Be Reported
Article 14 focuses on two specific situations. It does not require a report for every CVE or every security issue.
An actively exploited vulnerability. This means a vulnerability in the product that a malicious actor has discovered and is exploiting in the real world. The trigger is evidence of actual exploitation, not simply a theoretical possibility. A high CVSS score, a publicly available proof of concept, or an ordinary vulnerability disclosure does not automatically start the reporting clock. The evidence must indicate that the vulnerability is being exploited in the product.
A severe incident. This is a security incident that has, or could have, a significant effect on the security of the product or its users.
The European Commission's July 27, 2026 guidance adds two useful points [3].
First, the phrase "becoming aware" has a specific meaning. The clock starts after an initial assessment gives the manufacturer a reasonable degree of certainty that a vulnerability in its product is being actively exploited or that a severe incident has taken place. A rumor or unverified tip does not automatically start the clock at the moment it arrives.
Second, third-party vulnerabilities depend on whether the affected code can be reached and is being exploited in the product. If an actively exploited vulnerability comes from a component that you integrated, an Article 14 report is required when that vulnerability is being actively exploited in your product. If the vulnerable code is not reachable or is not being exploited in your product, an Article 14 report is not required on that basis, although other upstream and vulnerability-handling duties may still apply. Making this determination quickly requires an accurate component inventory and a way to identify whether the affected code is reachable.
The Reporting Timeline
Article 14 sets out a three-step reporting process. The first two steps are the same for an actively exploited vulnerability and a severe incident. The timing of the final report differs.
Stage | Deadline | What it contains |
|---|---|---|
Early warning | Within 24 hours of becoming aware | Notice that an actively exploited vulnerability or severe incident exists |
Full notification | Within 72 hours of becoming aware | A fuller technical assessment, including corrective or mitigating measures taken |
Final report | Within 14 days after a corrective measure becomes available for a vulnerability, or within one month for a severe incident | Details of the vulnerability or incident, any malicious actors involved, and the steps being taken to correct it |
The final-report deadline for a vulnerability is easy to misread. The 14-day period begins when a corrective or mitigating measure becomes available. It does not begin when the manufacturer first becomes aware of the vulnerability. For a severe incident, the final report is due within one month after the incident notification. These are short windows, so the reporting process needs to be ready before an incident occurs. There will not be enough time to design it from scratch during an active response.
Where and How to Report
Reports will be submitted through the CRA Single Reporting Platform, or SRP. ENISA is required to establish the platform under Article 16 and have it operational by September 11, 2026 [2]. A testing period is expected beforehand.
The process is designed around a single submission. The manufacturer reports to the coordinating CSIRT, which is the CSIRT associated with the manufacturer's main establishment in the EU. The notification is also made available to ENISA through the platform. For follow-up reports, the manufacturer can continue working through the same coordinating CSIRT. There is no need to send separate notifications to every EU member state.
Because the platform is being rolled out as the deadline approaches, companies should check ENISA's current SRP page and the European Commission's CRA reporting page for the latest registration and submission instructions. Do not rely on an older description of how the platform works.
The Obligations Teams Miss
Authority reporting is only part of the response. Two additional duties are easy to overlook.
Notify the component manufacturer or maintainer. If an actively exploited vulnerability in your product comes from a third-party component, you must notify the manufacturer or maintainer of that component. In products built from many libraries and modules, this makes your component inventory an operational contact list as well as a record of what is in the product.
Notify users. Once you become aware of an actively exploited vulnerability or a severe incident, you must inform affected users, and where appropriate all users, about the issue and the corrective measures they can take. The notification must happen without undue delay. If the manufacturer does not notify users, the CSIRT may do so directly.
Both duties depend on the same basic capability as the authority report: knowing what is in each product, which versions are affected, and who needs to be contacted.
Practical Steps Before September 11
The reporting requirement is narrow, but the response time is not forgiving. Before September 11, a company should be able to answer one question quickly: if a vulnerability is being exploited, which of our products and versions contain it, and who needs to be told?
Confirm your scope. Make a list of the products with digital elements that you have placed on the EU market, including older products that are still in use or still being sold. Legacy products can be in scope.
Maintain a current SBOM for each product. The 24-hour and 72-hour deadlines are difficult to meet if you cannot identify your components and match them to the exploited vulnerability. A current SBOM can make the difference between a same-day response and a frantic manual investigation.
Connect exploit monitoring to your inventory. Active exploitation is different from theoretical risk, and only active exploitation starts this reporting clock. Threat intelligence should connect to your component inventory so a credible signal can be mapped to affected products quickly.
Prepare the notification paths. Draft templates for the authority report, the notification to the upstream component manufacturer or maintainer, and the user notice. The writing should not begin with a 24-hour deadline already running.
Assign clear ownership. Decide who determines that the company is aware of a reportable event, who submits the SRP report, and who contacts users. The regulation assumes that these responsibilities have been assigned.
The vulnerability-handling requirements in Annex I do not become binding until December 2027, so a complete CRA vulnerability-management program is not required by September 2026. What is required is the ability to identify exploitation, find the affected products through their components, and report within the required time limits.
The Bottom Line
September 11, 2026 will be the CRA's first real test, and it comes more than a year before the regulation applies in full. The reporting requirement is limited to actively exploited vulnerabilities and severe incidents, but the response times are demanding.
The practical challenge comes down to visibility. Companies need to know what is inside their products, across every version still on the market, and they need to answer exposure questions in hours rather than days. Teams that treat their SBOMs as live operational data will be in a much better position to report on time. Teams that treat an SBOM as a document created once and filed away may still be rebuilding their inventory when the clock is running.
For the requirements that arrive when the CRA applies in full, including the BSI TR-03183 SBOM fields, see our guide to SBOM requirements for the CRA.
Interlynk helps manufacturers maintain audit-ready SBOMs with every build, monitor vulnerabilities throughout the product lifecycle, and answer questions such as "which products and versions contain this component" in minutes. Generate SBOMs in CycloneDX or SPDX, keep them current, and be ready to respond on the CRA's timeline. Learn more about our Cyber Resilience Act solution. Trusted by security and compliance teams at more than 100 regulated companies.
This guide reflects the CRA text, Regulation (EU) 2024/2847, and the European Commission's non-binding application guidance dated July 27, 2026. It was prepared for accuracy at the time of publication. Platform mechanics and official guidance may change before the deadline. Confirm current details on ENISA's Single Reporting Platform page and the European Commission's CRA reporting page, and consult your own legal counsel. This article is for informational purposes only and is not legal advice.
References
Regulation (EU) 2024/2847, the Cyber Resilience Act (EUR-Lex): https://eur-lex.europa.eu/eli/reg/2024/2847/oj
ENISA, Single Reporting Platform (SRP): https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp
European Commission, Cyber Resilience Act, reporting obligations: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting