Search every question across sub-FAQs

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.

Module A is the CRA conformity assessment procedure based on internal production control.

Under Annex VIII Part I, the manufacturer ensures and declares, on its sole responsibility, that the product with digital elements satisfies the applicable product cybersecurity requirements in Annex I Part I and that the manufacturer's vulnerability-handling processes satisfy Annex I Part II. The route applies to products placed on the Union market from 11 December 2027, subject to the Article 32 eligibility rules.

No. Module A is the CRA self-assessment route.

The Commission CRA FAQ states that no notified body participates in Module A. A manufacturer can still use external expertise or laboratories, but that does not turn Module A into a notified-body assessment and does not move responsibility away from the manufacturer.

Products with digital elements that are not listed as important or critical products can use Module A under Article 32(1). The manufacturer may also choose a stricter route, such as module B+C or module H, but Article 32(1) does not require that for default-category products.

Important class I products can use Module A only where the Article 32(2) trigger is not met. Important class II products and critical products are generally directed to stricter procedures, except for the specific free and open-source software exception in Article 32(5).

For an important class I product, Module A is not enough for the applicable essential cybersecurity requirements where the manufacturer has not applied, has only partly applied, or cannot apply relevant harmonised standards, common specifications, or qualifying European cybersecurity certification schemes.

For those requirements, Article 32(2) requires module B+C or module H. The practical control is therefore requirement-by-requirement: identify the applicable Annex I requirements, map the harmonised standard, common specification, or certification coverage, and send uncovered or partly covered requirements through the stricter route.