Vulnerability handling requirements are the part of the EU Cyber Resilience Act that keeps working after launch day. Regulation (EU) 2024/2847 does not stop at demanding secure products; Annex I, Part II obliges every manufacturer to run a living process that finds, fixes and communicates security flaws for as long as the product is supported. From 11 December 2027 those duties are enforceable with fines of up to 15 million euros, and the reporting regime they feed starts on 11 September 2026.
This article is the vulnerability handling deep-dive in our Cyber Resilience Act series. Our Cyber Resilience Act compliance guide for UK software companies covers the whole regime, our guide to Cyber Resilience Act reporting requirements covers the 24-hour and 72-hour clocks, our Cyber Resilience Act checklist for software developers walks the engineering workstreams in delivery order, and our SBOM requirements guide unpacks the component inventory duty in depth.
Here we take the vulnerability handling requirements themselves apart: the eight duties Annex I, Part II actually imposes, what each one demands in practice, how the support period stretches them across years, and how to stand the whole process up in ninety days without derailing your roadmap.
Table of contents
- What the Vulnerability Handling Requirements Actually Say
- Who Must Meet the Vulnerability Handling Requirements
- The Eight Duties in Annex I Part II, One by One
- Security Updates, Patches and the Support Period
- A Coordinated Vulnerability Disclosure Policy That Works
- Vulnerability Handling Requirements Deadlines and the CRA Timeline
- How Vulnerability Handling Requirements Feed Article 14 Reporting
- Market Surveillance, Fines and Enforcement
- Common Vulnerability Handling Requirements Mistakes to Avoid
- A 90-Day Plan to Meet the Vulnerability Handling Requirements
- Vulnerability Handling Requirements FAQ
- References
What the Vulnerability Handling Requirements Actually Say
One annex, eight duties, one process
The vulnerability handling requirements live in Annex I, Part II of the regulation, a single page of text that lists eight obligations. Read together they describe one continuous process: know what you ship, find the flaws in it, fix them without delay, tell the world honestly, and deliver the fix securely and free of charge. Every duty either produces evidence for another or consumes it, which is why partial implementations tend to fail assessments.
A process, not a policy binder
Nothing in Annex I, Part II is satisfied by a document alone. The vulnerability handling requirements demand an operating capability: pipelines that generate component inventories, a queue that triages incoming reports, engineers who ship security updates, and channels that carry advisories to users. Assessors and market surveillance authorities ask to see the process running, with records, not a policy that describes what would happen if it ever did.
Where the duties sit in the regulation
Article 13 makes manufacturers responsible for complying with Annex I, Part II, and ties the duties to the support period. Article 14 builds the reporting obligations on top of them. The technical documentation described in Annex VII must describe how the vulnerability handling requirements are met. That lattice matters: a gap in the handling process becomes a gap in reporting, documentation and conformity assessment all at once.
Who Must Meet the Vulnerability Handling Requirements
Manufacturers carry the duty
The vulnerability handling requirements bind the manufacturer: anyone who develops or has developed a product with digital elements and places it on the EU market under their own name or trademark, whether paid or free. That covers desktop and mobile applications, firmware, commercial SDKs and libraries, IoT devices, and the remote processing a product needs to function. Importers and distributors must check the duties have been met before they resell.
UK and non-EU vendors are in scope
The test is market access, not company registration. A UK software house shipping into Germany, France or Ireland owes exactly the same vulnerability handling requirements as a vendor in Berlin. Brexit changes nothing here: if the product is placed on the EU market, the duties follow it, and a cybersecurity programme that stops at the UK border will not survive its first EU enforcement question.
Open source and the steward regime
Open-source software developed or supplied outside a commercial activity sits outside the regulation, and non-profit open-source stewards get a lighter regime. The edges cut quickly, though: monetise support, sell a paid tier, or ship a community edition under your trademark and the full vulnerability handling requirements attach to you as a manufacturer. When in doubt, map your revenue streams against the product first and argue about scope with the map in hand.
The Eight Duties in Annex I Part II, One by One
The table below is the whole of Annex I, Part II in plain language, with the evidence an assessor will expect for each duty.
| Duty | What it obliges | Evidence expected |
|---|---|---|
| 1. Identify and document | Document vulnerabilities and components, including an SBOM | Machine-readable SBOM per version |
| 2. Remediate without delay | Address vulnerabilities in relation to risk, via security updates | Patch history with dates |
| 3. Test regularly | Effective, regular tests and reviews of product security | Test schedule and findings log |
| 4. Disclose fixed flaws | Publish details of fixed vulnerabilities once updates ship | Public advisory archive |
| 5. Enforce a CVD policy | Put in place and enforce coordinated vulnerability disclosure | Published CVD policy |
| 6. Enable reporting | Provide a contact address and facilitate information sharing | Reachable security contact |
| 7. Distribute securely | Mechanisms to securely distribute updates | Signed, verified update channel |
| 8. Patch free of charge | Disseminate security updates without delay, free, with advisories | Free patch policy and advisory texts |
The documentation duty: know what you ship
Duty one is the foundation the other seven stand on: identify and document the vulnerabilities and components in the product, including a software bill of materials covering at least the top-level dependencies. Our SBOM requirements guide covers that duty field by field; here it is enough to say that a team that cannot list its components cannot honestly claim to handle their vulnerabilities.
The remediation pair: fix fast, ship free
Duties two and eight form a pair. You must address vulnerabilities without delay in relation to the risks they pose, and where a security update exists you must disseminate it without delay and free of charge, accompanied by an advisory telling users what to do. Charging for security patches, or holding them hostage to a version upgrade, is exactly the commercial practice the vulnerability handling requirements were written to end.
The transparency cluster: disclosure, CVD and contact
Duties four, five and six make the process visible from outside. Once a fix is available you publish details of the vulnerability it addresses; you operate and enforce a coordinated vulnerability disclosure policy; and you provide a contact address so researchers and users can reach you about flaws, including flaws in third-party components you ship. Duty three, regular testing, and duty seven, secure update distribution, close the loop between finding flaws and delivering fixes.
Security Updates, Patches and the Support Period
Separate security fixes from feature releases
The regulation expects security updates to be provided separately from functionality updates where technically feasible. The reasoning is practical: users must be able to take a critical patch without swallowing new features, new licence terms or new bugs. For teams whose release train bundles everything together, this is often the single biggest engineering change the vulnerability handling requirements force, and it is worth prototyping early with your DevOps pipeline rather than discovering the cost in 2027.
The support period sets the clock
Every duty in Annex I, Part II runs for the support period, which Article 13 requires manufacturers to determine so that it reflects the time the product is expected to be in use, with five years as the default expectation. Once an update ships, it must remain available for at least ten years or the remainder of the support period, whichever is longer. The support period must be stated in the information supplied with the product, so it is a public promise, not an internal planning figure.
| Obligation | Duration | Practical consequence |
|---|---|---|
| Vulnerability handling process | Whole support period, 5 years by default | Budget security engineering per product, per year |
| Availability of shipped updates | 10 years minimum, or rest of support period | Keep old patches downloadable and signed |
| Security updates free of charge | Whole support period | No paid-patch or upgrade-to-fix models |
| Stating the support period | At purchase | The commitment is public and comparable |
End of support is not end of exposure
When the support period ends, the duties to patch end with it, but reputational and contractual exposure do not. Enterprise buyers already write vulnerability handling requirements into procurement contracts that outlast the statutory window, and a product line that leans on the legal minimum will be compared, in public, against competitors who patch for longer. Treat five years as the floor the law sets, not the number your customers will accept.
A Coordinated Vulnerability Disclosure Policy That Works
What the policy must cover
Duty five obliges you to put in place and enforce a coordinated vulnerability disclosure policy. A workable CVD policy tells a researcher where to report, what to include, what response times to expect, what testing is in and out of bounds, and how credit and publication will be handled. The NCSC vulnerability disclosure toolkit is a strong free starting point that maps cleanly onto the vulnerability handling requirements.
The contact address is a legal duty
Duty six makes a reachable security contact a matter of law, and the practical implementations are cheap: a security.txt file on your domain, a monitored security inbox, and a named owner for the queue. What the regulation adds is the word enforce. An address that silently discards reports, or a triage rota nobody staffs, is a compliance failure even if the policy document reads beautifully.
Researchers are the free half of your process
A functioning CVD channel is the cheapest source of vulnerability intelligence you will ever run: external researchers find what your tests miss and charge nothing but acknowledgement. Teams that respond quickly, fix honestly and credit generously see report quality rise year on year. Teams that threaten researchers see the same flaws surface on social media instead, at which point the vulnerability handling requirements are the least of their problems.
Vulnerability Handling Requirements Deadlines and the CRA Timeline
Three dates, three projects
The regulation entered into force on 10 December 2024 and applies in stages: notified body provisions from 11 June 2026, the Article 14 reporting duties from 11 September 2026, and the full regime, including the Annex I essential requirements, for products placed on the market from 11 December 2027. Treat these as three projects with three deadlines, because each needs different people and different lead times.
| Date | What applies | What it means for vulnerability handling |
|---|---|---|
| 11 June 2026 | Notified body provisions | Assessment capacity starts building |
| 11 September 2026 | Article 14 reporting duties | Your handling process must feed 24-hour notifications |
| 11 December 2027 | Full regime, Annex I applies | All eight duties become enforceable |
Why September 2026 matters more than December 2027
The reporting duties arrive fifteen months before the conformity duties, and they quietly assume the handling process already exists. You cannot notify an actively exploited vulnerability within 24 hours if nothing in your organisation notices, triages and confirms exploitation in the first place. That is why the vulnerability handling requirements belong in this year’s plan: September 2026 tests the process end to end, long before an assessor reads your documentation.
How Vulnerability Handling Requirements Feed Article 14 Reporting
The three reporting clocks
From 11 September 2026, an actively exploited vulnerability in your product starts a legal stopwatch: an early warning to your CSIRT and ENISA within 24 hours, a fuller vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective measure is available. The clocks are short by design, and they are measured in elapsed hours, not working days.
Handling is the engine, reporting is the exhaust
Every Article 14 submission is generated by the process Annex I, Part II describes. The SBOM tells you whether the exploited component is yours; the triage queue confirms exploitation; the remediation duty produces the fix the final report describes; the advisory duty tells your users. Teams that treat reporting as a standalone legal task end up drafting notifications about a process that does not exist, under a 24-hour clock, which is the worst possible moment to discover the gap.
One queue, two outputs
The practical design is a single vulnerability queue with two outputs: engineering work items on one side and regulatory notifications on the other. Every inbound report, scanner finding and upstream advisory lands in the same triage, gets the same severity assessment, and either does or does not cross the Article 14 thresholds. Running the vulnerability handling requirements and the reporting duties as one workflow halves the process cost and removes the hand-off where deadlines die.
Market Surveillance, Fines and Enforcement
What authorities can demand
Market surveillance authorities in each member state police the regulation. They can require the technical documentation, including the evidence that the vulnerability handling requirements are operating: SBOMs, patch histories, test records, the CVD policy and the advisory archive. Requests will not arrive on your release schedule, so the rehearsal question is simple: could the team produce that bundle for any supported version within a working day?
The fine bands are real money
Non-compliance with the Annex I essential requirements, or with Articles 13 and 14, carries administrative fines of up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher. Breaches of other obligations carry up to 10 million euros or 2 percent, and supplying misleading information to authorities carries up to 5 million euros or 1 percent. A missing or fictional handling process sits squarely in the top band, and authorities can also force a product off the EU market entirely.
Enforcement is a market-access question
The fine is not the sharpest tool the regulation carries. Because the CE marking depends on meeting the essential requirements, a failed vulnerability handling process can suspend a product’s right to be sold in the EU at all, which for most software businesses is a larger number than any penalty. Enforcement is a cybersecurity matter and a commercial one at once, and boards tend to fund the process quickly once that is explained.
Common Vulnerability Handling Requirements Mistakes to Avoid
Treating the policy as the deliverable
The most common failure is writing a beautiful CVD policy, a patch SLA and a process diagram, then never operating any of them. The vulnerability handling requirements are behavioural: assessors look for tickets, timestamps, advisories and shipped updates. A policy binder with no operational trace behind it is evidence of the gap, not a defence against it.
Patching without telling anyone
Duties four and eight both attach communication to the fix: public disclosure of the vulnerability once the update is available, and an advisory telling users what to do. Teams that quietly patch and say nothing fail both duties while doing most of the work. The advisory does not need marketing polish; it needs the affected versions, the severity, the fix and the action, published where users actually look.
Letting the security inbox rot
A contact address that worked at launch and decayed since is a live compliance failure, because duty six requires the channel to function for the whole support period. Put the security inbox on a monitored rota, test it quarterly with a synthetic report, and track time to first response. The metric is cheap and it is exactly what an authority will probe first, because it is exactly what a frustrated researcher will screenshot.
Scoping out the components you did not write
Your duties cover the product, not just your code. Third-party libraries, commercial SDKs, bundled runtimes and base images are all inside the vulnerability handling requirements, and your contact channel must accept reports about them. Upstream fixes flow through your patch pipeline like your own, on your clock. The NCSC supply chain guidance makes the same point from the defender’s side, and procurement teams increasingly enforce it in contracts.
A 90-Day Plan to Meet the Vulnerability Handling Requirements
Days 1 to 30: map products and gaps
List every product placed on the EU market under your name, with versions inside their support period. For each, score the eight duties honestly: does an SBOM exist, is there a patch pipeline, is there a CVD policy, does the security contact answer? The output is a gap matrix, products down the side and duties across the top, which becomes the whole programme’s backlog and the evidence that you started.
Days 31 to 60: stand up the process
Close the structural gaps first. Publish the CVD policy and security.txt, stand up the triage queue, wire SBOM generation into the build, and separate security updates from feature releases in your delivery pipeline. None of this is exotic engineering; it is the same automation discipline any mature delivery team already runs, pointed at the vulnerability handling requirements instead of features.
Days 61 to 90: rehearse and document
Run two drills. First, a disclosure drill: file a synthetic vulnerability report through your own public channel and time the journey to triage, fix, advisory and update. Second, a reporting drill: take a historical CVE in a component you ship and walk the 24-hour and 72-hour clocks against your real process. Fix what the drills expose, then write the working process into the technical documentation while it is fresh.
Vulnerability Handling Requirements FAQ
Do the duties apply to products we shipped before 2027?
The essential requirements apply to products placed on the market from 11 December 2027, but placing on the market happens per unit, not per product line. Sell a unit or a licence after that date and the duties attach to it. The Article 14 reporting obligations apply from 11 September 2026 to products already in the field, so the handling process cannot wait for your next major release.
Is five years of support always enough?
Five years is the default expectation, not a safe harbour. The support period must reflect the time the product is reasonably expected to be in use: industrial firmware and infrastructure software will justify longer, and a shorter period needs documented justification. Whatever you choose must be stated publicly with the product, so the decision is as much commercial as legal.
Can we charge for security updates?
No. Security updates addressing identified issues must be disseminated free of charge for the support period, with advisories. You can still charge for feature upgrades, new versions and extended support beyond the statutory window; what you cannot do is put the fix for a known vulnerability behind a paywall or bundle it exclusively into a paid upgrade.
Do we have to fix every CVE our scanner finds?
The duty is to address vulnerabilities in relation to the risks posed, which is risk-based language, not a demand for a clean scan. A finding that is unreachable in your product can be assessed, documented and closed without a patch; that assessment record is itself compliance evidence. What the vulnerability handling requirements do not permit is ignoring findings without any assessment at all.
References
Cyber Resilience Act | European Commission
NIS2 Directive | European Commission
NCSC Vulnerability Disclosure Toolkit
NCSC: Supply Chain Security Guidance
OWASP Vulnerability Disclosure Cheat Sheet
NIST SP 800-218: Secure Software Development Framework
NIST SP 800-61: Incident Response Recommendations
FIRST: Common Vulnerability Scoring System
FIRST: Exploit Prediction Scoring System
security.txt: A Proposed Standard for Security Contact Information
