Every CRA manufacturer needs a live vulnerability-handling process for each product: know what is inside the product, find and fix vulnerabilities, test regularly, publish advisories, receive external reports, and ship security updates securely and free of charge. This page explains that operating model and where it hands off to urgent regulatory reporting. For the combined Article 14 overview see vulnerability handling and reporting.
Summary
- Vulnerability handling is an engineering operating model every CRA manufacturer needs 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 are free by default, with a narrow carve-out for tailor-made products supplied to business users.
- The CVD policy is mandatory, not optional: coordinated vulnerability disclosure is part of CE-marking readiness, not a voluntary best practice.
- Vulnerability handling runs throughout the support period; the minimum is five years from market placement unless the expected product-in-use period is shorter and disclosed.
- Vulnerability handling is not urgent regulatory reporting: handling is the day-to-day engineering process; reporting starts only for active exploitation or severe incidents.
The four anchors that frame CRA vulnerability handling: scope, duration, update cost, and the boundary with urgent reporting.
The eight vulnerability-handling duties
The CRA does not treat vulnerability handling as a one-off checklist. It expects a continuous lifecycle that runs throughout the support period, from component inventory through remediation, disclosure, and secure update delivery. The table groups the eight duties by the operational phase where each one normally runs.
| Phase | Points | What it covers | Operational focus |
|---|---|---|---|
| Detect and catalogueIntake and inventory | Points 1 and 6 | SBOM-based identification of components and known vulnerabilities, plus a public reporting channel. | Keep component data current and make it easy for external reporters to reach the product security team. |
| Engineer and fixRemediation and testing | Points 2 and 3 | Remediation without delay and effective regular testing of the codebase and dependencies. | Use severity to set urgency, then preserve evidence that fixes and tests happened on time. |
| DistributeSecure update channel | Points 7 and 8 | Signed, authenticated security updates, separable from features and free of charge except for tailor-made B2B products. | Ship security fixes without forcing users into feature upgrades or paid maintenance tiers. |
| Coordinate and discloseCVD and advisories | Points 4 and 5 | An enforced coordinated vulnerability disclosure policy and public advisories once a fix is available. | Coordinate researcher intake, user notice, and justified disclosure delays from one playbook. |
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
Vulnerability handling runs for the whole support period. The default minimum is five years from the date the product is placed on the EU market, unless the expected product-in-use period is shorter and disclosed. The support-period end date must appear in the product information. Once that period ends, the active handling duties lapse for that product version, but the technical documentation and declaration of conformity must still be retained for 10 years after market placement or for the support period, whichever is longer. See CRA support period.
Vulnerability handling is not urgent reporting
The CRA distinguishes two duties that operate on different surfaces and different audiences:
- Vulnerability handling is the engineering process: SBOM, remediation, CVD policy, public disclosure, and secure updates. It applies to all vulnerabilities throughout the support period and sits with the manufacturer's product security organisation.
- Urgent regulatory reporting starts only when there is an actively exploited vulnerability or a severe incident having an impact on the security of the product. It is filed through the ENISA Single Reporting Platform on a 24h / 72h cadence, plus a final report (14 days after a corrective or mitigating measure is available for an actively exploited vulnerability, or one month after the 72-hour notification for a severe incident), to ENISA and the CSIRT designated as coordinator. For SRP onboarding mechanics, see ENISA SRP onboarding.
A product team can run a compliant vulnerability-handling process while never filing an urgent report, because most vulnerabilities are remediated before they are actively exploited. Reporting only starts when remediation has not yet caught up with active exploitation or a severe incident. See CRA vulnerability reporting.
Penalty exposure
Vulnerability-handling failures can carry serious administrative fines, but the detailed tiering belongs in the dedicated enforcement guide. See CRA penalties and enforcement for the fine levels, enforcement triggers, and how vulnerability-handling failures fit into the wider penalty model.
Frequently Asked Questions
Does the SBOM have to cover transitive dependencies?
The legal floor is top-level dependencies, but a practical SBOM should usually go deeper. You cannot remediate a CVE in a transitive component without delay if you never catalogued that component. 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: tailor-made products supplied to a business user can use a paid arrangement where the manufacturer and the business user 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 exposes the manufacturer to the top-tier fines.
Do vulnerability-handling duties continue after the support period ends?
No. The eight vulnerability-handling duties lapse for that product version when the support period ends. New vulnerabilities found after end-of-support do not have to be remediated for that version, provided the manufacturer published a clear end-of-support date so users can migrate. Two duties continue regardless. The technical documentation and EU declaration of conformity must still be kept for 10 years from market placement or for the support period, whichever is longer. Reporting is separate from handling: if the manufacturer becomes aware of an actively exploited vulnerability or a severe incident in the product, the Article 14 reporting duty can still apply, because it is not tied to the support period. See support period and end-of-support disclosure.
When does a CVD intake need urgent reporting?
The trigger is active exploitation, not a private report or proof of exploitability. A working proof-of-concept attached to a CVD report is not by itself reportable; it becomes reportable 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 vulnerability reporting.