CRA automatic security updates are part of a broader vulnerability-remediation system. Manufacturers should determine when automatic installation is appropriate, enable it by default where the requirement applies, provide clear user control, protect update authenticity and integrity, notify users about available security updates and verify that update delivery remains effective throughout the support period.
Annex I Connects Security Updates Directly to Vulnerability Handling
Annex I Part I point 2(c) requires products with digital elements to ensure that vulnerabilities can be addressed through security updates, on the basis of the cybersecurity risk assessment and where applicable. This makes update capability part of product security architecture rather than an optional support feature added after release. A manufacturer should understand how a security defect discovered during the support period can be corrected in products already supplied to users. The update path can involve software packages, firmware, cloud-managed components or another mechanism appropriate to the product, but the manufacturer should be able to demonstrate that security corrections can reach affected products effectively.
- Define how security corrections reach supported products.
- Identify products and versions affected by an update.
- Protect the update process throughout the support period.
- Test update installation and failure behaviour.
- Connect update capability to vulnerability remediation.
Automatic Security Updates Apply Where Appropriate
Point 2(c) expressly includes automatic security updates where applicable. The CRA therefore does not state that every product must use the same automatic installation model. The cybersecurity risk assessment, product architecture and operating environment should inform whether automatic security updates are appropriate. A consumer-connected product can have different update needs from a specialised system whose maintenance is tightly controlled by a professional operator. Where automatic updates are applicable, the implementation should be reliable enough that users are not required to discover every vulnerability and manually search for a patch before the product receives protection.
- Assess whether automatic installation is applicable.
- Document the product-specific rationale.
- Consider operational and safety dependencies.
- Avoid relying entirely on user awareness where automatic updates are appropriate.
- Verify the complete automatic update path.
Applicable Automatic Updates Should Be Enabled by Default
Annex I point 2(c) states that applicable automatic security updates should be enabled as a default setting. This means a product should not normally require the user to discover and activate the security-update capability after installation where automatic updates are the applicable approach. The default should be tested in the actual marketed product because packaging, deployment profiles or administrative templates can change the setting between development and release. The secure-by-default requirement and the update requirement reinforce each other, but they should still be mapped separately in the Annex I compliance evidence.
- Verify the marketed default state.
- Check all supported product editions.
- Check deployment templates and installation modes.
- Prevent release changes from silently disabling updates.
- Maintain requirement-specific evidence.
Users Need a Clear and Easy-to-Use Opt-Out Mechanism
Point 2(c) does not describe automatic updating as an unavoidable background process. It expressly requires a clear and easy-to-use opt-out mechanism. Manufacturers should therefore design user control into the update system and ensure that the option is understandable and functional. The product should accurately communicate what opting out changes and what security consequences can follow. The opt-out design should not be hidden behind unnecessary complexity merely to discourage its use. Product teams should test both the default automatic path and the opt-out path because each forms part of the expected behaviour.
- Provide a clear opt-out control.
- Explain what the control changes.
- Test that opting out actually changes automatic installation behaviour.
- Continue to make update information available.
- Document the security implications.
Temporary Postponement Is Separate From Opting Out
Annex I point 2(c) also refers to an option for users to temporarily postpone security updates. Postponement and opt-out should not be treated as identical controls. A user may need to delay installation briefly because of operational timing, compatibility testing or maintenance windows while still intending to receive the update later. Manufacturers should define how postponement works, whether limits or reminders apply and how the product returns to the update path. The design should avoid indefinite accidental delay where the user intended only a temporary postponement.
- Distinguish postponement from opt-out.
- Define the temporary postponement workflow.
- Provide appropriate reminders where useful.
- Return the product to the update path.
- Test postponed update installation.
Users Should Be Notified About Available Security Updates
Point 2(c) includes notification of available updates to users. This remains relevant even where automatic updating is used because users can need information about security corrections, planned installation, necessary action or update status. Notifications should provide useful information without overwhelming users with low-value messages. The product and support model should determine the appropriate communication channel. Where users have opted out of automatic installation, update notification becomes particularly important because the manufacturer should not assume that the user will independently discover that a security correction is available.
- Notify users that relevant security updates are available.
- Provide useful action information.
- Support users who have disabled automatic installation.
- Avoid misleading update status.
- Test update notification behaviour.
Security Updates Need Secure Distribution
Annex I Part II point 7 requires mechanisms to securely distribute updates so that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, automatically. An update system can create a highly privileged attack path because it delivers code or configuration that the product trusts. Manufacturers should therefore protect update authenticity and integrity, secure the transport and metadata where appropriate, control signing keys and prevent unauthorised packages from being accepted. Update verification should fail safely if authenticity or integrity checks do not succeed.
- Authenticate update packages.
- Protect update integrity.
- Protect signing keys.
- Validate update metadata.
- Reject unauthorised or corrupted packages.
Security Updates Should Be Disseminated Without Delay
Annex I Part II point 8 requires security updates that address identified security issues to be disseminated without delay. Unless the Regulation's specific tailor-made business-product agreement applies, those updates are also to be provided free of charge and accompanied by advisory messages containing relevant information, including action users may need to take. The manufacturer should therefore connect remediation, release engineering, distribution and user communication into one operational workflow. A completed patch that remains unavailable to affected users does not complete the vulnerability-handling process.
- Release security updates without unnecessary delay.
- Coordinate engineering and distribution.
- Provide relevant advisory information.
- Identify user action where needed.
- Track whether affected versions can receive the update.
Security and Functionality Updates Should Be Separable Where Technically Feasible
Annex I Part II point 2 provides that, where technically feasible, new security updates should be provided separately from functionality updates. This helps users receive security corrections without being forced to adopt unrelated new functionality simply to address a vulnerability. Manufacturers should consider update packaging and release processes with this objective in mind. A combined package can still be justified where technical architecture makes separation infeasible, but the product team should understand the reason rather than combine all changes by default because it is operationally convenient.
- Identify security-only changes.
- Separate security and feature updates where technically feasible.
- Document technical constraints.
- Avoid delaying security fixes for unrelated features.
- Test security-only update paths where supported.
Evidence for CRA Automatic Security Updates
Evidence can include update architecture, default-setting specifications, opt-out and postponement flows, update-signing design, key-management controls, package-verification tests, notification behaviour, release procedures and records showing timely dissemination. Manufacturers should also retain evidence for failure and rollback behaviour because an update that leaves a product unusable or insecure can create additional risk. Evidence should identify the relevant product version and support configuration. Update-system changes should trigger review because they directly affect the manufacturer's ability to remediate future vulnerabilities.
- Update architecture.
- Automatic-update default verification.
- Opt-out and postponement tests.
- Update signing and verification evidence.
- User notification tests.
- Security-update release records.
- Secure distribution verification.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.