Deep Dive - CRA Requirement (4) Notification for Security Updates & Vulnerability Disclosure

The fourth vulnerability-handling requirement under the EU Cyber Resilience Act (CRA) focuses on transparency once a security update has been released. Annex I of the CRA states:

“(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 requirement goes beyond fixing vulnerabilities by also ensuring that users and stakeholders are informed about what has been fixed, why it matters, and how they can take action. While some exceptions exist to avoid exposing users to active exploitation, the default expectation is clear: public disclosure is the norm, not the exception.

What this requirement means

Think of this requirement as the digital equivalent of a product recall notice. If a car manufacturer replaces a faulty airbag, they don’t just fix it quietly; they inform the public which models are affected, why it’s dangerous, and how owners can address it. The CRA brings the same logic to digital products.

Manufacturers must provide clear descriptions of the vulnerabilities that have been fixed. They are also required to identify the affected products, versions, or configurations so that users can determine whether they are impacted. In addition, manufacturers must share information about the severity and potential impact of each vulnerability. They must also offer actionable guidance to help users apply patches and mitigate risks effectively. At the same time, the CRA acknowledges that immediate publication of such information is not always safe. If disclosing details would expose users to greater risk before they have had sufficient time to install the fix, manufacturers are permitted to delay disclosure, but only temporarily and with properly justified reasoning.

Relevant Standards and Guidelines

Although the CRA does not prescribe specific disclosure standards, several frameworks can support this requirement:

• EN ISO/IEC 29147: provides guidelines for vulnerability disclosure, covering how to communicate information such as severity, impacts, and remediation steps. It is central but does not prescribe exact timelines or formats.

• EN ISO/IEC 30111: outlines processes for handling vulnerabilities in software, including resolution and public disclosure, but does not extend fully to hardware or non-software components.

• ETSI EN 303 645, focused on consumer IoT, references ISO/IEC 29147 and provides a general framework for IoT vulnerability disclosure, though timelines remain broad.

• EN IEC 62443-4-1: (for industrial automation and control systems) includes Requirement DM-5 on timely disclosure of security issues, tailored to the industrial domain.

Taken together, these standards offer strong foundations, but gaps remain in defining exact disclosure timelines, industry-agnostic formats, and processes for non-software products. To address this, manufacturers should combine these standards with best practices such as publishing CVE identifiers, aligning with the NIST National Vulnerability Database (NVD), and leveraging initiatives like FIRST’s VRDX SIG to ensure consistent, high-quality disclosures across ecosystems.

How to approach Implementation

To implement this requirement effectively, manufacturers should begin by adopting a clear disclosure policy that defines how and when vulnerability information will be communicated, including escalation paths and any exceptions. They should use standardized identifiers such as CVE IDs to label vulnerabilities and disseminate this information through trusted channels, for example the National Vulnerability Database (NVD) or official vendor advisories.

It is equally important to ensure clarity for users by publishing security advisories that describe the issue, identify the affected products and versions, explain the potential impacts, and provide concrete remediation guidance. Manufacturers must also balance transparency with security: disclosure should only be delayed when early publication would create additional risks, and communication should take place as soon as users have had a reasonable opportunity to apply the patch.

Finally, effective implementation requires active engagement with stakeholders. This includes coordinating with customers, national CSIRTs, and the wider security community to validate disclosures and make sure the information is accessible and actionable. By embedding these practices into the secure development lifecycle, manufacturers create a disclosure process that is proactive, consistent, and credible.

Strategic Considerations beyond Compliance

For many organizations, disclosure can feel risky, why advertise vulnerabilities once they are fixed? The CRA reframes this thinking. Transparent disclosure is not about exposing weakness, but about demonstrating accountability.

Public advisories build trust with customers, regulators, and partners. They show that vulnerabilities are not only identified and patched but also openly communicated. This transparency reduces speculation, strengthens brand reputation, and provides assurance that security is managed responsibly.

Beyond compliance, effective disclosure can also accelerate collaboration. By publishing vulnerabilities with CVE IDs, manufacturers enable integration with automated vulnerability management tools, helping customers and partners respond faster. In competitive markets, companies known for clear, timely, and transparent disclosure will be recognized as leaders in security maturity.

In our next post, we will explore Requirement (5): Coordinated Vulnerability Disclosure (CVD) Policy.

Previous Blog CRA Vulnerability Handling Requirement (3): https://tributech.io/blog/cra-vulnerability-handling-requirement-3-security-testingNext Blog CRA Vulnerability Handling Requirement (5): https://www.tributech.io/blog/cra-vulnerability-handling-requirement-5-coordinated-vulnerability-disclosure-policy