CRA Update Management: Security Updates per Art. 10

Under Art. 10 and Annex I Part II of the CRA (EU 2024/2847), manufacturers of products with digital elements must handle vulnerabilities effectively for the entire support period. This means identifying and documenting vulnerabilities and components — including a software bill of materials (SBOM) — addressing vulnerabilities without delay, and distributing security updates free of charge through secure mechanisms. Updates must be made available promptly after a fix exists, accompanied by advisory information describing the vulnerability and the action users should take. Security updates must be deliverable separately from functionality updates, and the product must be designed so that updates can be installed reliably, with automatic installation as the default where the product category supports it. These obligations apply regardless of whether the product is sold once or licensed continuously.

The CRA requires manufacturers to define a support period that reflects the time the product is reasonably expected to be in use — as a rule, at least five years. For products with a demonstrably shorter expected lifetime, a shorter period may be justified; for long-lived products such as industrial components, a longer period is expected. The support period must be stated transparently at the time of purchase, including a clearly indicated end-of-support date. In addition, manufacturers must keep technical documentation and make security updates that were issued during the support period available for at least ten years. Defining the support period is therefore a strategic product decision: it drives engineering capacity, component selection and contractual commitments across the entire portfolio.

The CRA establishes a strict multi-stage reporting process for actively exploited vulnerabilities and severe incidents affecting product security.

🔍 The key stages:

Yes — security updates within the support period must be provided free of charge and made available without delay. For many product categories, particularly consumer products, the CRA additionally expects automatic security updates to be enabled as the default setting, with a clear and easy opt-out mechanism for users who need to control update timing. Users must be informed about available updates, and the update mechanism itself must be secure: cryptographically signed packages, integrity verification before installation and rollback capability if an update fails. For enterprise and industrial products where automatic installation could disrupt operations, manufacturers can offer deferred deployment, but they must still notify users promptly and make installation straightforward. The guiding principle is that staying secure must not depend on user effort or payment.

The CRA requires that security updates can be delivered separately from functionality updates wherever technically feasible. The rationale is user protection: customers must be able to close vulnerabilities without being forced to accept new features, changed behavior or new license terms. For many manufacturers this is the most disruptive requirement, because established release trains bundle fixes and features into combined versions. In practice it means maintaining patchable release branches for every supported version, building CI/CD pipelines that can produce security-only packages, and defining a backporting strategy for older versions still within the support period. We help you redesign the release architecture and versioning policy so that security-only updates become routine rather than exceptional effort — a prerequisite for meeting the "without delay" expectation.

The CRA entered into force in December 2024. The reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026, and the main obligations — including the full update and vulnerability handling requirements — apply from 11 December 2027 to products placed on the market from that date. Products undergo conformity assessment against these requirements, so update management directly affects market access and CE marking. A realistic preparation sequence: gap analysis of current patch and vulnerability management against Art. 10 and Annex I, definition of support periods per product line, implementation of secure update distribution and SBOM-based vulnerability monitoring, and preparation of the technical documentation per Annex VII. Starting early matters because architecture changes — signed update channels, separable security releases — need full development cycles to land.