CRA vulnerability handling FAQ

Manufacturers must ensure, when placing a product with digital elements on the market and throughout the support period, that vulnerabilities of the product, including its components, are handled effectively.

In practical terms, Article 13 and Annex I Part II require a process that can identify and document vulnerabilities, track components, remediate vulnerabilities without delay in light of the risk, test and review security regularly, run coordinated vulnerability disclosure, receive vulnerability reports, securely distribute updates, and provide security updates without delay when they are available.

No. The Commission FAQ explains that the CRA does not require a patch for every vulnerability discovered during the support period.

The manufacturer must determine whether the vulnerability is relevant to the product, assess the risk, and put an appropriate remedy in place without delay. Depending on the risk and exploitability, that remedy may be an immediate patch, a mitigation, disabling an affected function, configuration guidance, user advice, documentation updates, or removal in a later regular release.

A useful vulnerability record should connect the legal duty to engineering evidence. It should identify the affected product and version, affected component or dependency where relevant, discovery source, exploitability assessment, risk and severity, affected user population, remediation decision, security update or mitigation, user advisory text, disclosure timing, and whether Article 14 reporting was assessed.

The record should also show whether the cybersecurity risk assessment and technical documentation were updated. Article 13(7) requires systematic documentation of relevant cybersecurity aspects, including vulnerabilities the manufacturer becomes aware of and relevant third-party information.

Annex I Part II requires manufacturers to identify and document vulnerabilities and components, including a software bill of materials in a commonly used and machine-readable format covering at least top-level dependencies.

The CRA does not make every SBOM public by default. Annex II says that if the manufacturer decides to make the SBOM available to the user, the user information must say where it can be accessed. Annex VII separately lists the SBOM as part of technical documentation where applicable and available to market surveillance authorities when needed to check compliance.

Yes. The vulnerability-handling obligations apply to the product in its entirety, including integrated components.

When a manufacturer identifies a vulnerability in an integrated component, including an open-source component, Article 13(6) requires the manufacturer to report it to the person or entity manufacturing or maintaining the component, address and remediate it in the manufacturer's own product, and share relevant code or documentation if the manufacturer developed a software or hardware modification to address the component vulnerability.

The Commission's March 2026 draft guidance narrows Article 13(6) upstream reporting to vulnerabilities that exist in the integrated component itself, and only for the component version actually integrated. It does not require upstream reporting for vulnerabilities created only by the manufacturer's integration with its own code or other components.

The same draft guidance says upstream reporting is not required where the component no longer has a maintainer, or where the manufacturer maintains an independent fork and no longer relies on the original maintainer for new versions or security fixes. If the manufacturer still synchronises with upstream for new versions or fixes, that is not treated as an independent fork for this purpose.

No. The draft Commission guidance says the CRA does not require a manufacturer to ensure that its fix is accepted or integrated by the component maintainer.

Where appropriate, the manufacturer should share the fix in a machine-readable way, such as a merge request, and for open-source components should share it in a way compatible with the component's licence and the maintainer's contribution guidelines. But the finished-product manufacturer may still choose another suitable mitigation for its own product.

They last for the support period determined by the manufacturer under Article 13(8). The support period must reflect the time the product is expected to be in use, considering reasonable user expectations, product nature and intended purpose, relevant Union law on product lifetime, comparable products, the operating environment, core third-party component support periods, and relevant ADCO or Commission guidance.

The support period is at least five years unless the product is expected to be in use for less than five years, in which case the support period corresponds to the expected use time. The end date, including at least month and year, must be clearly and understandably specified at purchase in an easily accessible way.

Not always. Article 13(10) allows a manufacturer that has placed later substantially modified versions of a software product on the market to satisfy the Annex I Part II remediation requirement only for the latest placed-on-market version, but only if users of earlier versions can access that latest version free of charge and without additional costs to adjust their hardware or software environment.

That exception is limited. Recital 40 adds that other vulnerability-handling requirements, such as coordinated vulnerability disclosure and vulnerability-reporting channels, still apply for all subsequent substantially modified versions. For hardware that cannot run the latest originally delivered operating system, security updates should continue at least for the latest compatible version during the support period.

When security updates are available to address identified security issues, they must be disseminated without delay and, except for the tailor-made business-user exception, free of charge. They must be accompanied by advisory messages with relevant user information, including potential action to take.

The manufacturer must also provide mechanisms to distribute updates securely so vulnerabilities are fixed or mitigated in a timely manner. Where technically feasible, new security updates must be separate from functionality updates, so users do not have to accept unrelated feature changes just to receive a security fix.

Article 13(9) requires each security update made available to users during the support period to remain available for at least 10 years after it is issued or for the remainder of the support period, whichever is longer.

This is separate from the support-period end date itself. Article 13(19) deals with the duty to specify the end date of the support period at purchase, while Article 13(9) sets how long issued security updates remain available after release.

After a security update has been made available, Annex I Part II point 4 requires the manufacturer to share and publicly disclose information about fixed vulnerabilities. That information should let users identify the affected product, understand the impact and severity, and find clear remediation information.

The CRA allows delay only in duly justified cases where the manufacturer considers the security risks of publication to outweigh the security benefits, and only until users have had the possibility to apply the relevant patch.

Yes. Annex I Part II requires manufacturers to put in place and enforce a coordinated vulnerability disclosure policy, and to support sharing of information about potential vulnerabilities in the product and in third-party components, including by providing a contact address.

Article 13(17) separately requires a single point of contact that lets users communicate directly and rapidly with the manufacturer, including to help users report vulnerabilities. Recital 76 also recognises direct and indirect reporting paths, including anonymous reporting through CSIRTs where requested, and says bug bounties may be used as part of coordinated disclosure policies, but it does not make bug bounties mandatory.

No. Vulnerability handling under Article 13 and Annex I Part II is the broader lifecycle process. It applies to vulnerabilities during the support period, including documentation, risk assessment, remediation, testing, update distribution, component handling, and coordinated disclosure.

Article 14 is narrower. It creates mandatory reporting duties when the manufacturer becomes aware of an actively exploited vulnerability contained in the product, or a severe incident having an impact on the security of the product. A vulnerability can require handling and remediation even when Article 14 mandatory reporting is not triggered.

Article 14 requires reporting when the manufacturer becomes aware of an actively exploited vulnerability contained in the product with digital elements. The CRA defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner's permission.

For an actively exploited vulnerability, the manufacturer must submit an early warning without undue delay and within 24 hours of awareness, a vulnerability notification within 72 hours of awareness unless already provided, and a final report no later than 14 days after a corrective or mitigating measure is available.

There are several distinct user-communication duties. For ordinary security updates, Annex I Part II point 8 requires advisory messages with relevant information and potential user action. For fixed vulnerabilities, Annex I Part II point 4 requires public information once a security update is available, subject to the limited justified delay rule.

For Article 14 events, the manufacturer must inform impacted users and, where appropriate, all users about the actively exploited vulnerability or severe incident and any mitigation or corrective measures they can deploy. The March 2026 draft guidance says this Article 14(8) duty is risk-based and proportionate; it does not always require indiscriminate public disclosure of detailed information.

The manufacturer must still take corrective measures necessary to bring the product or its vulnerability-handling process back into conformity, or withdraw or recall the product where appropriate.

The Commission FAQ treats withdrawal or recall as exceptional, but possible where a very significant vulnerability cannot be adequately addressed, especially for a hardware product. Assess whether risk-based remediation, mitigation, component replacement, configuration change, or another corrective action can restore conformity.

Yes. Article 13(8) requires appropriate policies and procedures to process and remediate potential vulnerabilities reported from internal or external sources.

One workflow can cover findings from internal testing, code review, monitoring, researchers, customers, component maintainers, public disclosures, and other outside sources, but it should preserve the source, affected product and version, triage decision, risk assessment, component impact, remediation or mitigation, testing, disclosure, update, and Article 14 reporting decision.

Yes. Article 15 allows voluntary notification of vulnerabilities and incidents that affect the cybersecurity risk profile of a product, including cases where Article 14 mandatory reporting does not apply.

Voluntary notification does not replace ordinary vulnerability handling. The manufacturer must still assess and remediate the issue, handle affected components, update records, and communicate with users where the CRA requires it. For example, a vulnerability without reliable evidence of malicious exploitation may fall outside the mandatory actively-exploited-vulnerability trigger while still requiring risk-based remediation.