Reporting and Disclosure Obligations in the Cyber Resilience Act

When do vendors need to report what to whom?

TL;DR: Starting on 11 September 2026, the Cyber Resilience Act requires vendors to report exploited vulnerabilities and severe incidents to ENISA through a central reporting platform. Reporting deadlines are tight, vendors must improve their vulnerability and incident handling processes accordingly. They should further review the CSAF standard, as it is likely to become the primary format for reporting vulnerabilities to ENISA.

While much of the discussion (at least on LinkedIn) focuses on NIS2, another EU regulation, the Cyber Resilience Act (CRA), has also entered into force. Parts of the CRA will apply from 11 September 2026. Over the Christmas break, I took the time to read the legal text and derive conclusions on what this regulation means for affected customers.

This blog post focuses on the reporting obligations of the Cyber Resilience Act, which will take effect this year. I will also reference related sections that address vulnerability reporting and security advisories. This post is by far not a comprehensive introduction to the Act. For this, I recommend the eBook Manufacturing European Software and the EU’s FAQ - Cyber Resilience Act implementation.

I am (obviously) not a lawyer, and this blog post does not constitute legal advice. This post includes several quotes from the CRA legal text. I use them mainly to support my assumptions. You can skip them if you want.

Cyber Resilience Act objectives

With the Cyber Resilience Act, the European Union is primarily pursuing the following objectives:

  • Addressing the inadequate level of cybersecurity in many products
    Products should be secure by default. Vendors must provide timely security updates for identified vulnerabilities.

  • Help consumers / business to determine if products are secure
    Users should be able to determine if the used the product up to date or if it contains any known security vulnerabilities.

By forcing vendors to do vulnerability reporting and disclosure the CRA tries to reach the second goal. Vendors should no longer be able to engage in poor security practices as “silent patching”. The Cyber Resilience Act reporting obligations that will apply on 11 September 2026 should help consumers identify issues that require immediate action because they represent active threats.

Reporting obligations, according to article 14

The Cyber Resilience Act entered into force in December 2024 (as an EU regulation, it does not require member-state transposition). Vulnerability reporting obligations apply from 11 September 2026. Full enforcement of all CRA requirements begins on 11 December 2027.

The reporting obligations are described in article 14. It requires that actively exploited vulnerabilies (paragraph 1) and “severe incidents” (paragraph 3) are reported to the ENISA, using a dedicated reporting platform. Let’s first look at the requirement for vulnerability reporting.

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…

Actively exploited vulnerabilities

It is important to note that the regulation refers specifically to actively exploited vulnerabilities. Vendors do not need to report all vulnerabilities in all products to ENISA or a local CSIRT. Vulnerabilities discovered or exercised during penetration tests or red team assessments also do not require reporting. However, the regulation does not distinguish between zero-day vulnerabilities and known issues that were patched months or years ago or affect product versions that are no longer supported. It also includes vulnerabilities in third-party components that were integrated into the product. The CRA defines actively exploited vulnerabilities in Article 3(42).

Paragraph 68 in the “whereas” section provides even more clarity:

Actively exploited vulnerabilities concern instances where a manufacturer establishes that a security breach affecting its users or any other natural or legal persons has resulted from a malicious actor making use of a flaw in one of the products with digital elements made available on the market by the manufacturer. Examples of such vulnerabilities could be weaknesses in a product’s identification and authentication functions. Vulnerabilities that are discovered with no malicious intent for purposes of good faith testing, investigation, correction or disclosure to promote the security or safety of the system owner and its users should not be subject to mandatory notification.

Severe incidents

Vendors now also need to report any severe incident that has a effect on the security of CRA-regulated products. Article 14, Paragraph 3:

A manufacturer shall notify any severe incident having an impact on the security of 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…

The regulation defines a “severe incident” in Article 14, paragraph 5.

For the purposes of paragraph 3, an incident having an impact on the security of the product with digital elements shall be considered to be severe where:

(a) it negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or

(b) it has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product with digital elements.

The key phrase is “capable of”. For example, a compromise in which an attacker gains access to an application’s build environment, among other things, is considered a serious incident, even if there is no evidence of manipulation of builds.

Reporting requirements and deadlines

For both exploited vulnerabilities and severe incidents, the Cyber Resilience Act defines strict deadlines. The following applies to exploited vulnerabilities:

  • Within 24 hours of becoming aware of exploitation, the vendor must submit an early warning notification about the vulnerability to ENISA.
  • Within 72 hours, the vendor must provide details on affected product versions, the nature of the vulnerability, and any applied or available mitigations.
  • Within 14 days, the vendor must submit a full vulnerability description, information about the threat actor (if known) that exploited the vulnerability, and details on security updates or corrective measures.

I assume this information will be included in the “Known Exploited Vulnerabilities” catalog. ENISA already provides this dataset through the EU Vulnerability Database (EUVD).

The deadlines for a severe incident are similar. However, you have more time to submit the final incident report. The deadline is one month instead of 14 days.

In both cases, vendors must use the new central reporting platform to submit reports. At the time of writing, the platform is not yet live. However, we can review the technical specifications in the public tender to get a first idea of the expected system capabilities.

Unfortunately, ENISA currently provides no examples of what it require at each reporting step. Based on the technical specification, I assume they expect CSAF-based advisories (see below).

As a manufacturer, it is important to note that after registration, you will be assigned to a CSIRT based on your country which CSIRT will confirm your registration. Vendor security teams should complete this step in advance to save time when they actually need to submit a vulnerability or incident report.

What about customers?

So far, we have only addressed reporting obligations to ENISA. However, vendors must also inform their customers about the vulnerability and potential mitigations. Otherwise, the responsible CSIRT will attempt to do so (if possible). This requirement is defined in Article 14, paragraph 8:

After becoming aware of an actively exploited vulnerability or a severe incident having an impact on the security of the product with digital elements, the manufacturer shall inform the impacted users of the product with digital elements, and where appropriate all users, of that vulnerability or incident and, where necessary, of any risk mitigation and corrective measures that the users can deploy to mitigate the impact of that vulnerability or incident, where appropriate in a structured, machine-readable format that is easily automatically processable. Where the manufacturer fails to inform the users of the product with digital elements in a timely manner, the notified CSIRTs designated as coordinators may provide such information to the users when considered to be proportionate and necessary for preventing or mitigating the impact of that vulnerability or incident.

It is important to understand that vendors not only need to provide advisories for actively exploited vulnerabilties. They also need to release advisories for known / fixed vulnerabilities, even if these were not actively exploited. However, this must not be reported to ENISA. From the CRA Annex I, Part II (Vulnerability handling requirements).

Manufacturers of products with digital elements shall:…
…(4) once a security update has been made available, share and publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and clear and accessible information helping users to remediate the vulnerabilities; in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security benefits, they may delay making public information regarding a fixed vulnerability until after users have been given the possibility to apply the relevant patch;

This is generally a good thing as it removed the possiblity of “silent patches” for critical vulnerabilities, even if some vendors will strech the “delay” to the max. However this is not part of Article 14 of the Act and will take effect on 11 Dezember 2027.

Streamline vulnerability handling

Due to tight deadlines, vendors need to streamline reporting channels for potential vulnerabilities and security incidents. This includes:

Provide clear guidance on how to report security vulnerabilities and security incidents
In the past, I had to deal with several vendors where I was forced to use standard support or sales channels to report a vulnerability. In the worst case, the report became blocked because I was not representing a customer.

Thus, vendors should provide clear information how to report vulnerabilities. This is actually also mentioned of the Cyber Resiliance Act (whereas section number 76), but is not a requirement.

I recommend the Practical Guide to Vulnerability Handling and Disclosure from the Global CVE Allocation System which provides a good introduction to this topic.

Instruct sales and customer support teams to forward this information to the security team
These teams often interact directly with customers. As a result, they may be the first to receive reports about exploited vulnerabilities and must forward this information to the security team. This applies even if the vulnerability is already fixed, as all exploited vulnerabilities must be reported to ENISA.

Test the vulnerability handling process
The process for handling incoming vulnerability reports should be tested regularly. For example, vendors can use findings from a penetration test to validate the reporting process and ensure it works as intended. Testing should also include the process of reporting the issue to ENISA, preparing the official advisories and informing customers.

CSAF (Common Security Advisory Framework)

While reading the Cyber Resilience Act (and related documents), I had my first direct encounter to the Common Security Advisory Framework (CSAF). In short, CSAF is a JSON-based format for publishing security advisories. It furhter defines ways how to automatically publish and comsume these advisories. CSAF is an international standard, but the German Bundesamt für Sicherheit in der Informationstechnik (BSI) seems to be the key player in developing and promiting it.

The CSAF format appears in several Cyber Resilience Act related documents. For example, the technical specification of the central reporting platform states that vendors must be able to upload data in this format.

Data Exchange Standard: Primarily use CSAF (Common Security Advisory Framework) in JSON format for data exchange.

Vendor Advisories

When discussing security advisories, most security professionals think of the “Common Vulnerability and Exposure” (CVE) program. Its goal is to identify, define, and catalog cybersecurity vulnerabilities. The CVE program also defines a JSON-based record format. So why do we need another format? Because fits better to requirements for vendors.

To start, many vendors did not obtain a CVE-ID for every vulnerability in their products. In the past, the CVE process was complex, especially for teams unfamiliar with it. This situation has improved in recent years due to the growing number of CVE Naming Authorities (CNAs) that can assign CVE IDs. However, it can still take time to receive a CVE ID that you can reference in an advisory.

Another problem that is easier to solve with CSAF based advisories are vulnerabilities in dependencies. Let’s assume that we have a critical vulnerability like CVE-2025-55182 (React2Shell) that affects a large number of products. The CVE JSON format defines an “affected” section to list affected products, but a vendor would need to contact the CNA that assigned the CVE to update that record with a list of their own products. This approach is not practical for vulnerabilities that affect a large number of products. That is why separate databases exist for widespread vulnerabilities such as Log4shell (CVE-2021-44228).

On the other side, users and companies that want to know if they are affected by such a vulnerability, you would spend a lot of time finding such databases. In the worst case, customers might contact vendors to ask if a product is affected as it happend multiple times in the case of Log4shell vulnerability.

CSAF simplifies this process by allowing vendors to publish product advisories that bundle multiple vulnerabilities. The format still lets vendors describe each vulnerability separately and reference CVEs if needed. It further describes clear ways how organizations can automatically get these advisories.

To quote the CSAF FAQ:

CSAF is not a replacement for CVE. A CSAF document may include one or many security vulnerabilities that have been assigned a CVE. Not all vulnerabilities are assigned a CVE. CSAF also allows for any organization to be able to disclose or consume security vulnerabilities or responses that do not have an assigned CVE.

If you want to see what a CSAF-based advisory looks like, I recommend to review the advisories published by Open-Xchange GmbH.

CSAF Profiles and Icident Response

The CSAF standard can not only be used for security advisories as it contains multiple profiles that support different use cases. The profile list includes a Security Incident Response profile which should be used to provide responses to security breaches or incidents. I assume the ENISA reporting platform will require this type of CSAF document when vendors report a severe incident.

Final words

The Cyber Resilience Act introduced additional reporting obligations. These obligations primarily target actively exploited vulnerabilities and severe incidents. Vendors that already take product security seriously should face few challenges. However, now is a good time to review reporting processes and the way security advisories are published.

The key question is how customers will use this information. Even today, we face many well-documented security vulnerabilities but many affected instances or devices remain unpatched. I hope that other parts of the CRA, such as the requirement to provide automatic updates, will help here.

Thanks to Diana Polekhina on Unsplash for the title picture.