CRA Annex I, Part II: The Eight Vulnerability-Handling Obligations That Run for Your Product's Entire Life
Most CRA conversations focus on what you build - the security-by-design requirements in Annex I, Part I. But there is a second half of Annex I that is just as binding and, in some ways, harder to satisfy: Part II. It does not care about your architecture decisions at launch. It cares about what you do every day for the entire life of the product after you ship it.
This post unpacks all eight obligations in Annex I, Part II of Regulation (EU) 2024/2847 - the CRA's "keep it secure after you ship" half - in plain terms, with the practical implications for product, security, and compliance teams.
This is general information, not legal advice. Confirm specifics against the official text of Regulation (EU) 2024/2847 and seek qualified legal counsel for your situation.
Key points at a glance
- Annex I, Part II sets eight ongoing process obligations — not one-time design requirements.
- They apply from the moment a product is placed on the market and run for the entire support period (minimum five years, or the product's expected lifetime if longer).
- Every security update you issue must remain available for at least 10 years after it is issued, or the remainder of the support period, whichever is longer.
- Security updates must be free of charge and, where technically feasible, delivered separately from feature updates.
- Full applicability: 11 December 2027. Article 14 reporting obligations (a related but separate duty) switch on earlier: 11 September 2026.
- As of mid-2026, no CRA harmonised standard has been published in the Official Journal, so the Article 27 presumption of conformity is not yet available for any product category.
Part I vs Part II: the distinction that matters
Annex I of Regulation (EU) 2024/2847 is split into two parts: Part I sets the security properties a product must have; Part II sets the vulnerability-handling processes a manufacturer must run. Think of Part I as the entry ticket - you need it to place the product on the market. Part II is the ongoing subscription: it keeps running for as long as the product is in use.
The two parts are also assessed differently. Part I conformity is demonstrated at the point of market placement. Part II conformity is a live obligation - market surveillance authorities can examine your processes at any time during the support period.
The eight obligations, explained
1. Identify and document vulnerabilities and components - including an SBOM
The first obligation is the foundation for everything else. Annex I, Part II, point (1) of Regulation (EU) 2024/2847 requires manufacturers to identify and document the components in their products, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies.
The CRA does not mandate a specific standard for the SBOM format. In practice, CycloneDX and SPDX are the two formats that market surveillance authorities recognise. The "at least top-level dependencies" wording sets a floor, not a ceiling - transitive components are where most known vulnerabilities hide, so a full dependency tree is the safer approach.
Critically, the SBOM is not a one-time deliverable. It must be kept current across the entire support period. That means regenerating it on every build, not just at release.
2. Address and remediate vulnerabilities without delay
Once a vulnerability is identified - whether through your own testing, a researcher report, or a CVE feed - you must act on it without delay. This includes providing security updates where needed.
Article 13(6) of Regulation (EU) 2024/2847 requires manufacturers, upon identifying a vulnerability in a component (including open-source components) integrated in their product, to report it to the person or entity manufacturing or maintaining that component, and to address and remediate the vulnerability in accordance with the Part II requirements. If you develop a fix for a third-party component, you are also expected to share the relevant code or documentation with the component's maintainer.
"Without delay" is not defined with a fixed number of days in Part II - that precision lives in Article 14 for the specific case of actively exploited vulnerabilities. For the broader remediation obligation, the standard is proportionality: the severity and exploitability of the vulnerability determines how fast you must move.
3. Apply effective and regular security tests and reviews
You cannot rely on a one-time pre-launch penetration test. Part II requires ongoing testing and review of the product's security throughout the support period. This means building security testing into your release pipeline and scheduling periodic reviews - not just reacting when something goes wrong.
What counts as "effective and regular" will be shaped by the harmonised standards currently being developed. The horizontal standard on vulnerability handling for products with digital elements (Standard 15 under Mandate M/606) has an adoption deadline of 30 August 2026 - the earliest of any CRA standard - because vulnerability handling requirements under Article 14 switch on 11 September 2026. Until that standard is cited in the Official Journal, it cannot be used to claim a presumption of conformity, but the drafts are publicly available and useful for anticipating what "effective and regular" will mean in practice.
4. Publicly disclose information about fixed vulnerabilities
Once a security update is available, you must share and publicly disclose information about the fixed vulnerability. Annex I, Part II, point (4) of Regulation (EU) 2024/2847 requires manufacturers, once a security update has been made available, to share and publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the affected product, the impacts, their severity, and clear and accessible information helping users to remediate.
There is one permitted exception: where the security risks of publication outweigh the security benefits, manufacturers may delay public disclosure until after users have had the opportunity to apply the patch. This is a narrow carve-out, not a general licence to stay quiet.
In practice, this means publishing security advisories - ideally in a machine-readable format such as CSAF - for every patched vulnerability, with CVSS scores or equivalent severity ratings.
5. Put in place and enforce a coordinated vulnerability disclosure policy
A coordinated vulnerability disclosure (CVD) policy is explicitly required by name in Part II. Article 13(8) of Regulation (EU) 2024/2847 requires manufacturers to have appropriate policies and procedures, including coordinated vulnerability disclosure policies referred to in Part II, point (5) of Annex I, to process and remediate potential vulnerabilities reported from internal or external sources.
A CVD policy is the documented commitment that tells security researchers, customers, and the public how you will handle vulnerability reports: what to send, where to send it, what timelines to expect, and what protections apply to good-faith reporters. It needs to be publicly accessible - not buried in a legal document.
We have a dedicated guide to CVD policy requirements on this site if you need to build one from scratch.
6. Facilitate information sharing - including a public contact address
Related to the CVD policy but distinct from it: you must actively make it easy for people to report potential vulnerabilities to you. Annex I, Part II, point (6) of Regulation (EU) 2024/2847 requires manufacturers to take measures to facilitate the sharing of information about potential vulnerabilities in their product, including by providing a contact address for the reporting of vulnerabilities discovered in the product.
A security.txt file at /.well-known/security.txt (per RFC 9116) is the standard mechanism. It should point to your CVD policy and your security contact. This is also the mechanism that feeds your Article 14 reporting workflow: the same channel that receives researcher reports should be the one that triggers your internal triage and, where applicable, your ENISA notification process.
7. Provide mechanisms to securely distribute updates
You must have a secure, reliable mechanism for getting patches to users. This is not just about having an update server - it is about the integrity and authenticity of the update delivery channel itself. Updates must be signed, tamper-evident, and distributed in a way that prevents interception or substitution.
For products where it is technically feasible, the CRA also expects automatic security updates to be available as a default-on option, with a clear and easy-to-use opt-out mechanism. The key word is "timely": a patch that exists but cannot reach users quickly is not a remedy.
8. Ensure security updates are free, separate, and accompanied by advisory messages
This is the obligation that has the most direct commercial implications. Annex I, Part II, point (8) of Regulation (EU) 2024/2847 requires manufacturers to ensure that, where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product, free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken.
Where technically feasible, security updates must be delivered separately from feature or functionality updates. The rationale is straightforward: users should not have to accept new features - and the risks that come with them - in order to receive a security fix.
The "free of charge" rule applies to end users. The B2B carve-out (tailor-made products) is narrow and requires explicit agreement. Do not assume it applies to your standard commercial terms.
The long tail: how long do these obligations run?
The support period under the CRA must be at least five years from the date of placing on the market, unless the product's expected usable life is shorter - and the Commission's draft guidance emphasises that five years is a minimum safeguard, not a default that can be applied to all products. Products expected to be in use longer - industrial equipment, infrastructure components, embedded systems - must have correspondingly longer support periods.
Every security update issued during the support period must remain available for a minimum of 10 years after it is issued, or for the remainder of the support period, whichever is longer. That is a significant archiving and hosting commitment. If you issue a patch in year two of a five-year support period, that patch must remain downloadable until at least year twelve from the date of issue.
The support period clock starts when the product is placed on the market - not when the customer buys it, and not when the CRA's full requirements apply. Plan your support commitments accordingly.
Annex I Part II vs Article 14: two related but different obligations
A common source of confusion is the relationship between Part II and Article 14. They are not the same thing.
| Dimension | Annex I, Part II | Article 14 Reporting |
|---|---|---|
| What it covers | Your internal vulnerability handling process — how you find, fix, test, disclose, and distribute patches | Notifying ENISA and your national CSIRT when you become aware of an actively exploited vulnerability or a severe incident |
| Who it is directed at | Your engineering and security teams | ENISA and the relevant national CSIRT (via the single reporting platform) |
| Trigger | Any vulnerability you become aware of, across the support period | Active exploitation confirmed, or a severe incident having an impact on product security |
| Timing | Ongoing — applies for the full support period | 24h early warning → 72h detailed notification → 14-day final report |
| Applies from | 11 December 2027 (full product requirements) | 11 September 2026 (earlier deadline) |
| Nature of obligation | Process and engineering obligation | Regulatory notification obligation |
The practical relationship: a well-run Part II process is what makes Article 14 reporting possible. If you have no SBOM, no vulnerability triage workflow, and no CVD policy, you will not be able to identify an actively exploited vulnerability quickly enough to meet the 24-hour early warning deadline.
The standards picture in mid-2026
As of June 2026, no CRA harmonised standard has been published in the Official Journal of the European Union, meaning the Article 27 presumption of conformity is not yet available for any product category.
CEN, CENELEC, and ETSI officially accepted the European Commission's Standardisation Request M/606 on 3 April 2025, committing to deliver harmonised standards at least one year before the CRA's full application date of 11 December 2027. The vulnerability handling standard (Standard 15 in the mandate) has a target adoption date of 30 August 2026. Several drafts - including the EN 40000 vulnerability-handling parts - have closed their public enquiry and are under approval, but ratification and Official Journal citation are separate milestones that have not yet been reached.
What this means for you: you cannot currently rely on a harmonised standard to demonstrate conformity. You need to demonstrate compliance directly against the Annex I text. The published drafts are useful for anticipating what conformity evidence will look like, but they are not yet a finished basis for assessment.
What to put in place now
The full Annex I Part II obligations apply from 11 December 2027. That is 17 months away. The engineering and process work required is not trivial, and some of it - particularly SBOM pipelines and CVD infrastructure - takes time to embed in development workflows.
Integrate SBOM generation (CycloneDX or SPDX) into your CI/CD pipeline so every build produces a current, version-bound bill of materials. Cover at least top-level dependencies now; aim for full transitive coverage. Store SBOMs so they can be provided to market surveillance authorities on request.
Define who receives vulnerability reports, who triages them, who decides on severity and remediation priority, and who approves public disclosure. Document the process — it will need to be evidenced in your technical file. Feed CVE feeds and your SBOM into the triage workflow so you can answer 'are we affected?' quickly.
Draft and publish a coordinated vulnerability disclosure policy. Add a security.txt file at /.well-known/security.txt pointing to the policy and a monitored security contact address. This is required by Part II, point (5) and (6), and it is also the foundation for your Article 14 reporting workflow.
Verify that your update channel is signed and tamper-evident. Confirm that security updates can be delivered separately from feature updates where technically feasible. Check that your update infrastructure can support the 10-year availability requirement for issued patches.
Set a defensible support period that reflects realistic expected product use — not just the five-year minimum. Publish the end date (month and year) so it is visible at the point of purchase. Document the factors you used to determine the period in your technical file.
Move from one-off penetration tests to a recurring security review cadence. Define what 'regular' means for your product category and risk profile, and document it. Use the EN 40000-1-3 draft as a reference for what the harmonised standard is likely to require.
A note on timing
The Article 14 reporting obligations - the 24h/72h/14-day ENISA notification clock - switch on 11 September 2026, less than two months from now. Those obligations apply to all products already on the EU market, not just products placed on the market after December 2027. If you have not yet set up the infrastructure to detect and report actively exploited vulnerabilities, that is the most urgent gap to close.
The Annex I Part II process obligations apply in full from 11 December 2027. But the processes they require - SBOM pipelines, triage workflows, CVD policies, secure update channels - take months to build and embed. Starting now is not early; it is on time.
Related reading
CRA Annex II: The User-Facing Documentation You Must Ship With Your Product
Annex II of the CRA sets out the security information manufacturers must ship with every product. Here's exactly what it requires, how to present it, and how to produce it without reinventing your docs.
CRA for Small Companies: What Article 33 Actually Gives You
The CRA applies to small companies too - but Article 33 of Regulation (EU) 2024/2847 builds in real relief for microenterprises and SMEs. Here is exactly what you are entitled to.
RED Cybersecurity Done - What Does the CRA Add? A Practical Guide for Wireless Product Makers
Already compliant with RED EN 18031? Here's exactly what the CRA adds, what carries over, and what you need to do before December 2027. Plain-English, no fluff.