The EU Cyber Resilience Act reporting system is approaching a major deadline. From September 11, 2026, manufacturers will have to report certain exploited vulnerabilities and serious security incidents within strict time limits.
This requirement takes effect more than a year before most Cyber Resilience Act rules become applicable. So, businesses cannot leave all their CRA preparation until the end of 2027. Their incident detection, internal escalation and reporting procedures need to work much sooner.
ENISA’s new Single Reporting Platform will offer a central place for submitting CRA notifications. Still, not every software vulnerability, service interruption or attempted attack will require a report. Manufacturers need to understand what qualifies, when the reporting clock starts and which products fall within the rules.
What changes on September 11, 2026?
The Cyber Resilience Act entered into force on December 10, 2024. Most of its requirements will apply from December 11, 2027. These include wider obligations for secure product design, vulnerability management, security updates and conformity assessment.
Article 14 follows an earlier schedule. Starting September 11, 2026, manufacturers must report:
- Actively exploited vulnerabilities in products with digital elements
- Severe incidents affecting the security of those products
ENISA is responsible for running and maintaining the Single Reporting Platform, usually shortened to SRP. The system has gone through functional, security and user testing, with national Computer Security Incident Response Teams taking part in the process.
At launch, the platform will only accept mandatory notifications. Voluntary reporting of other vulnerabilities, cyber threats, incidents and near misses is planned for a later phase.
That distinction is easy to miss. Security researchers and other individuals or organizations may eventually gain access to voluntary reporting tools. However, the first version focuses on reports submitted by manufacturers and covered open-source software stewards.
How the Single Reporting Platform works
The purpose of the SRP is fairly simple. A manufacturer submits one CRA notification through a central platform instead of contacting several national authorities separately.
The company must select the CSIRT designated as coordinator for the relevant EU Member State. In most cases, this will be the country where the main decisions about product cybersecurity are made.
The notification also becomes available to ENISA. The receiving CSIRT can then share it with relevant CSIRTs in other Member States where the affected product is available. Market surveillance authorities may receive the information they need for investigations and enforcement as well.
So, “single reporting” refers to the submission process. It does not mean the report remains with one national authority.
Manufacturers with several European offices, subsidiaries or business units should still submit only one notification for the same event. Of course, that requires good internal coordination. Otherwise, teams may file duplicate reports or provide authorities with conflicting details.
Which products can fall under the CRA?
The Cyber Resilience Act uses the broad term “products with digital elements.” It covers hardware and software made available on the EU market when their intended or reasonably foreseeable use involves a direct or indirect connection to a device or network.
Depending on their design and purpose, covered products may include:
- Routers and mesh Wi-Fi systems
- Smart-home hubs and security cameras
- Connected appliances and IoT devices
- Mobile and desktop applications
- Operating systems
- Network-management software
- Hardware and software components sold separately
- Remote data-processing services required for a product to perform one of its functions
The rules are not limited to traditional computers or enterprise security products. Everyday connected devices can also be relevant. For example, products such as the PETKIT Eversweet Max cordless pet fountain show how digital features and app connectivity now appear in even fairly ordinary household accessories.
However, the scope still depends on the product’s actual functionality, how it reaches the market and whether another EU legal framework applies. Certain medical devices, aviation products, vehicle systems and specialized equipment have separate rules or specific exclusions.
What must manufacturers report?
The CRA divides mandatory notifications into two main categories. Although they can overlap in practice, each category has a separate legal meaning.
Actively exploited vulnerabilities
An actively exploited vulnerability is more than a weakness that someone could theoretically abuse. The manufacturer must have reliable evidence that a malicious actor has already exploited the vulnerability without the system owner’s permission.
For instance, researchers might publish details about a serious remote code execution flaw. That alone does not necessarily make it an actively exploited vulnerability under the CRA. The mandatory reporting threshold is reached when reliable evidence of real exploitation becomes available.
This distinction should prevent the reporting platform from being flooded with every discovered software bug. Even so, companies need a fast way to investigate exploitation claims. Waiting for perfect attribution or a complete technical analysis could cause them to miss the 24-hour deadline.
Severe security incidents
A severe incident is one that seriously affects, or could seriously affect, the security of a product with digital elements.
An incident may qualify when it:
- Negatively affects the product’s ability to protect important data or functions
- Compromises availability, authenticity, integrity or confidentiality
- Introduces malicious code into the product
- Allows malicious code to reach a user’s network or information systems
Manufacturers should assess both the damage that has already occurred and what the incident is realistically capable of causing.
Still, an ordinary outage, harmless bug or unsuccessful automated scan will not automatically qualify as a severe incident. The context, affected functions, product design and potential impact all matter.
The CRA reporting deadlines explained
The reporting process has several stages. Companies can provide basic information quickly, then update the notification as their investigation develops.
| Reporting stage | Deadline | Information expected |
|---|---|---|
| Early warning | Within 24 hours of awareness | Basic event details, affected product and relevant Member States |
| Vulnerability or incident notification | Within 72 hours of awareness | Initial assessment, available technical information and mitigation measures |
| Final report for an exploited vulnerability | No later than 14 days after a corrective or mitigating measure becomes available | Vulnerability details, impact, exploitation information and the available fix |
| Final report for a severe incident | Within one month after the 72-hour notification | Detailed impact, likely root cause and ongoing mitigation measures |
These are maximum time limits. The CRA also requires reporting “without undue delay,” which means businesses should not treat the deadline as a target.
The countdown starts when the manufacturer becomes aware of the vulnerability or incident. That sounds straightforward, but it may become complicated inside a large organization.
A customer might report suspicious behavior to technical support. A monitoring tool could generate an alert during the night. Alternatively, a third-party supplier may inform a product team about exploitation in a shared component.
Businesses need to decide who can officially recognize a reportable event and how the awareness time will be documented. An urgent warning should not remain unnoticed in a forgotten inbox while the reporting window continues to shrink.
The SRP will include reminders and deadline counters. However, companies remain responsible for calculating and meeting the legal deadlines.
Who is responsible for submitting reports?
The manufacturer has the primary Article 14 reporting obligation. Under the CRA, a manufacturer can be a company that develops a product, manufactures it or has it developed and then markets it under its own name or trademark.
That definition can also cover software provided free of charge when it forms part of a commercial activity or monetization model.
Importers and distributors should not automatically assume that the original manufacturer carries every obligation. An importer or distributor may be treated as the manufacturer if it:
- Sells a product under its own name or trademark
- Makes a substantial modification to an existing product
- Changes the product in a way that affects its cybersecurity compliance or intended purpose
Certain open-source software stewards also have tailored reporting responsibilities. These are legal entities that provide sustained support for particular open-source projects intended for commercial use and play a central role in keeping those projects viable.
This does not mean every volunteer developer becomes legally responsible for CRA reporting. Individual contributors to independent, non-commercial open-source projects do not automatically become manufacturers or open-source software stewards.
Older products can still trigger reporting duties
One of the most overlooked parts of the reporting rules concerns products already available on the market.
The September 2026 obligations can apply to products placed on the EU market before the main CRA requirements begin in December 2027. Therefore, companies should not limit their incident-reporting procedures to newly launched or fully CRA-compliant products.
Manufacturers do not generally have to submit retrospective notifications for exploitation they already knew about before September 11, 2026.
However, the reporting duty can apply if the manufacturer becomes aware of active exploitation after that date. This remains true even if the underlying vulnerability was discovered earlier or exists in an older product.
In practical terms, manufacturers need a reasonably accurate inventory of their supported products, versions, markets and third-party components. Without that information, it may be difficult to identify affected users or determine where a product was made available.
Accessing and registering for the SRP
People who submit reports through the platform will need individual EU Login accounts. Multi-factor authentication must also be enabled.
ENISA refers to these platform users as Assigned Representatives. A manufacturer can have one Primary Assigned Representative and as many as 20 Secondary Assigned Representatives.
The primary user manages the manufacturer’s platform profile. They can also invite or remove secondary users. Having backup representatives makes sense, especially for incidents that happen overnight, during holidays or when the usual security contact is unavailable.
The association between an Assigned Representative and a manufacturer must be validated by the relevant CSIRT. Still, that validation takes place alongside the reporting process. A pending validation should not prevent an urgent notification from being submitted.
ENISA currently recommends creating the manufacturer association when there is a report to submit instead of registering pre-emptively. Even so, companies can prepare by creating EU Login accounts, enabling multi-factor authentication and selecting their primary and backup representatives.
The first version of the SRP will not offer an application programming interface. Businesses can automate their internal monitoring, evidence collection and incident workflows, but someone will still need to enter the report through the platform interface.
For larger manufacturers, this manual step deserves some thought. A single employee should not become the only person capable of meeting a legal deadline.
What manufacturers should prepare now
A long policy document is not enough. Companies need a reporting workflow that still functions during a stressful security incident.
A practical preparation checklist should include the following steps:
- Map the product portfolio. Identify potentially covered products, versions, components, cloud dependencies and markets.
- Determine the relevant CSIRT. Establish where decisions about product cybersecurity are mainly taken.
- Define the awareness trigger. Decide which event starts the reporting clock and who records the time.
- Create clear triage criteria. Security teams should understand the difference between a vulnerability, an actively exploited vulnerability and a severe incident.
- Choose primary and backup reporters. Create EU Login accounts and enable multi-factor authentication in advance.
- Prepare basic product information. Keep product names, versions, manufacturer details and market information easy to access.
- Connect technical, legal and communication teams. A report may require input from several departments, but the 24-hour warning cannot wait for a complete forensic investigation.
- Plan customer notifications. Manufacturers must also inform affected users and provide practical mitigation or corrective measures where necessary.
- Review other legal duties. A CRA notification should not automatically be treated as satisfying separate reporting requirements under NIS2, data-protection law or sector-specific regulations.
- Record decisions not to report. If a company decides that an event falls below the CRA threshold, it should preserve the supporting evidence and reasoning.
Will confidential vulnerability information remain protected?
Manufacturers may understandably worry about sharing information about an unpatched vulnerability across several EU authorities.
The SRP must use suitable technical and organisational safeguards. Under normal circumstances, the receiving CSIRT shares the notification with other relevant national CSIRTs without unnecessary delay.
However, dissemination may be delayed in exceptional circumstances when genuine cybersecurity reasons justify it. This could apply during a coordinated vulnerability disclosure process if wider circulation would create an additional security risk.
Manufacturers can mark information as sensitive and raise exceptional circumstances in the report. The receiving CSIRT will then decide whether delaying wider dissemination is justified.
This option is not intended to hide uncomfortable incidents or delay public scrutiny. It is reserved for unusual cases where sharing the information too quickly could make the security problem worse.
Submitting an SRP report does not automatically publish the vulnerability. However, a CSIRT may inform the public, or ask the manufacturer to do so, when public awareness is necessary to prevent or reduce the impact of a severe incident.
What happens if the platform is unavailable?
The reporting system itself may occasionally become unavailable. If that happens, ENISA advises manufacturers to wait until the service returns and then submit the notification through the SRP.
If urgent communication cannot wait, the manufacturer may contact its designated CSIRT directly. Even after doing so, the formal notification must still be entered into the Single Reporting Platform once it becomes available again.
Incident-response plans should therefore contain up-to-date contact information for the appropriate national CSIRT. Companies should also keep records of failed submission attempts, timestamps and any information sent outside the platform.
What are the possible penalties?
Failure to comply with Article 14 can fall under the CRA’s highest administrative fine category.
The maximum penalty may reach €15 million or 2.5% of the company’s total worldwide annual turnover from the previous financial year, whichever amount is higher.
Actual enforcement will depend on national procedures and the circumstances of each case. Authorities must consider factors such as the seriousness and duration of the infringement, the size of the company and any previous similar violations.
The regulation also provides special treatment in some situations. For example, microenterprises and small enterprises are protected from financial penalties specifically for missing the 24-hour early-warning deadline. Open-source software stewards also follow a separate penalty approach.
Even so, fines are only part of the risk. A missed notification may expose wider problems with vulnerability management, internal ownership or product tracking.
Why this launch matters
The September deadline turns the Cyber Resilience Act from a future compliance project into an immediate operational responsibility.
Manufacturers will need to recognize reportable events, identify affected products and prepare accurate information within a very short period. That will test internal communication just as much as technical security.
For consumers, the system should improve coordination between manufacturers, ENISA and national cybersecurity teams. It may also help authorities spot recurring risks across different product categories and Member States.
Still, the platform cannot fix insecure products on its own. Fast reporting only becomes useful when manufacturers also release patches, explain the risk clearly and support their products for a reasonable period.
September 11, 2026, is therefore more than the launch of another EU reporting portal. It is the first major operational test of the Cyber Resilience Act and a fairly revealing one for Europe’s digital-product industry.
