What does the Cyber Resilience Act require for security updates?
The update rules are where the Regulation touches your release engineering directly, and they are specific.
Security updates must be distributed securely, provided free of charge, delivered in a timely manner, and accompanied by advisory messages telling users what the update addresses [1]. For consumer products, security updates install automatically by default, with a clear and easy-to-use mechanism to opt out [2]. And the baseline the updates defend is itself a requirement: products are made available without known exploitable vulnerabilities and with a secure-by-default configuration [3].
All of this runs for the declared support period — at least five years unless the product's expected use time is genuinely shorter — so the update capability is a long-lived commitment, not a launch feature [4].
What each word means for your pipeline
Securely distributed means the update channel itself is defensible: signed artefacts, an authenticated delivery path [1]. If your update mechanism would accept an attacker's build, the mechanism fails the requirement regardless of the update's content. Free of charge closes the model where security fixes are gated behind a paid maintenance tier: whatever you charge for features, the security update must reach every user of a supported version at no cost [1]. Timely is judged against the vulnerability, not your release calendar — a quarterly release train is fine for features and indefensible for an actively exploited flaw [1]. With advisory messages connects to the public disclosure duty: after the fix is available you publish what it fixed, for which products, with what severity [1] [5].
Automatic by default, for consumers
The auto-update rule is scoped to consumer products, and it is a default, not a mandate — users can opt out, and the opt-out must be clear and easy rather than buried [2]. If you ship a consumer product whose updates are manual-only today, this is a product change to plan, not a documentation exercise [2].
Business and developer products are outside that specific default, but the general duties — secure, free, timely, advised — apply to them identically [1].
Separating security from feature updates
The Regulation's duties attach to security updates, which is a reason to make them separable in your engineering practice [1]. A user who opted out of feature updates, or who stays on an older major version you still support, must still be reachable with the security fix [1]. Monolithic "take everything or nothing" release trains make that hard; a patch lane makes it mechanical.
These duties bind with full application on 11 December 2027, and the support-period commitment you declare then reaches years beyond it [6] [4].
Check where you stand
The checker maps your product to the exact update duties and generates the checklist items your release process needs to satisfy, with citations.
What to do next
Run your own product through the checker — it takes under a minute and gives you a dated, citable result you can send to a customer.
Sources
- Manufacturers ensure secure distribution of updates and that security updates are provided free of charge, in a timely manner, with advisory messages. Annex I Part II(7)–(8) — EUR-Lex ↩
- Security updates are installed automatically by default for consumer products, with a clear and easy-to-use opt-out mechanism. Annex I Part I(2)(c), Recital 56 — EUR-Lex ↩
- Products are made available without known exploitable vulnerabilities and with a secure-by-default configuration. Annex I Part I(2)(a)–(b) — EUR-Lex ↩
- Support period: determined by the manufacturer to reflect the expected use time; at least five years unless the product is expected to be in use for less; the end date (month and year) is stated at purchase. A security update, once issued, remains available for at least ten years or the remainder of the support period, whichever is longer. Art. 13(8), (9), (19) — EUR-Lex ↩
- Manufacturers publicly disclose information about fixed vulnerabilities after a security update is available, including a description, affected products, impacts, severity and remediation information. Annex I Part II(4) — EUR-Lex ↩
- The Regulation applies in full from 11 December 2027. Art. 71(2) — EUR-Lex ↩
Related
- How long is the support period under the CRA?
You set the support period yourself, but it has a floor: it must reflect the time the product is expected to be in use, and at least five years unless the product is expected to be used for less.
- Does the CRA require a coordinated vulnerability disclosure policy?
Yes. Every manufacturer must have a coordinated vulnerability disclosure policy in place, a contact address for reports, a single point of contact for users, and a practice of publishing fixed vulnerabilities.
- What are the fines and penalties under the Cyber Resilience Act?
Fines reach EUR 15 million or 2.5% of worldwide annual turnover for breaching the essential requirements or the core manufacturer obligations, and market surveillance authorities can order withdrawal or recall.
- What goes in the CRA technical file?
A technical file in the Annex VII structure — product description, design and vulnerability-handling documentation, risk assessment, SBOM, test reports — drawn up before market placement and kept for ten years or the support period.
CEMarque encodes Regulation (EU) 2024/2847 and the European Commission's published guidance as of 10 September 2026 (Facts v2026.09.4). It is not legal advice. Verify obligations for your product with qualified counsel where the stakes require it.