The Cyber Resilience Act (Regulation (EU) 2024/2847) defines security requirements for products with digital elements and requires vendors to report to national CSIRTs if a vulnerability in one of their products is actively exploited.

This reporting is done via a “Single Reporting Platform” (as defined in Article 16), which is currently being built by ENISA – after multiple rounds of consultations with the CSIRTs Network.

One interesting aspect is Article 16(2) which states:

After receiving a notification, the CSIRT designated as coordinator initially receiving the notification shall, without delay, disseminate the notification via the single reporting platform to the CSIRTs designated as coordinators on the territory of which the manufacturer has indicated that the product with digital elements has been made available.

But also:

In exceptional circumstances and, in particular, upon request by the manufacturer and in light of the level of sensitivity of the notified information as indicated by the manufacturer under Article 14(2), point (a), of this Regulation, the dissemination of the notification may be delayed based on justified cybersecurity-related grounds for a period of time that is strictly necessary […]

Article 14(9) expands on this and states:

By 11 December 2025, the Commission shall adopt delegated acts in accordance with Article 61 of this Regulation to supplement this Regulation by specifying the terms and conditions for applying the cybersecurity-related grounds in relation to delaying the dissemination of notifications as referred to in Article 16(2) of this Regulation. The Commission shall cooperate with the CSIRTs network established pursuant to Article 15 of Directive (EU) 2022/2555 and ENISA in preparing the draft delegated acts.

Thus, the EU Commission needs to come up with a set of criteria for us that define when it makes sense to delay passing on a vulnerability notification to peer CSIRTs. Additionally, the Commission needs to talk to us, so it makes sense for us to think about this.

So, which criteria would be useful to have? Let’s pick a few ideas and discuss them.

Keep in mind that we’re talking about passing on the information to other CSIRTs in the CSIRT’s Network, and not about publishing the information. This makes a huge difference. This leads us to the first reason:

• If there are serious doubts about the trustworthiness of a CSIRT, e.g., because they have a live security incident there or there have been unresolved information leaks there, then it makes sense to cut that team out of the sharing circle.

In our daily CSIRT work, sharing information is not a binary decision. It’s rarely “all info without any restrictions” or “no sharing at all”. There is a lot of grey between those extremes. On one dimension, it’s about what you share. Sometimes we withhold information, because it’s not necessary for the receiving CSIRT to accomplish its mission, or we want to protect our sources or the identity of the initial victim. Sharing exploit code is often not needed, so why do it? And the other dimension is information usage and handling restrictions tagged on the information being shared. For this purpose, PAP (Permissible Actions Protocol) markings and TLP (Traffic Light Protocol) markings are applied. For example, we might want to share details of a simple proof-of-concept exploit that can be fashioned into a scanning oracle to find vulnerable systems to all other CSIRTs: that way they can identify which constituents they need to urgently warn about the vulnerability. But passing that scanning script to malicious actors could quickly lead to mass exploitation. This is a perfect example for sharing under TLP:AMBER+STRICT.

One way to formulate this is:

• Do not share the vulnerability notification if the inherent risks of sharing cannot be mitigated by placing restrictions on the handling and onward sharing of the notification by using PAP (Permissible Actions Protocol) and TLP (Traffic Light Protocol) markings.

This mitigates any fear that the notification might enable the receiver to create an exploit. Thus, anything like “this information is too sensitive” should not be an excuse not to disseminate.

The next reason I can think of is that the vulnerability notification as received via the SRP does not provide additional useful information to what is already available in the CSIRTs Network. E.g., by writing

• Dissemination can be delayed if all information needed for the relevant CSIRTs to advise and protect their constituency has been shared independently of the vendor notification.

Or the notification could be part of a high-stakes incident response which has been classified under national law. That might legally preclude the CSIRT from discussing aspects of this case with foreign teams. E.g.,

• If the vulnerability notification is tied to an incident of national security concerns, then the dissemination can be delayed.

On the other hand, I don’t think that pure timing concerns are a valid reason for a delay. We’ve been fooled way too often by a vendor’s “We’ll release our public advisory tomorrow.” to believe those promises in the first place, and to think an imminent public advisory is a valid reason to delay sharing anyway.

Summary

The CSIRTs Network is a trusted group of security teams, sharing even highly sensitive information works, because dealing with TLP-tagged data is our daily business.

Which leaves basically two reasons not to share the original notification: 

• There is a known problem with the security of a CSIRT
• Dissemination is not needed because sufficient information has already been passed around