EU Cyber Resilience Act, CRA Product Security and CE Marking Vulnerability Handling and Disclosure

Part II is a live operations requirement. It asks manufacturers to identify components and vulnerabilities, address and remediate vulnerabilities without delay, perform regular security tests and reviews, disclose fixed vulnerabilities, run coordinated vulnerability disclosure, provide a reporting contact, and distribute security updates securely and without delay.

This model needs real tooling, roles, and decision records.

The Commission FAQ says the CRA does not require a patch for every vulnerability, but it does require manufacturers to assess the risk and ensure remedies are put in place without delay. That means you need a documented method for deciding whether the correct response is a patch, another corrective measure, a mitigation, or if necessary a withdrawal or recall.

A good program separates speed from guesswork. Fast response should still be traceable.

Component risk is still product risk. Article 13(6) requires manufacturers to report vulnerabilities in integrated components to the component maker or maintainer and, where appropriate, to share the security fix upstream. The March 2026 draft guidance adds practical limits: the duty concerns the integrated version of the component and the vulnerability must exist in the component itself, not only in the way the manufacturer combined it with other code.

The draft guidance also explains that manufacturers do not have to report upstream where the component no longer has a maintainer or where the manufacturer maintains an independent fork and no longer relies on upstream for new versions or security fixes. Where a fix is shared upstream, it should be in a form the maintainer can assess and integrate, but the CRA does not require the maintainer to accept it.

Once a security update or other corrective or mitigating measure is available, the CRA expects information about fixed vulnerabilities to be shared publicly with enough detail for users to identify the affected product, understand the impact, and remediate. If publication would create greater security risk, publication may be delayed, but that decision needs a documented and time bounded justification.

Use the same identifiers across the advisory, support content, and any Article 14 reporting.

The CRA does not mandate ISO or ENISA process models, but ISO/IEC 29147 and ISO/IEC 30111 are useful fair use reference points for disclosure and handling workflow design. ENISA guidance is also useful for building a disclosure policy that researchers can actually use.

Use these sources as process references, not as a substitute for the CRA text.