From September 2026, organisations that develop, manufacture, or place software and connected products on the European Union market will be required to have formal processes in place for identifying, managing, and reporting cybersecurity vulnerabilities and security incidents.
The Cyber Resilience Act introduces mandatory reporting obligations for manufacturers when they become aware of vulnerabilities that are actively being exploited or when a serious cybersecurity incident affects their products. These requirements are intended to improve the overall security of digital products and ensure that threats are communicated quickly to the relevant authorities.
A vulnerability does not automatically become reportable simply because it has been discovered. Many vulnerabilities are identified through internal testing, customer feedback, security assessments, penetration tests, or responsible disclosure by security researchers. In these situations, the organisation should investigate, assess the risk, and develop remediation plans. Reporting to authorities is generally required when there is evidence that the vulnerability is being actively exploited or when a significant cybersecurity incident has occurred.
To support compliance, organisations should establish a documented vulnerability management process. This process should include procedures for receiving reports, assessing severity, investigating potential impacts, tracking remediation activities, and determining whether regulatory reporting obligations apply.
A key requirement is ensuring that customers, researchers, suppliers, and other interested parties have a clear way to report security vulnerabilities. Organisations should therefore provide a dedicated vulnerability reporting channel that is easy to locate and use. This may consist of a dedicated email address such as [email protected], a web-based reporting form, or a vulnerability disclosure portal. The reporting mechanism should be publicly available and referenced within the organisation’s security or privacy documentation.
Maintaining this information creates an audit trail demonstrating compliance and supports rapid reporting if active exploitation is later identified.
The vulnerability reporting process should clearly explain what information should be provided by the reporter. Useful information includes the affected product, software version, description of the issue, steps required to reproduce the vulnerability, supporting evidence, and contact details for follow-up communication. Providing guidance to reporters helps improve the quality of submissions and reduces investigation time.
When receiving a vulnerability report, the manufacturer should record at minimum:
- Date and time received.
- Reporter contact information.
- Product name and version.
- Description of the vulnerability.
- Evidence or proof of concept.
- Severity assessment.
- Whether exploitation is suspected or confirmed.
- Remediation status.
- Customer notification status.
- Regulatory reporting status.
In addition to providing a reporting mechanism, organisations should publish a Vulnerability Disclosure Policy. This document should explain how reports are handled, expected response times, how researchers can communicate securely with the organisation, and how the organisation will coordinate remediation and disclosure activities. A published policy demonstrates a commitment to responsible vulnerability management and supports compliance with the Cyber Resilience Act.
All reported vulnerabilities should be formally recorded and tracked. Organisations should maintain records including the date received, reporter details, affected products, severity assessment, investigation status, remediation actions, customer communications, and any regulatory notifications. Maintaining accurate records provides evidence of compliance and supports future audits or regulatory reviews.
Where a vulnerability is confirmed to be actively exploited, the organisation must be prepared to escalate the issue rapidly. Internal procedures should define who is responsible for assessing reportability, communicating with regulators, notifying customers, and coordinating technical remediation activities. Clear roles and responsibilities are essential because reporting deadlines under the Cyber Resilience Act are measured in hours and days rather than weeks.
Customer communication is also an important aspect of vulnerability management. If users need to install updates, apply mitigations, change configurations, or take other actions to reduce risk, the organisation should provide timely and clear security advisories. Customers should be informed through established communication channels such as customer portals, email notifications, support systems, or product update mechanisms.
To prepare for September 2026, organisations should review their existing vulnerability management capabilities and identify any gaps. Particular attention should be given to vulnerability disclosure processes, incident response procedures, reporting workflows, record keeping, customer notification processes, and regulatory reporting responsibilities.
By implementing a structured vulnerability disclosure program, maintaining clear reporting channels, and establishing documented escalation procedures, organisations will be better positioned to meet their obligations under the Cyber Resilience Act and demonstrate a proactive approach to cybersecurity risk management.
Reporting Timescales (Mandatory from 11 September 2026)
If you become aware that a vulnerability in your product is being actively exploited, or a severe security incident has occurred, the following deadlines apply:
| Requirement | Deadline |
|---|---|
| Early Warning | Within 24 hours of becoming aware |
| Detailed Notification | Within 72 hours of becoming aware |
| Final Vulnerability Report | Within 14 days after a corrective measure (fix or mitigation) becomes available |
| Final Incident Report | Within 1 month after the detailed notification |
These reports are submitted through ENISA’s Single Reporting Platform, which forwards them to the appropriate national CSIRT and ENISA.
What Starts the Clock?
The clock starts when your organisation becomes aware that:
- A vulnerability is being actively exploited “in the wild”.
- A severe security incident has occurred that impacts the security of your product.
Practical Expectations
Although the CRA does not mandate repair times, regulators would likely expect organisations to define internal targets based on risk, for example:
| Severity | Typical Internal Target |
|---|---|
| Critical / Actively Exploited | Immediate action, often within hours or days |
| High | Days to a few weeks |
| Medium | Weeks to a few months |
| Low | Planned maintenance cycle |
These are industry practices rather than CRA requirements.
Requirements of CRA Article 14 that become enforceable on 11 September 2026.
