Product Risks Today: No new duties, higher expectations — the EU’s AI-and-cyber action plan and CRA guidance on product-liability readiness

Introduction

Vulnerability management (the ongoing process of finding, prioritising and fixing security weaknesses in a product) is under growing pressure to move faster. Artificial intelligence is making it easier and quicker for attackers to find weaknesses in software and turn them into real attacks, and these attacks are already materializing in practice. Companies are having to keep pace with this faster-moving threat, and may need to update plans which problems to fix first. Regulators are also now responding to this pressure:

On 7 July 2026, the European Commission (EC) published its Action Plan on Cybersecurity and Artificial Intelligence. Shortly after, on 27 July, the EC followed up with guidance on the Cyber Resilience Act (Regulation (EU) 2024/2847, the CRA)¹. That same month, ENISA, the EU's cybersecurity agency tasked under the AI plan with developing further guidance, supplemented this with practical guidance on handling vulnerabilities by issuing two papers.

A policy signal, not a new duty

None of these documents create new legal obligations. The Action Plan sets out the EC’s priorities, in particular in relation to the AI Act, the CRA and NIS2. The EC has also decided to publish the CRA guidance now, ahead of the CRA obligations starting to apply and ENISA’s publications equally reflect its views and interpretations rather than a binding requirement.

Together, they lay down the EC’s and ENISA’s expectations of responsible vulnerability management for manufacturers and AI providers, in particular, when a known vulnerability must be fixed immediately and when a provider may legitimately decide to wait. This focus on technical vulnerabilities forms part of a broader EU approach to cybersecurity. The proposed Cybersecurity Act 2 would reinforce ENISA’s role in vulnerability management and operational co-operation, while also introducing a new framework for non-technical ICT supply-chain risks. We discuss the proposal in our separate blog post.

Why this signal matters 

Two factors give this guidance immediate practical relevance, namely liability under the revised Product Liability Directive (PLD), and a CRA obligation that will be applicable for manufacturers from 11 September 2026. 

As we’ve explored before, the revised PLD’s framework continues to tie liability to the safety a person is entitled to expect, in particular where the regulatory framework sets product safety requirements. One of the key PLD’s innovations is an extension of relevant timing for assessing product safety. 

Until now, a product has been assessed as it was on the day it was placed on the market. Under the new PLD, if a product has not entirely left the manufacturer’s control, typically because it can still issue software updates or upgrades, their responsibility may not end. A defect introduced by a software update or upgrade, or caused by a security update the manufacturer could have supplied but did not, remains the manufacturer's responsibility. For these, the manufacturer generally cannot rely on the defence that the defect only arose after the product left its premises. This applies only to products placed on the market or put into service from 9 December 2026; existing products stay with the old rules. 

Unlike the PLD's forward-looking cut-off, the CRA does not wait for a product to be newly placed on the market when it comes to reporting: its reporting obligation for actively exploited vulnerabilities applies from 11 September 2026 to products already in circulation, with the rest of the CRA following on 11 December 2027 (see our recent post for more detail on what must be reported and by when). 

From policy to practice: what 'risk-based' now means 

Judging what counts as 'adequate' vulnerability management is a risk-based exercise. Neither the CRA guidance nor ENISA's Secure by Design and Default Playbook — guidance aimed in particular at smaller manufacturers — requires manufacturers to fix every known vulnerability the moment it is discovered, or in any fixed order. The CRA guidance addresses this specifically at the point of release: where a new exploitable vulnerability is identified shortly before a product is due to be placed on the market, manufacturers may weigh a short delay against releasing on schedule, provided that judgement is risk-based rather than automatic. ENISA's playbook extends the same logic to day-to-day operation after release. It frames vulnerability handling as an ongoing triage — using severity, exploitability and exposure to decide, case by case, whether to fix now, mitigate, accept for a defined period, or defer with a documented rationale — rather than setting out a queue that must be worked through in a fixed order. What both documents converge on is not that every fix happen immediately, but an expectation that the decision on timing be made, and be capable of being justified, on a risk basis.

Under the CRA guidance, deciding whether to fix a known, exploitable vulnerability immediately is a matter of weighing two things against each other. On one side sits the danger the vulnerability itself presents: how severe it is, how easily it could be exploited, and the harm it could do. On the other side sits any genuine case for a short delay, for example because a slightly later release would also fix other vulnerabilities, or because an immediate fix would take a critical system offline unnecessarily.

The CRA guidance also sets out that cost, commercial strategy and a manufacturer's own appetite for risk are, on their own, not considered as basis for leaving a known vulnerability unaddressed. 

The recent ENISA paper on cybersecurity in the age of frontier AI complements to this framework: because AI does not only increase the risk each individual vulnerability carries, but also multiplies how many arise at the same time, ENISA points manufacturers towards established prioritisation tools, such as the Exploit Prediction Scoring System (EPSS) and the Vulnerability Exploitability eXchange (VEX). These assess exactly the exploitability of a vulnerability, one of the core factors the balancing test above turns on, and help manufacturers apply that criterion consistently rather than case by case.

Making the decision defensible

Against this background, manufacturers should be prepared to show, after the fact, that a decision was balanced and well documented. The Secure by Design and Default Playbook by ENISA confirms this approach by setting out that the decision taken for each vulnerability and the reasoning behind it shall be recorded with an assigned owner and a review date, including documentation on risks that were accepted rather than fixed. Each of these risks shall be tracked until respective issues are fix through a release.

What manufacturers and AI providers may take away for everyday operations

• Weighing the severity, exploitability and potential impact of a vulnerability against any genuine case for delay remains key.
• Documenting rationales and a consistent record for these decisions, across internal audit processes as well as external reports, disclosures and public statements, can support future defences.
• In case any gaps in governance are identified, the coming months can serve as a testing period: the CRA's own reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026, well ahead of the CRA's full application on 11 December 2027.