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.
Does the CRA require manufacturers to patch every vulnerability?
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.
Article 13(7), Annex VII, and Annex I Part II require documentation of vulnerabilities, vulnerability-handling processes, SBOM information, disclosure policy, reporting contact, update distribution, and test reports.
How does the CRA use SBOMs and dependency awareness?
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 should 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.
Do CRA vulnerability-handling duties cover third-party and open-source components?
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.
When is upstream reporting or fix sharing not required for a component issue?
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.
Must the upstream maintainer accept a security fix shared under the CRA?
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.
Draft guidance points 204-207 explain machine-readable sharing, open-source licence compatibility, maintainer guidelines, and the absence of an acceptance obligation.
How long do CRA vulnerability-handling obligations last?
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.
Does the manufacturer need to remediate every old software version?
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.
Article 13(10) and recital 40 explain when remediation can focus on the latest substantially modified software version and how hardware compatibility affects updates.
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 should be separate from functionality updates, so users do not have to accept unrelated feature changes just to receive a security fix.
Annex I Part II points 2, 7, and 8, plus recital 57, cover update separation, secure distribution, advisory messages, free security updates, and timely dissemination.
How long must each CRA security update remain available?
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.
When must fixed vulnerabilities be publicly disclosed?
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.
Is coordinated vulnerability disclosure mandatory under the CRA?
Yes. Annex I Part II requires manufacturers to put in place and enforce a coordinated vulnerability disclosure policy, and to facilitate 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 facilitate vulnerability reporting. 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.
Article 13(17), Annex I Part II points 5-6, and recital 76 support the coordinated disclosure policy, reporting contact, and optional bug-bounty framing.
Is CRA vulnerability handling the same as Article 14 reporting?
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 13 and Annex I Part II define vulnerability handling; Article 14 defines mandatory reporting for actively exploited vulnerabilities and severe incidents.
When does Article 14 require reporting of a vulnerability?
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.
What user communication does the CRA require for vulnerabilities?
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.
What if a vulnerability cannot be adequately fixed?
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. The practical question is whether risk-based remediation, mitigation, component replacement, configuration change, or another corrective action can restore conformity.
FAQ section 4.3.4 explains that recall or withdrawal may be required in exceptional cases where a significant vulnerability cannot be adequately addressed.
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 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) conditions are 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).