Annex I Part II of Regulation (EU) 2024/2847 sets eight numbered duties every manufacturer of a product with digital elements must operate throughout the support period: SBOM-anchored identification, remediation without delay, regular testing, public disclosure of fixes, a coordinated vulnerability disclosure policy, an external reporting channel, secure update distribution, and free-of-charge security updates. This page walks each duty and shows where Annex I handling ends and Article 14 reporting begins.
Summary
- Annex I Part II is the engineering specification for vulnerability handling under the CRA, applicable to every manufacturer for every product with digital elements.
- Eight numbered duties: identify (with SBOM), remediate without delay, test regularly, publicly disclose fixed vulnerabilities, operate a CVD policy, facilitate vulnerability reporting, distribute updates securely, deliver security updates free of charge.
- Free of charge is non-negotiable: security updates must be provided free under Annex I Part II point 8, with the only carve-out for tailor-made products to business users.
- The CVD policy is mandatory, not optional: Annex I Part II point 5 makes coordinated vulnerability disclosure a CE-marking obligation, not a best practice.
- Vulnerability handling runs throughout the support period defined in Article 3(20) and Article 13(8); the minimum is five years from market placement.
- Vulnerability handling is not Article 14 reporting: handling is the day-to-day engineering process; reporting is the 24h/72h/14d cadence triggered only by actively exploited vulnerabilities or severe incidents (see CRA Article 14 reporting).
The four anchors that frame CRA vulnerability handling: scope, duration, cost rule, and penalty ceiling.
The eight Annex I Part II duties
Annex I Part II of Regulation (EU) 2024/2847 lists eight numbered duties. They are not a checklist: they describe a continuous lifecycle that runs throughout the support period. The grouping below organises them by the operational phase in which each one runs.
Points 1, 6. SBOM-based identification of components and known vulnerabilities, plus a public contact channel that lets external parties report what your scanners missed.
Points 2, 3. Remediation without delay (severity-scaled, not a fixed SLA) and effective regular testing of the codebase and its dependencies.
Points 7, 8. Secure update channel (signed, authenticated, automatic where applicable), with security updates separable from features and free of charge except for tailor-made B2B products.
Points 4, 5. A coordinated vulnerability disclosure policy that is in place and enforced, plus public advisories once a fix is available, with a narrow "duly justified" delay carve-out.
What each duty means in practice
| # | Duty | What it actually requires |
|---|---|---|
| 1 | Identify and document vulnerabilities and components | An SBOM in CycloneDX or SPDX, covering at least top-level dependencies. The SBOM is the index that makes CVE matching possible: you cannot remediate what you have not catalogued. |
| 2 | Remediate without delay, separately from features | No fixed SLA; the speed expected scales with severity. Security branches must be separable from feature branches so users cannot defer a patch by deferring a release. |
| 3 | Effective and regular testing | Static analysis, dynamic testing, dependency scanning against vulnerability feeds, and penetration testing. "Regular" must match the risk and the rate of change of the codebase. |
| 4 | Public disclosure of fixed vulnerabilities | Once a fix ships, publish description, affected product, impact, severity, and remediation. Delay only "in duly justified cases" until users can patch. CVE plus CSAF is the de facto carrier. |
| 5 | Coordinated vulnerability disclosure policy | A written, enforced CVD policy with intake channel, response SLA, and disclosure conditions. ISO/IEC 29147 and 30111 provide a formal frame. |
| 6 | Facilitate external vulnerability reporting | A contact address for reporting issues in the product and its third-party components. security.txt under RFC 9116 satisfies the channel requirement. |
| 7 | Secure update distribution | Signed, authenticated updates, automatic where applicable. Products without an update channel must build one or document why automation is not applicable. See security updates. |
| 8 | Free of charge, with advisory messages | Security updates must be disseminated without delay and free of charge (only carve-out: tailor-made products to business users where the parties agreed otherwise). Each update must carry an advisory message describing the issue and the action the user needs to take. A paid-maintenance gate, or a silent patch with no advisory, breaches point 8. |
Vulnerability handling and the support period
Annex I Part II requirements apply throughout the support period defined in Article 3(20) and required by Article 13(8). The support period is at least five years from the date the product is placed on the EU market, or the expected product-in-use period if shorter and disclosed. The support period end date must appear in the product information under Annex II. Once the support period ends, Annex I Part II duties lapse for that product version, but the documentation retention duty under Article 31 (ten years from market placement) continues. See CRA support period.
Vulnerability handling is not Article 14 reporting
The CRA distinguishes two duties that operate on different surfaces and different audiences:
- Annex I Part II vulnerability handling is the engineering process: SBOM, remediation, CVD policy, public disclosure, secure updates. It applies to all vulnerabilities, all the time, throughout the support period. It is delivered through the manufacturer's product security organisation.
- Article 14 reporting is the regulatory notification triggered by an actively exploited vulnerability (Article 3(42)) or a severe incident having an impact on the security of the product. It is delivered through the ENISA Single Reporting Platform on a 24h / 72h / 14d cadence to ENISA and the CSIRT designated as coordinator. For SRP onboarding mechanics, see ENISA SRP onboarding.
A product team can be fully compliant with Annex I Part II while never filing an Article 14 report, because most vulnerabilities are remediated before they are actively exploited. Article 14 only triggers when remediation has not yet caught up with active exploitation. See CRA Article 14 reporting.
Penalties for breach
Non-compliance with the essential requirements in Annex I, including Part II vulnerability handling, falls under the top tier of administrative fines in Article 64(2): up to EUR 15 000 000 or 2.5% of total worldwide annual turnover, whichever is higher. The duty applies from 11 December 2027 for products placed on the market from that date.
Frequently Asked Questions
Does the SBOM under Annex I Part II point 1 have to cover transitive dependencies?
The verbatim text requires "at the very least the top-level dependencies", which is the regulatory floor. Transitive components are not mandated by point 1, but they are mandated in practice by point 2: you cannot "address and remediate vulnerabilities without delay" for a CVE in a transitive component you have never catalogued. Most regulators and customers expect a deep SBOM that follows BSI TR-03183 or comparable guidance. CycloneDX and SPDX both qualify as "commonly used and machine-readable" formats. See CRA SBOM requirements.
What does "without delay" mean in practice for remediation under point 2?
The CRA does not specify a fixed remediation SLA. "Without delay" scales with the cybersecurity risk: a critical vulnerability with active exploitation in the wild requires a fix in days, while a low-severity issue can wait for the next regular cycle. Severity is established with CVSS, sharpened by EPSS exploit-probability data, and confirmed by CISA KEV catalogue evidence where the vulnerability is on CISA's actively-exploited list. See severity scoring for the operational ladder market authorities apply when judging whether a manufacturer remediated "without delay".
Can security updates be charged for under any circumstances?
Only one carve-out exists: Annex I Part II point 8 permits a paid arrangement for tailor-made products supplied to a business user where the manufacturer and the business user have agreed otherwise. For every other product, including all consumer products and standard B2B SaaS or hardware, security updates must be free of charge throughout the support period. Gating a security patch behind a paid maintenance tier is a direct breach of point 8 and exposes the manufacturer to the top-tier fines under Article 64(2).
Do Annex I Part II duties continue after the support period ends?
No. The eight Annex I Part II duties apply throughout the support period under Article 13(8) and lapse for that product version when the support period ends. Two duties survive the support period: the technical-documentation retention duty under Article 31 (ten years from market placement), and any Article 14 reporting that was already underway at the moment the period ended. New vulnerabilities discovered after end-of-support do not need to be remediated for that version, but the manufacturer must have published a clear end-of-support date in the product information so users can migrate. See support period and end-of-support disclosure.
When does a CVD intake become an Article 14 trigger?
The trigger is "actively exploited" under Article 3(42), not "reported" or "exploitable". A working proof-of-concept attached to a CVD report is not by itself an Article 14 trigger; it becomes one when there is reasonable belief a malicious actor has used the flaw against a real target. Once that threshold is crossed, the 24-hour early warning to ENISA and the coordinator CSIRT begins, followed by the 72-hour notification and a final report within 14 days of a corrective measure becoming available. See CRA Article 14 reporting.