While the full implementation of the Cyber Resilience Act (CRA) won’t take effect until December 2027, another critical milestone is already approaching much sooner. Starting from 11 September 2026, all manufacturers selling products with digital elements in countries of the European Union will be required to report actively exploited vulnerabilities in their digital products, as well as related security incidents, as well as security incidents that affect or compromise products already placed on the market.
Incidents or vulnerabilities limited to development or internal environments are therefore only relevant if they result in (or could result in) a compromise of production devices.
Although the platform itself is not yet available, the landmark legislation has already established a detailed framework and set of requirements. This article aims to summarize the most important aspects of the reporting process in order to help you prepare for these upcoming changes. Additionally, it provides clear guidelines for determining when a vulnerability or incident becomes mandatory to report.
Overview
In Chapter I, Article 14, ยง1, the Cyber Resilience Act states the following:
A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA.
In the context of the CRA, an “actively exploited vulnerability” is defined as a “vulnerability for which there is reliable evidence that it has been abused by a malicious actor in a system without permission of the system’s owner.”
Put simply, manufacturers must publish a public report as soon as they become aware of a vulnerability in their products being actively abused. This could be, for example, a flaw in the authentication mechanism that allows attackers to access or modify data of other users.
Security incidents affecting a manufacturer’s development, production, or maintenance processes (e.g., a compromise of the software update release channel) must also be addressed in the same way. An example scenario would consist of attackers being able to compromise the firmware repository, inject malicious code into the system, which is then transferred and executed on users’ devices.
However, if a vulnerability is instead discovered during a security audit, internal inspections or other non-malicious means, it does not fall under mandatory reporting.
Reports must be submitted via a centralized reporting platform to the national CSIRT (Computer Security Incident Response Team) as well to ENISA, the European Union Agency for Cybersecurity.
When to report a vulnerability?
The process begins the moment a vulnerability is discovered in a product with digital elements, whether identified internally or via an external notification. Whether or not mandatory reporting is required is determined by the following decision logic:
The process starts as soon as a possible a flaw is identified, either by the manufacturer themself or by an external party.
- Is it exploitable? A manufacturer must first determine if the vulnerability can effectively be abused by malicious actors under practical operational conditions. If it cannot be exploited in practice (for example, if it only exists in a controlled testing environment), reporting is not required.
- Is it actively exploited? If the vulnerability is exploitable under practical conditions, manufacturers must look for evidence of abuse.
- Is there reliable evidence that it has been exploited by malicious actors?
NO: Reporting is not required.
YES: Reporting is mandatory under the CRA.
Even if reporting is not mandatory, either because the vulnerability is not exploitable or no evidence of abuse was found, vendors may still choose to submit a voluntary report. The CRA guarantees that voluntary reporting will not impose any additional legal obligations on the vendor in this case.
When to report a security incident?
According to the CRA, any “severe incident having an impact on the security of the product with digital elements” is subject to mandatory reporting.
Generally, an “incident” is defined as “any event that compromises the availability, authenticity, integrity or confidentiality of either stored, transmitted, or processed data, or of the services offered by, or accessible via, network and information systems“. In other words, any event that disrupts, modifies or steals information or services is regarded as an incident.
The additional description “having an impact on the security of the product with digital elements” focuses strictly on a specific product. Instead of the company itself, the CRA only covers security incidents that directly affect the digital product in such a way that it is no longer able to keep sensitive data and its functions secure, reliable and private.
Finally, a security incident is categorized as severe if it falls into one of the following two scenarios:
- The product is no longer able to protect sensitive data or important functions.
- Attackers are able to execute malicious code on the product itself or use the device to execute malicious code on the user’s network.
At Compass Security, we interpret sensitive data as data where a compromise has meaningful security consequences, for example logon information, authentication secrets, cryptographic keys, personal data, confidential user data, security configuration or similarly protected information.
Important functions are those whose loss or manipulation would have a significant impact on the product or its security. Examples include access control, firmware verification, safety-related controls, configuration management, communication and the availability of core services and other essential product functionality.
The Reporting Process
The reporting process consists of three stages, triggered immediately after a manufacturer becomes aware of an exploited vulnerability or a severe security incident.
Early Warning
As soon as an exploited vulnerability or an incident becomes known, an early warning must be submitted within 24 hours. While technical details are not required at this stage, the countries in which the affected product is available must be indicated.
Full Notification
Within 72 hours, the early warning must be extended to a full notification that provides more information about the vulnerability or incident. This includes general information about the affected product, describing the nature of the vulnerability and how it is being exploited. It should also indicate any mitigation steps already taken. If applicable, it should also detail measures that affected users can implement to remediate the vulnerability themselves, such as disabling certain features.
Post Mortem
A final report must be published no later than 14 days after a patch has been implemented and released. This report must contain a description of the vulnerability, along with its severity and impact rating. If available, it should also include information about the extent of the exploitation. Additionally, it should also detail the security updates and any other steps taken to remedy the situation.
The final report for a security incident must be published within one month of the initial report. Unless it has already been provided, the report must contain a detailed description of the incident, including its severity and impact. It should also explain what triggered the incident and describe all mitigation measures.
Where to report?
Reports must be submitted to the following entities, which is done via the centralized platform:
- ENISA: The European Union Agency for Cybersecurity.
- CSIRT: The designated national Computer Security Incident Response Team.
Once the platform is ready for use and more information is available, the exact process will be described in a follow-up article.
Manufacturers should also inform their users directly about vulnerabilities and incidents, for example by publishing relevant information on their websites. If the severity of the vulnerability or incident justifies it, and if a means of contact is available, manufacturers could also reach out to their users directly to inform them of the issue and any necessary mitigation measures.
Prevention, Detection, Reaction
Rather than treating the CRA as a purely reactive legal obligation, manufacturers should integrate it into a proactive security strategy based on three central pillars: prevention, detection and reaction.
Prevention
The most effective way to manage the reporting requirements is to minimize the vulnerabilities and attack surfaces that trigger them in the first place. Frequent security testing helps reduce the overall risk of vulnerabilities. This should include continuous, automated vulnerability scanning as part of the build pipeline, or even periodic penetration testing.
Overall, security must be treated as a core design requirement (“security by design”) rather than an afterthought. All system components should adhere to the principle of least privilege and implement strong authentication mechanisms. Moreover, the product should be hardened so that no unnecessary services or ports are exposed.
Besides technical measures to harden the product, there are several things to implement on the organizational side as well. By implementing fixed processes and guidelines and conducting regular risk assessments to achieve a high level of maturity, sporadic and isolated checks can be transformed into a secure product development lifecycle.
Detection
Once a product has been deployed, centralized logging and audit trails are essential for identifying irregular and malicious behavior in the wild. In case a vulnerability is discovered, the ability to determine whether it has already been exploited, and thus to determine whether reporting is mandatory, depends on the quality of the available forensic data.
Reaction
To ensure an effective reaction, organizations should maintain an incident response handbook and standardized reporting templates. Having such reporting templates and response procedures ready in advance ensures that the mandated time windows for an early warning and full notification can be met. Ultimately, incident responses should be defined and regularly drilled. By turning it into a routine, teams can focus their energy on handling the actual situation rather than managing the administrative chaos behind the scenes.
However, immediate responses should be complemented by long-term support. In particular, secure update channels should be maintained and documented support provided throughout the product’s expected lifespan.
References
Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act):
https://eur-lex.europa.eu/eli/reg/2024/2847/oj
Summary of the CRA:
https://digital-strategy.ec.europa.eu/en/policies/cra-summary
ENISA Single Reporting Platform:
https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp
Leave a Reply