Cyber Resilience Act: How to stay on top of vulnerability-handling

A vulnerability in a component your product uses is reported as actively exploited. Can your team assess the evidence and meet the Cyber Resilience Act’s 24-hour early warning deadline?

Your answer depends on more than identifying the vulnerability. It depends on how quickly you can determine which products are affected, assess the evidence, and decide whether reporting is required. A continuous vulnerability management process makes each of those steps faster and easier to repeat.

You know the Cyber Resilience Act (CRA) reporting clock is running, but do you know what a continuous process of vulnerability discovery, prioritization, remediation, reporting, and evidence-gathering really looks like? This article discusses how to build that process and prepare for the CRA’s vulnerability-handling requirements. It doesn’t cover product design, CE marking, or conformity assessment.

What the Cyber Resilience Act requires: Reporting & vulnerability-handling

The CRA introduces two groups of requirements that manufacturers of products with digital elements must comply with: reporting actively exploited vulnerabilities and severe incidents, and handling vulnerabilities throughout the product support period.

The first has applied since September 11, 2026, and, similar to the NIS2 Directive, provides a clear reporting structure:

• 24 hours. An early warning is due within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident impacting the security of the product.
• 72 hours. A notification with more details is due within 72 hours of becoming aware of the vulnerability or incident.
• 14 days. A final report concerning an actively exploited vulnerability is due no later than 14 days after a corrective or mitigating measure becomes available.
• 1 month. A final report concerning a severe incident is due within one month of the 72-hour notification.

Manufacturers must send their notifications through the CRA’s Single Reporting Platform to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment. ENISA receives them at the same time.

While these reporting requirements are already in effect, the CRA’s vulnerability-handling requirements only apply from December 11, 2027, which gives manufacturers time to prepare.

Among other things, Annex I, Part II vulnerability-handling requirements ask you to:

• Know what software components and vulnerabilities each product contains, including through an SBOM
• Fix vulnerabilities without delay
• Test and review product security regularly
• Maintain a coordinated vulnerability disclosure policy

The rest of this article looks at how those pieces connect in practice.

Why periodic audits & disconnected tracking fall short

Periodic audits and assessments still matter, but they only provide a snapshot of a product’s security at one point in time. New vulnerabilities emerge between assessments, and evidence of active exploitation, from CISA’s KEV catalog, vendor advisories, or threat intelligence feeds, can arrive at any time. The Cyber Resilience Act’s reporting deadline runs from when you become aware of an actively exploited vulnerability in your product, not from your next scheduled audit.

A vulnerability announcement alone doesn’t necessarily start the 24-hour clock. The European Commission’s guidance indicates you’re aware once, after an initial assessment, you reach a reasonable degree of certainty that a vulnerability in your product is being actively exploited. But that isn’t an open-ended window. The guidance expects you to start assessing a suspicious event immediately and to act promptly, especially when the risk is significant. How quickly you complete that assessment is the part you control.

Say your product uses a third-party library that’s now being actively exploited. Your security team spots it in a threat intelligence feed, but the component inventory is kept separately from the product records. Someone has to check each product by hand, confirm the library is present and exploitable, and report back. Depending on the size of your portfolio, that could take a day or more.

With current SBOMs linked to your product records, the picture changes. The alert arrives at 9:00 a.m. By 10:00 a.m., your team has identified the affected library and the product versions that use it. By 11:00 a.m., you’ve gathered initial technical evidence and escalated to whoever owns the CRA reporting assessment. These times are illustrative, but the point holds: a current inventory connected to vulnerability intelligence shortens the time it takes to complete the initial assessment.

Build CRA compliance into continuous vulnerability management

Vulnerability-handling doesn’t stop once your product is on the market. The CRA requires you to handle vulnerabilities throughout the support period, which is at least five years unless the product is expected to be in use for a shorter period (Article 13(8)). The CRA doesn’t explicitly require a continuous process, but having one in place makes its reporting deadlines easier to meet. Records that build up as part of a continuous process stay complete across years of releases, staff changes, and new vulnerabilities, instead of being reconstructed when an authority asks. In practice, it works best as one workflow: identify the affected components, assess the risk, fix, report when required, and keep evidence of every decision. These six steps show how.

1. Keep an accurate inventory of products, assets, and software dependencies

   Start with a list of your products, the versions deployed, and the software components in each version: third-party libraries, open-source packages, and other dependencies. Where they’re part of the product or support its functionality, include the web apps, APIs, and cloud services too.
   
   

2. Use SBOMs to identify affected components
   

   An SBOM turns a newly published vulnerability into a list of affected products. Match the vulnerable component and version against your SBOMs to see which products need further assessment. The CRA requires you to draw up an SBOM in a commonly used, machine-readable format that covers at least the top-level dependencies (Annex I, Part II, point (1)). Update it with every release, because an outdated SBOM can cause missed or false matches, especially when dependencies change between releases.
   
   

3. Prioritize using exploitability, exposure, product impact, and threat intelligence

   CVSS shows severity, not whether attackers are exploiting a vulnerability or whether the affected component gives them a path into your product. Weigh it alongside exploitation evidence, product exposure, the component’s role in the product, and the potential impact on product security. 
   
   Draw on several sources, and use each for what it can tell you. EPSS estimates the probability that a vulnerability will be exploited within the next 30 days, so it helps you rank what to fix first, but it isn’t evidence that exploitation has happened. CISA KEV, ENISA’s EUVD, vendor advisories, and threat intelligence can show that a vulnerability is being exploited in the wild. Your SBOMs then tell you whether the affected component is in your product. Together, they help you decide what to fix first and when to start a reporting assessment. The CRA doesn’t mandate any of these sources.
   
   

4. Establish remediation and escalation procedures

   Assign an owner to every vulnerability, set remediation timelines, and define when an issue escalates. Name one role to assess the evidence against the CRA definition of an actively exploited vulnerability and decide whether the reporting criteria are met. That’s typically your PSIRT lead or whoever owns product security.
   
   

5. Connect vulnerability disclosure with regulatory reporting

   Set up one process for vulnerability reports from researchers, customers, suppliers, and other external sources, and connect it directly to your reporting decision. Article 13(8) requires policies and procedures for this, including a coordinated vulnerability disclosure policy. A report that comes in should move straight into the Article 14 steps: early warning, notification, and final report. If the vulnerability is in a component you integrate, including open-source, Article 13(6) also requires you to report it to whoever makes or maintains that component. 
   
   If you’re also in scope of the NIS2 Directive, you have separate reporting duties for significant incidents with a similar rhythm: an early warning within 24 hours, a notification within 72 hours, and a final report within one month of the notification. The criteria, channels, and receiving authorities differ from the CRA, so align your internal process, but keep the two obligations separate.
   
   

6. Retain evidence of assessments, remediation decisions, and actions

   Keep a record of what happened when you discovered a vulnerability, how you measured its impact, and what you did about it. These records help you track unresolved vulnerabilities, explain your decisions, and show your process if a market surveillance authority asks. Include assessment schedules, results, and follow-up actions, which ENISA names as useful evidence of vulnerability management under NIS2. 
   
   In practice, you’ll hold two kinds of records. The formal technical documentation must include, under Annex VII, information on your vulnerability-handling processes, such as the SBOM and your coordinated vulnerability disclosure policy, along with reports of the tests you’ve run to verify that those processes meet the CRA’s requirements. Alongside it, you’ll keep working records of how you applied those processes to individual vulnerabilities, like triage notes, tickets, and remediation decisions. Article 13(7) requires you to document the vulnerabilities you become aware of, in proportion to the product’s nature and risks.

Prepare for December 11, 2027

Start by checking your current vulnerability management process against the requirements in Annex I, Part II. Look for gaps in how you discover, assess, document, remediate, and disclose vulnerabilities.

Keep the two sets of rules apart when you scope this work. Article 69(3) extends the Article 14 reporting obligations to all in-scope products, including those placed on the market before December 11, 2027. The vulnerability-handling requirements in Annex I, Part II apply from that date, but products placed on the market earlier are subject to them only if they’re substantially modified afterward (Article 69(2)). That means your reporting readiness has to cover every in-scope product you’ve placed on the market, old and new.

If you sell to organizations that are in scope of NIS2, expect questions. Those customers must address supply chain risks, including those from their suppliers, so they’ll want to know how you identify vulnerabilities, manage remediation, and communicate security issues that affect your product.

Preparation isn’t a one-time project. Your products and their software components keep changing, so keep your inventories, assessments, remediation procedures, and supporting records current. Keeping this information up to date makes it easier to identify affected products, respond promptly, and meet your reporting deadlines. For more information, see the European Commission’s guidance on the CRA and its implementation FAQ.

Vulnerability management is one part of CRA compliance. Security by design, technical documentation, and conformity assessment are separate requirements.

Put these steps to work with Holm Security

Our vulnerability assessment platform lets your team assess the systems, networks, web applications, APIs, and cloud services that make up or support your products, and prioritize what it finds using CVSS, EPSS, and threat intelligence. You see all your findings in one unified view and track remediation progress in one place. The platform keeps your assessment history and reports, which can serve as evidence of your vulnerability management process.

These capabilities line up with the Annex I, Part II requirements to identify vulnerabilities, test security regularly, and remediate without delay. The CRA places the reporting duty on the manufacturer: you assess the evidence against the definition of an actively exploited vulnerability and submit the required reports.

To see how continuous vulnerability management works in practice, reach out to one of our experts.

FAQ

1. What are the CRA reporting obligations?

   Under Article 14 of the Cyber Resilience Act, manufacturers must report actively exploited vulnerabilities and severe incidents affecting their products. An early warning is due without undue delay and within 24 hours of becoming aware, and a notification within 72 hours. The final report follows within 14 days after a corrective or mitigating measure is available (vulnerabilities) or within one month of the notification (severe incidents).
   
   

2. Is vulnerability management a CRA requirement?

   Yes. Article 13(8) requires manufacturers to handle vulnerabilities effectively throughout the support period, in line with the vulnerability-handling requirements in Annex I, Part II. That said, vulnerability management covers only part of the CRA. Security by design, technical documentation, and conformity assessment are separate requirements.
   
   

3. What does CRA compliance mean for vulnerability management?

   Among other things, Annex I, Part II requires you to identify and document vulnerabilities and components, assess their impact on product security, remediate vulnerabilities without delay, test security regularly, run a coordinated vulnerability disclosure policy, publicly disclose fixed vulnerabilities, and distribute security updates securely and without delay.
   
   

4. Is a periodic security audit enough for CRA compliance?

   Not on its own. Periodic audits still matter, and the CRA requires effective and regular security tests and reviews. While it doesn’t mandate continuous vulnerability management, relying only on periodic audits makes it harder to spot new vulnerabilities, assess affected products, and meet reporting deadlines. Keeping your inventories and vulnerability information current helps you respond in time.
   
   

5. Does NIS2 compliance cover the CRA?

   No. The CRA and NIS2 are separate laws with different reporting criteria, receiving authorities, and channels. If you’re in scope of both, align your internal vulnerability and incident handling, but meet each reporting obligation separately. Meeting NIS2 doesn’t by itself satisfy the CRA’s manufacturer reporting obligation. For the organizations and sectors NIS2 covers, see our NIS2 sectors overview.