Cyber Resilience Act Vulnerability Handling

Julian Meroi · Published 9 November 2026 · Last reviewed 9 November 2026

The Cyber Resilience Act requires manufacturers to handle the vulnerabilities of their products for as long as the product is supported. In practice that means a process that receives reports, finds the affected releases, decides how to remediate in proportion to the risk, delivers a security update, tells users what they need to know and keeps a record of each decision.

This guide shows how to set up that process and connect it to the work your teams already do in their ticketing, engineering and release tools. The CRA does not require a dedicated platform or a separate security department.

What the manufacturer needs to have in place

Vulnerability handling under the CRA has eight parts. The manufacturer must:

1. know what the product contains, including a software bill of materials (SBOM);
2. address and remediate vulnerabilities without delay, in proportion to the risk;
3. test and review the product’s security regularly;
4. publish information about fixed vulnerabilities once the update is available;
5. put in place and enforce a coordinated vulnerability disclosure policy;
6. make it easy to report vulnerabilities, including through a contact address;
7. distribute updates securely, and automatically where applicable;
8. disseminate security updates without delay, free of charge and with advice for users.

Annex I Part II.

These duties start when the product is placed on the market and last for the whole support period. They cover products placed on the market from December 11, 2027. A product placed on the market before that date is covered only if it is substantially modified on or after December 11, 2027.

Reporting is a separate obligation with a different timeline. Since September 11, 2026, manufacturers must notify actively exploited vulnerabilities and severe incidents for all products in scope, including older products, and the obligation continues after support ends. Our CRA reporting requirements guide covers it. This guide shows where the two processes meet.

Make reports easy to receive and route

Vulnerability reports come from many places: your own testing, security researchers, customers, suppliers’ advisories and public vulnerability databases. The intake has to catch all of them and send each one to the people who can assess it.

A contact that users can find. The CRA requires a contact address for reporting vulnerabilities and a single point of contact that users can identify easily. Users must be able to choose how they contact you, and you cannot limit them to automated tools such as a chatbot. Name the contact, and say where your disclosure policy can be found, in the information that comes with the product. Article 13(17).

A policy that you follow. A coordinated vulnerability disclosure policy tells people who find vulnerabilities (finders) how to report them and what will happen next. The CRA requires you to put the policy in place and to enforce it, so the process behind it has to work as described. ETSI’s guide to coordinated vulnerability disclosure suggests a basic policy that covers:

• how you want to be contacted, and how to communicate securely;
• what information a report should include, such as the affected product and version, a description, steps to reproduce and the impact;
• what the finder can expect to happen after reporting;
• what is in and out of scope.

This outline is an example of implementation based on ETSI TR 103 838. The CRA requires a coordinated vulnerability disclosure policy that is put in place and enforced, but it does not prescribe the policy’s contents or the fields of a report.

A security.txt file at /.well-known/security.txt on your website is a common way to advertise the contact and the policy. If you publish one, RFC 9116 requires a Contact field and an Expires date. The CRA does not require the file; it is one way to make the contact easy to find.

Routing and confidentiality. Give each report a reference, acknowledge it, and pass it to the team responsible for the product. Decide who is responsible for the case from the first report until it is closed. Keep the details of an unfixed vulnerability confidential, and keep the finder informed while you work on the case.

Triage against the product you actually ship

A report tells you only that a product may be vulnerable. Triage establishes whether the vulnerability affects the releases you have placed on the market, and how serious it is in those releases. Record the answer to each of these questions separately:

• Which product, release and configuration? Use the SBOM and your release records to find every release that contains the affected component or code, including older releases that are still in their support period. Our CRA SBOM requirements guide explains how to match an advisory against your releases.
• Is it present and reachable? Check whether the vulnerable code is in the build and whether it can be reached in the way the product is used.
• Is it exploitable in practice? The CRA treats a vulnerability as exploitable if an adversary could effectively use it under practical operational conditions. Some vulnerabilities can be exploited only in a lab.
• What is the impact? Consider what an attacker could do with the product and with the systems connected to it.
• Is there evidence that it is being exploited? If there is, the reporting obligation applies, as explained below.

A vulnerability can become known in several ways: through a public vulnerability database, through coordinated disclosure, through your own testing or through prominent media reports. The Commission’s guidance expects manufacturers to investigate promptly and confirm whether the vulnerability is real and applies to their product. A high score in a scanner or a new CVE entry does not answer those questions on its own. Where the answer is uncertain, keep investigating and record what remains open. Until you have an answer, do not treat the release as unaffected.

Escalate possible exploitation at once. If at any point you become aware that a vulnerability in the product is actively exploited, the reporting obligation starts from that moment. It runs in parallel with the investigation and the fix, and your internal triage deadlines do not pause it. Build the escalation into triage: whoever sees evidence of exploitation passes it straight to the people who handle reporting. The reporting guide explains when awareness begins and what must be sent.

Record the evidence and the reasoning behind each conclusion. You must document the vulnerabilities you become aware of and relevant information from third parties, and update the risk assessment where applicable. Our CRA risk assessment guide explains the assessment itself.

Choose and coordinate the remediation

The CRA requires you to address and remediate vulnerabilities without delay, in relation to the risks they pose. The Commission’s FAQ explains that this does not mean a patch for every finding. Depending on the risk, the remediation can be an immediate patch, a workaround followed by an update, configuration guidance that disables the affected feature, or an update to the user documentation. Where the analysis shows that a vulnerability cannot be exploited, for example because the product never calls the vulnerable library functions, it may be enough to document it and remove the unused code in a later release. FAQ 4.3.1.

Whatever you choose, record why it is proportionate to the risk and what evidence shows that it works.

Before the product is placed on the market. On the basis of your risk assessment, a product must be made available on the market without known exploitable vulnerabilities. If a vulnerability becomes known shortly before release, the Commission’s guidance expects you to decide whether the product can still be placed on the market securely, taking into account its severity, exploitability and impact. Once the product is on the market, the handling duties continue.

Components from suppliers and open-source projects. The handling duties cover the whole product, including the components you integrate. When you identify a vulnerability in an integrated component, you must report it to the company or project that manufactures or maintains the component. According to the Commission’s guidance, this applies only to the version you integrate and only to vulnerabilities in the component itself, so you do not have to report a problem caused by the way you integrated it. You also do not have to report the vulnerability if you can confirm that the maintainer is already aware of it, for example from the maintainer’s own security advisory, or if the component no longer has a maintainer. If you develop a software or hardware modification that fixes the vulnerability, you must share the relevant code or documentation with the maintainer, where appropriate in a machine-readable format. You do not have to make sure that the maintainer accepts it. Article 13(6).

A fix from the supplier does not finish the work. You still need to confirm that the fix addresses the vulnerability in your release, deliver it to your users and update your documentation. If a supplier stops supporting a component while your product is still supported, the FAQ expects you to remediate the vulnerability in another way, such as replacing the component or developing the patch yourself.

When a product does not comply. If you know or have reason to believe that the product or your processes do not comply with the essential requirements, you must immediately take the corrective measures needed to bring them into conformity, or withdraw or recall the product, as appropriate. The FAQ expects withdrawal or recall to be exceptional, for example for a hardware product with a vulnerability that presents a very significant risk and cannot be adequately remediated.

Verify and distribute the update

Test the fix. Confirm that the update removes or mitigates the vulnerability in each affected release and configuration, and run regression tests on what the change could affect. The CRA also requires effective and regular tests and reviews throughout the support period. The Commission’s guidance explains that this means reviewing whether new information, such as a newly discovered vulnerability, calls for new or changed tests. It does not mean repeating an unchanged test campaign at fixed intervals.

Keep security updates separate where you can. Where technically feasible, provide new security updates separately from functionality updates, so users do not have to accept new features to stay secure. The FAQ accepts a combined update where the fix itself changes functionality, for example when a vulnerable parser has to be replaced by a stricter one.

Deliver securely, and automatically where applicable. Updates must be distributed through a secure mechanism. Where applicable, security updates should install automatically by default within an appropriate timeframe. Users need a clear and easy way to opt out, notification of available updates and the option to postpone them temporarily. The FAQ, drawing on the CRA’s recitals, explains that automatic updates are not expected for products mainly intended for integration into other products, or where users would not reasonably expect them, such as in professional networks and industrial environments where an update could interfere with operations. It adds that the manufacturer is not responsible if a user does not install an update.

Disseminate without delay and free of charge. Once a security update is available, disseminate it without delay and free of charge, with an advisory message telling users what they need to do. The only exception is where you and a business user have agreed otherwise for a tailor-made product. Annex I Part II(8).

Keep each update available. Each security update made available during the support period must remain available for at least ten years after it is issued, or for the rest of the support period if that is longer. Article 13(9).

Older software versions. If you have placed later, substantially modified versions of a software product on the market, you may remediate vulnerabilities only in the latest version. This applies only if users of earlier versions can get the latest version free of charge and without extra cost to adapt their hardware or software environment. Your other handling duties, such as the disclosure policy and the reporting contact, still cover every version. Article 13(10).

Coordinate disclosure and inform users

Handling a vulnerability involves four kinds of communication. Each has its own audience, trigger and level of detail, and a delay in one does not delay the others:

• With the finder or the supplier, under your disclosure policy: you acknowledge the report, ask questions, share progress and coordinate the fix.
• With the authorities, when you become aware of active exploitation or a severe incident, through the reporting process.
• With impacted users, and where appropriate all users, after you become aware of active exploitation or a severe incident: tell them about the vulnerability or incident and, where necessary, the measures they can take. Where appropriate, provide this in a structured, machine-readable format. You may have to do this before a fix exists. The Commission’s guidance allows you to limit detailed information to the users concerned where public detail could help attackers. Article 14(8).
• With the public, once a security update is available: information about the fixed vulnerability.

The public advisory. Once the security update has been made available, share and publicly disclose information about the fixed vulnerability: a description, information that lets users identify the affected product, the impact and severity, and clear guidance on how to remediate. In duly justified cases, where you consider the security risks of publication to outweigh its benefits, you may delay publication until users have had the possibility to apply the patch. Annex I Part II(4).

For the public advisory, the CRA does not prescribe identifiers, scoring or a format. You can add a CVE ID, a CVSS score or a machine-readable CSAF version to help users process it. ETSI notes that a CVE entry on its own is not a way to disclose a vulnerability. Advisories should also leave out detail that would make exploitation easier, such as proof-of-concept code.

Example: a supplier library in Example Gateway 2.1

Example Gateway 2.1 is a fictional building gateway with a companion mobile app. Assume it was placed on the market after December 11, 2027 and is within its support period. The current firmware is 2.1.0. Older units still run firmware 2.0.4, which is also within its support period.

The maintainer of an open-source MQTT client library publishes an advisory: in versions 4.2.0 to 4.2.2, a malformed message from the broker can crash the library and may allow an attacker to run code. Version 4.2.3 fixes it. There is no known exploitation.

The team opens a case and works through it:

1. Affected releases. The SBOM for firmware 2.1.0 lists the library at version 4.2.1. The SBOM for firmware 2.0.4 lists version 4.1.8, outside the affected range. The app does not use the library.
2. Applicability. The vulnerable parsing code is compiled into firmware 2.1.0 and runs on every message from the cloud broker. An attacker who can impersonate or compromise the broker could reach it. The team rates the risk as high.
3. Upstream (maintainer). The maintainer published the advisory itself, so the team can confirm that it is aware of the vulnerability. No upstream report is needed.
4. Remediation. The team updates the library to 4.2.3 in firmware 2.1.1, a security-only release, and runs its regression tests on the messaging functions.
5. Distribution and advisory. Firmware 2.1.1 is delivered through the gateway’s signed automatic update channel. Once it is available, the team publishes an advisory describing the vulnerability, the affected firmware version, the impact and severity, and how to update.
6. Follow-up. The team updates the risk assessment and the technical documentation, issues the new SBOM, and closes the case once the remaining question below is answered.

This is an example of implementation based on CRA Annex I Part II and the Commission’s guidance and FAQ. These record fields, statuses and workflow choices are not mandated by the CRA, and the rows are a sample. The duties to handle the vulnerability, document it and inform users remain binding.

The supplier’s patch did not close the case. The team still had to confirm which of its own releases were affected, test the fix, deliver it and publish the advisory, and one question about customer builds is still open.

If the team becomes aware during this work that the vulnerability is being exploited, work on the case continues, and the reporting process starts in parallel from that moment.

Keep the record and review the process

What goes into the technical documentation. The technical documentation must describe your vulnerability handling processes, including the SBOM, the coordinated vulnerability disclosure policy, evidence that a reporting contact is provided and the technical solution for secure update distribution. Case records, risk decisions and test results show that the process works. Our CRA technical documentation guide explains how to organize the file. Annex VII.

Three different periods. Do not confuse them:

• the support period, during which you handle vulnerabilities;
• the availability of each security update, at least ten years after it is issued or the rest of the support period if longer;
• the retention of the technical documentation, at least ten years after the product is placed on the market or the support period if longer.

Review the process itself. Check periodically whether reports reach the right people, whether cases stall, and whether the same root causes come back. ETSI recommends feeding lessons back into development, so that you fix the causes as well as individual vulnerabilities.

Use the standards to assess and improve the process

EN 40000-1-3. This is the harmonized standard being prepared for vulnerability handling under the CRA. Its published scope follows the Part II requirements: identifying components and the SBOM, remediation and security updates, tests and reviews, disclosure of fixed vulnerabilities, the disclosure policy, information sharing and the contact address, and secure, timely distribution of updates. On November 8, 2026, the CEN project record showed it as under approval, with citation in the Official Journal expected. A harmonized standard gives a presumption of conformity only once its reference is published in the Official Journal, and only for the requirements it covers.

You do not need the final text to start. Map your existing process against the eight requirements and check that each produces evidence:

This mapping is an example of implementation based on CRA Annex I Part II and the published scope of prEN 40000-1-3. The process steps, evidence and gaps shown are implementation choices that the CRA does not mandate. The mapping does not reproduce the standard’s requirements, which must be checked against the published edition.

When the standard is published, compare your process with its actual requirements and assessment criteria, and check whether its reference has appeared in the Official Journal and for which requirements, before you rely on it for conformity. Our CRA risk assessment guide explains how the EN 40000 parts fit together, and the conformity assessment guide explains how standards affect the choice of procedure.

Other references. ISO/IEC 29147 covers vulnerability disclosure: receiving reports and publishing information. ISO/IEC 30111 covers the processes for investigating and remediating reported vulnerabilities. Many organizations already use them, and they can support a CRA process. Following them does not by itself give a presumption of conformity. A standard gives that presumption only if it is a harmonized standard whose reference has been published in the Official Journal, and only for the requirements it covers. ETSI TR 103 838 is a free, practical guide to setting up coordinated vulnerability disclosure. Its recommendations are good practice, and the CRA does not require them.

How Meroi Security can help

Meroi Security can assess your current vulnerability handling against the CRA, define clear handoffs between intake, engineering, release and reporting, connect the SBOM and release records to each case, improve your disclosure policy and advisory practice, and prepare the process documentation for the technical file. Explore our Cyber Resilience Act compliance services.