Under the EU Cyber Resilience Act (CRA), vulnerability management is now a condition of access to the European market for manufacturers of products with digital elements.

Since 11 September 2026, manufacturers have been required to report actively exploited vulnerabilities and severe incidents affecting their products. The CRA’s remaining requirements will apply from 11 December 2027, including wider obligations for addressing and remediating product security issues.

While organizations shouldn’t need to completely overhaul their vulnerability management policy, the challenge is making sure existing processes meet CRA requirements. This guide outlines some practical tips to help organizations get there.

Tip 1 – Know Your Responsibilities

When a vulnerability is disclosed, one of the first things your team needs to establish is which products are affected. That gets difficult quickly if product information sits across different teams, or no one is quite sure who owns the response.

Under the CRA, manufacturers are responsible for handling vulnerabilities in their products, including vulnerabilities in the components they contain, throughout the support period. In most cases, that support period must be at least five years. It can be shorter where the product is expected to be used for less than five years, provided the support period reflects its expected lifetime.

A good place to start is to make sure you have a clear view of:

• Which products fall within scope of the CRA.
• Who owns each product from a security and vulnerability management perspective.
• Which versions are currently supported.
• How long each product will be supported.
• Which third-party and open-source components each product depends on.
• Where responsibility sits between security, engineering, and product teams when a vulnerability is found.

Tip 2 – Build a Process for Vulnerability Reports

You need a reliable way for other people to tell you when they find a vulnerability in your products. The CRA requires manufacturers to put in place and enforce a coordinated vulnerability disclosure (CVD) policy and take measures that make it easier to share information about potential vulnerabilities. This includes providing a contact address for reporting vulnerabilities in the product and its third-party components.

For organizations that already run a PSIRT or product security program, much of this may already be familiar. But it’s worth checking the whole journey from a researcher’s perspective. Can someone who discovers a vulnerability quickly work out where to report it, what information to provide and what happens next?

Tip 3 – Define a CRA-Aligned Vulnerability Triage Process

When a vulnerability lands with your team, you don’t want to spend valuable time deciding how to classify it or who needs to be involved. Set those rules in advance.

Your triage process should make it clear how vulnerabilities are assessed, when they need to be escalated and what information is needed to decide whether the CRA’s reporting requirements apply.

Vulnerabilities outside Article 14 still need to move through your vulnerability management process. From December 2027, manufacturers will need to address and remediate vulnerabilities without delay, taking account of the risks they pose.

The important distinction is between reporting and remediation. Build your triage process so your team can make both decisions quickly and consistently. That way, when the clock starts, people already know what happens next.

Tip 4 – Build the Reporting Deadlines into Your Incident Workflow

CRA reporting deadlines are short, so the reporting process needs to be part of your incident workflow from the start.

For actively exploited vulnerabilities, the CRA requires an early warning within 24 hours of becoming aware of the issue, followed by a vulnerability notification within 72 hours. A final report is due no later than 14 days after a corrective or mitigating measure becomes available. Severe incidents follow the same 24- and 72-hour stages, with the final report due within one month of the 72-hour notification.

That means reporting can’t wait until after the technical investigation. A few practical things to put in place now:

• Nominate the people authorized to submit CRA notifications and make sure you have backups.
• Check that they have an EU Login account with multi-factor authentication so they can access the Single Reporting Platform.
• Document how the 24-hour escalation process works, including evenings, weekends and staff absence.

Tip 5 – Create a Clear Vulnerability Remediation Process

The CRA requires manufacturers to address and remediate vulnerabilities without delay, taking account of the risks they pose. It doesn’t prescribe a single remediation deadline for every vulnerability, so your teams need a clear way to decide what gets fixed first.

A practical approach is to set risk-based remediation targets using factors such as severity, exploitability, exposure and evidence of active exploitation. For example, you might distinguish between:

• Vulnerabilities known to be actively exploited.
• Critical vulnerabilities that can be exploited remotely.
• High-severity vulnerabilities with no evidence of active exploitation.
• Lower-risk vulnerabilities that can be handled through the normal release cycle.

These categories aren’t defined by the CRA, and there’s no universal set of timelines that will work for every product. The point is to give engineering and product security teams clear expectations before a vulnerability appears.

Tip 6 – Don’t Forget Third-Party Vulnerabilities

Your vulnerability management process needs to cover more than the code your own teams write.

If you identify a vulnerability in an integrated component, including an open-source component, the CRA requires you to notify the person or organization that manufactures or maintains it. You still need to address and remediate the issue in your own product, and if you develop a software or hardware modification to fix the component, you may also need to share the relevant code or documentation upstream where appropriate.

That makes third-party vulnerability handling something to think about before a vulnerability is disclosed. If a critical dependency has no clear owner, no reliable update channel or no straightforward way to patch it in your product, that is useful information to know during development rather than during an incident.

How Outpost24 Supports CRA Vulnerability Management

Outpost24’s unified platform supports CRA readiness by improving vulnerability management and security testing across the product lifecycle:

• CyberFlex combines PTaaS and EASM to uncover known and unknown assets and help teams focus continuous security testing where the risk is greatest.
• OutscanNX combines CVSS, KEV, EPSS, exploit intelligence and asset context to help teams prioritize vulnerabilities and track remediation progress over time.
• Outpost24 Digital Risk Protection provides visibility into emerging threats and external indicators so teams can identify changing risks and feed them into ongoing cybersecurity risk assessments.

Together, these capabilities help teams adapt testing and vulnerability management as products and risks change, while building useful evidence to support CRA readiness.

Want to see how Outpost24 could support your CRA vulnerability management program? Book a demo.