Reg (EU) 2024/2847Generate dossier — €149
LIVE — Enforcement tracker · Deadline dashboard · Transposition status — Updated weekly from EUR-Lex, Safety Gate, OEIL & 12 official sourcesView regulatory intelligence →

Secure update mechanisms under Regulation (EU) 2024/2847: automatic security updates by default per Annex I Part I (2)(c), secure distribution per Annex I Part II (7), and free dissemination per Part II (8)

The Cyber Resilience Act treats security updates as a product property, not as an aftermarket service. Annex I, Part I, point (2)(c) requires that vulnerabilities can be addressed through security updates, including, where applicable, automatic updates installed within an appropriate timeframe — enabled as a default setting, with a clear and easy-to-use opt-out mechanism, with user notification, and the option to temporarily postpone. Annex I, Part II, points (7) and (8) require the secure-distribution mechanism itself and that the updates be disseminated without delay and free of charge (unless tailor-made business agreement). Recital 56 carves out products primarily integrated as components, professional ICT networks, and industrial environments. This page maps every OTA requirement to its source. CRACheck documents the update mechanism in the Annex VII technical file.

Generate CRA dossier — €149Free: check if CRA applies to your product

€149 one-time · 8-document ZIP · 15–25 minutes · Browser-side

Regulation (EU) 2024/2847 · Annex I Part I (2)(c) · Annex I Part II (7)+(8) · Recitals 56, 57 · 100% browser-side

Three update properties the regulation actually requires

(2)(c)
Annex I, Part I — automatic security updates by default, with opt-out
(7)
Annex I, Part II — secure distribution mechanism
(8)
Annex I, Part II — free, without delay, with advisory messages

Seven concrete OTA rules — mapped to article text

Each rule below is taken from Annex I or from a recital. The article reference is the operative one for the technical documentation under Annex VII.

1
Rule 1 — Vulnerabilities must be addressable through security updates
Annex I, Part I, point (2)(c): ‘ensure that vulnerabilities can be addressed through security updates’. The update path must exist as a product property, not as an optional add-on. Without it, the product cannot be placed on the market in the relevant configuration.
2
Rule 2 — Automatic security updates, default-on, with opt-out
Annex I, Part I, point (2)(c): ‘where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them’. Recital 56 confirms the design — a default-on regime with a frictionless opt-out path.
3
Rule 3 — Carve-out for components and professional environments
Recital 56: the automatic-update requirement does not apply to products primarily intended to be integrated as components into other products, nor to products for which users would not reasonably expect automatic updates — in particular professional ICT networks and critical and industrial environments where an automatic update could cause interference with operations. The MANUAL update obligation still applies.
4
Rule 4 — Secure update distribution mechanism
Annex I, Part II, point (7): ‘provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner’. Authenticity, integrity and confidentiality of the update channel (TLS, code signing) are implicit in ‘securely’.
5
Rule 5 — Free security updates, without delay, with advisory
Annex I, Part II, point (8): security updates are disseminated without delay and, unless otherwise agreed between manufacturer and business user for a tailor-made product, free of charge, accompanied by advisory messages providing users with relevant information including potential action to be taken.
6
Rule 6 — Separation of security and functionality updates
Annex I, Part II, point (2) + Recital 57: where technically feasible, new security updates shall be provided separately from functionality updates. The user must not be forced to install a feature update to receive a security update. This connects to the substantial-modification analysis under Art. 3(30): a separate security update is generally not substantial; a bundled feature update may be.
7
Rule 7 — End-of-support notification on the device
Article 13(19), second subparagraph + Annex II point 7: where technically feasible in light of the nature of the product, manufacturers shall display a notification to users informing them that their product has reached the end of its support period. The support-period end date (at least month and year) must also be clearly visible at the time of purchase (Art. 13(19) first subpara).
8
Rule 8 — Updates available for 10 years
Article 13(9): each security update made available during the support period shall remain available after it has been issued for a minimum of 10 years, or for the remainder of the support period, whichever is longer.

Common mistakes

OPT-OUT ABSENCE

“We will make automatic updates mandatory — safer for users”

Annex I, Part I, point (2)(c) is explicit: ‘with a clear and easy-to-use opt-out mechanism’. Removing the opt-out makes the product non-compliant. Recital 56 reinforces: ‘Users should retain the ability to deactivate automatic updates, with a clear and easy-to-use mechanism, supported by clear instructions on how users can opt out.’ Mandatory automatic updates are a Tier 1 (Article 64(2)) fine exposure.

PAID SECURITY UPDATES

“Security updates are part of our paid maintenance contract”

Annex I, Part II, point (8) requires security updates to be free of charge, with one narrow exception — a tailor-made product for a specific business user under a bilateral agreement. Outside that narrow case, charging for security updates is a Tier 1 fine under Article 64(2).

BUNDLED RELEASES

“Our release model bundles security fixes with feature updates”

Annex I, Part II, point (2) + Recital 57 require separation where technically feasible. The burden is on the manufacturer to demonstrate that separation is technically infeasible. If feasible and the manufacturer still bundles — with the effect that users must install a feature update to get a security fix — the practice violates point (2) and may also trigger substantial-modification analysis under Art. 3(30).

Does the CRA apply to your product?

Four-question self-check. If you answer YES to all four, your product is in scope of Regulation (EU) 2024/2847.

Take the full product classification test →

Choose your licence

One-time payment. No subscription. The downloaded dossier is yours forever.

1 PRODUCT
149
/ product
  • 8-document CRA dossier (ZIP)
  • Product Classifier + Technical Documentation
  • Risk Assessment + User Information
  • 10 regenerations · 30 days
  • 1 licence = 1 product
Buy licence →

What the ZIP contains

8 PDF documents generated from your data. Each cites the specific article of Regulation (EU) 2024/2847 it complies with.

1

Product Classifier

Determines whether your product is Default, Important Class I, Important Class II (Annex III) or Critical (Annex IV). Documents the rationale and the applicable conformity assessment procedure under Article 32.

2

Technical Documentation

Article 31 + Annex VII dossier. Product description, design and development, vulnerability handling processes, risk assessment, list of harmonised standards applied, conformity solutions.

3

Cybersecurity Risk Assessment

Annex I, Part I analysis. Intended purpose, reasonably foreseeable use, operational environment, applicability of each essential requirement, mitigation measures.

4

User Information & Instructions

Annex II. Manufacturer details, single point of contact, intended purpose, support period end date, secure decommissioning, automatic-update opt-out instructions.

5

EU Declaration of Conformity

Article 28 + Annex V. Pre-structured with your classification, applicable conformity module, harmonised standards or certificates relied on, notified body number when applicable.

6

Coordinated Vulnerability Disclosure Policy

Annex I, Part II, point (5). Single point of contact, intake workflow, triage and remediation timeline, public disclosure rules.

7

ENISA Notification Template

Article 14 reporting. Pre-filled 24h early warning, 72h vulnerability/incident notification, 14-day final report templates.

8

Obligations Calendar

Personalised milestones: Article 14 reporting starts 11 September 2026, full application 11 December 2027, document retention 10 years, support period (Art. 13(8)) end date.

See before you buy — Download sample dossier (PDF, fictional company). Real structure, real articles, real format. Fictional data.

Generated from your data, in your browser. No data leaves your device.

What you pay

🔄 BUILD A COMPLIANT OTA INFRASTRUCTURE FROM SCRATCH
€50,000–€250,000
Code-signing PKI, signed-update verification on the device, staged rollout, opt-out UI, postponement UI, advisory message infrastructure, 10-year update archive. Engineering-heavy.
CRACHECK — SAME OUTPUT
€149
CRACheck does not build the OTA pipeline. It documents your existing or planned pipeline against Annex I, Part I (2)(c) and Annex I, Part II (7) and (8), and includes the design in the Annex VII technical-documentation file.

Legal sources

Every article and recital cited on this page comes from the official text of Regulation (EU) 2024/2847 (Cyber Resilience Act), published in the Official Journal of the European Union on 20 November 2024 (ELI: data.europa.eu/eli/reg/2024/2847/oj).

Related: Regulation (EU) 2019/881 (Cybersecurity Act, EUCC) · Directive (EU) 2022/2555 (NIS2) · Regulation (EU) 2019/1020 (market surveillance) · Regulation (EU) 2024/1689 (AI Act).

Important notice

This is not legal advice. CRACheck is structured self-assessment software based on Regulation (EU) 2024/2847. The dossier you download is structured documentation, not a third-party audit or certification.

Class II and Critical products still need a notified body. CRACheck prepares the dossier that the notified body will examine — it does not replace the third-party conformity assessment required by Article 32(3) and Article 32(4).

Maximum liability: the amount you paid for the licence. Always verify your specific situation with your legal counsel.

Frequently asked questions

Are automatic updates always mandatory under the CRA?
No — only where applicable. Annex I, Part I, point (2)(c) qualifies the obligation: ‘where applicable, through automatic security updates’. Recital 56 carves out products primarily integrated as components into other products, and products for which users would not reasonably expect automatic updates (in particular professional ICT networks, critical and industrial environments). For consumer products, automatic-by-default is the strong norm; for B2B industrial control systems, the manual route with timely notification is acceptable.
Can I charge for security updates to enterprise customers?
Only in the tailor-made-product / business-user scenario explicitly carved out by Annex I, Part II, point (8): ‘unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements’. For standard products sold to enterprises, security updates must be free of charge. The pricing model can charge for feature updates and support — not for security fixes.
What about end-of-support? Can my product just stop updating after 5 years?
The support period must be at least 5 years under Article 13(8), but can and should be longer when the product is reasonably expected to be in use longer — hardware components, motherboards, network gear, operating systems, video-editing tools (Recital 60). At end of support, two things happen: (a) the support-period end date must have been clearly displayed at the time of purchase (Art. 13(19)); (b) where technically feasible, a device-side notification informs the user of end of support (Art. 13(19) + Recital 56). Updates already issued must remain available for 10 more years (Art. 13(9)).
Do I have to use code signing for OTA updates?
The regulation is technology-neutral on this point. Annex I, Part II, point (7) requires that you ‘provide for mechanisms to securely distribute updates’ — ‘securely’ covers authenticity and integrity, which in practice means code signing or an equivalent cryptographic mechanism. Annex I, Part I, point (2)(f) separately requires protection of the integrity of stored, transmitted or otherwise processed data, commands, programs and configuration against any non-authorised manipulation. A signed-update verifier on the device is the conventional way to meet both.
Is this a subscription?
No. One-time payment. 30-day editing window. 10 regenerations. The PDF dossier is yours permanently.
Can I request a refund?
Under Article 16(m) of Directive (EU) 2011/83, the act of licence activation constitutes express consent for immediate digital content generation, which removes the right of withdrawal. Refunds are issued only for reproducible technical failures.
What if the regulation changes before I file my dossier?
Regenerate at no additional cost during your licence validity. Substantive amendments to Regulation (EU) 2024/2847 are tracked weekly from EUR-Lex; if a clause you cited is amended, you can regenerate the affected sections.
€149 one-time
8-document ZIP · 15–25 minutes · Browser-side

Document the OTA mechanism once — reuse across SKUs.

CRACheck records your OTA architecture in the Annex VII technical-documentation file, the user-facing opt-out instructions in Annex II, and the secure-update commitment in the CVD policy and EU declaration of conformity.

Generate dossier — €149