CRA Automatic Security Updates: Default-On, Opt-Out, and Kept Separate From Feature Updates
The Cyber Resilience Act does not just say "ship security patches". It says how they should reach users: automatically where applicable, switched on by default, with a clear way to opt out. This guide explains what that means, where you have room to manoeuvre, and how to design it without breaking your product.
Key points
- Default-on where applicable. Annex I, Part I(2)(c) expects vulnerabilities to be addressable through security updates, including automatic updates enabled by default, "where applicable".
- Users keep control. That means a clear, easy-to-use opt-out, notification when updates are available, and the option to postpone them temporarily.
- Separate security from features. Users should be able to take a fix without taking a behaviour change, where technically feasible.
- "Where applicable" is real but not a loophole. Industrial, air-gapped and on-premises products often cannot update themselves. You still need a documented, workable delivery route.
- Standards help but do not grant presumption. ETSI EN 303 645 and IEC 62443 are useful references. CRA harmonised standards are still in development.
This is general guidance, not legal advice.
What the text says
Annex I, Part I(2)(c) of Regulation (EU) 2024/2847 asks that products ensure vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates installed within an appropriate timeframe, enabled as a default setting, with a clear and easy-to-use opt-out mechanism, notification of available updates, and the option to temporarily postpone them. Annex I, Part II adds the manufacturer's side: security updates are provided free of charge, and disclosed and distributed in a timely way. Check the exact wording on EUR-Lex. Secondary explainers such as this one from Tributech and the Annex I text on cyber-resilience-act.com are useful for orientation only.
This is about the mechanism. For what happens when an upstream component stops getting patches, see when a dependency goes end-of-life. For how long you must keep updating, see the support period explained.
What "where applicable" gives you
The phrase recognises that automatic updates are not sensible everywhere. Reasonable cases include:
| Product situation | Sensible approach |
|---|---|
| Consumer device with internet access | Automatic updates on by default, simple opt-out and postpone |
| Business software with change control | Automatic by default, with an admin policy to schedule or hold updates |
| Industrial or safety-relevant equipment | Notified, signed updates the operator applies in a maintenance window |
| Air-gapped or on-premises deployment | Offline update packages with signature checks, and a documented delivery route (see Distr's guide) |
Whatever you choose, write down the reasoning in your risk assessment and technical documentation. "We did not do it" needs a documented "because" tied to the product's use.
Designing it well
- Verify every update. Use cryptographic signatures and integrity checks, and consider rollback protection so old vulnerable builds cannot be reinstalled.
- Default to on, but make opting out obvious. Bury the switch and you undermine "clear and easy-to-use".
- Notify and allow postponing. Users need to know an update exists and be able to delay it for a short period, for example to finish a job.
- Keep security patches separate from feature releases wherever it is technically feasible, so users are not forced to accept unrelated changes to get a fix.
- Log update events. Records of what was offered, installed or declined help your technical file and any authority request.
- Test the failure path. A failed update should leave the product working and secure.
How the standards relate
ETSI EN 303 645 (consumer IoT) expects secure update support with automatic updating as the default, and IEC 62443 covers update management in industrial settings. They are good design references. They do not yet give presumption of conformity with the CRA. According to the state of play on cyberresilienceact.eu, the first horizontal harmonised standards are expected around 31 October 2026, and none has been cited in the Official Journal yet.
What to do now
Tip: Map each product to a row in the table above and record the decision. See the CRA readiness checklist for where this sits in your plan.
- List every product and how it gets security updates today.
- Note where automatic default-on is feasible and where it is not, with the reason.
- Check the opt-out, notification and postpone flows against the text of Annex I.
- Decide how you will ship security fixes separately from features.
- Add the design decisions to your technical documentation.
Subscribe to The CRA Brief for a calm weekly update as the harmonised standards land.
Related reading
Three Weeks Into CRA Reporting: What Early Users Learned and What a "Disclosure Delay" Really Means
Article 14 reporting has been live for three weeks. Here is what early users of ENISA's Single Reporting Platform report, what a "disclosure delay" does and does not change, and the four things worth doing this week.
CRA SBOM Requirements: What Goes Inside, Which Format Versions to Use, and Where VEX Fits
The CRA says your SBOM must be machine-readable but not what fields it needs. Here is what goes inside, which CycloneDX and SPDX versions still count, and why VEX is optional.
Does the Cyber Resilience Act Require Penetration Testing?
The CRA never mentions penetration testing. Annex I, Part II, point 3 requires "effective and regular" security tests - here is what that means in practice.