An update mechanism is a privileged code-delivery path and should be designed as a security-critical subsystem. The manufacturer should control who can produce updates, how packages are signed, how products authenticate them, what happens when installation fails and how affected versions receive corrections throughout the support period.
Update Capability Is Part of the Product Security Architecture
Annex I Part I point 2(c) requires products to ensure that vulnerabilities can be addressed through security updates where applicable and based on the cybersecurity risk assessment. This means the manufacturer should not wait until the first serious vulnerability to discover whether deployed products can be corrected. The update mechanism should be designed while the product architecture is still under development, including how versions are identified, how packages are delivered and which component has authority to install them.
- Define the update mechanism before release.
- Identify supported products and versions.
- Define update authority.
- Test the complete delivery and installation path.
Treat the Update System as a High-Privilege Trust Boundary
An update system is capable of changing code, firmware, configuration or other security-critical product state. Compromise of that path can bypass many other product protections. Threat modelling should therefore cover the release system, signing environment, distribution service, update metadata and verification logic in the product. Access to update-production infrastructure should be more restricted than ordinary development access where the risk justifies it.
- Threat-model the complete update path.
- Separate build and signing authority where appropriate.
- Protect release infrastructure.
- Restrict update publication permissions.
Verify Update Authenticity Before Installation
The product should be able to determine whether an update came from an authorised source. Cryptographic signatures are a common mechanism for doing this. The verification decision should occur before privileged installation changes product state. Failure to authenticate an update should cause rejection rather than silent installation. Trust anchors and signing keys should also have a controlled lifecycle so the manufacturer can replace them when necessary.
- Authenticate update packages.
- Verify signatures before installation.
- Reject unauthorised packages.
- Plan trusted signing-key replacement.
Protect Update Integrity
Authenticity and integrity are closely related in secure updating. An authorised package should not be accepted if it has been altered after signing or publication. Package verification should therefore cover the content that will actually be installed and any security-relevant metadata used to interpret it. Transport encryption can provide useful protection but should not be the only assurance where package-level authenticity and integrity are required.
- Verify package integrity.
- Protect security-relevant update metadata.
- Reject corrupted packages.
- Do not rely solely on transport security.
Protect Signing Keys and Release Authority
Signing keys can authorise software across a large installed base. They should therefore be protected from ordinary developer access, accidental export and uncontrolled use. Depending on risk, manufacturers can use hardware-backed keys, isolated signing systems, restricted CI/CD jobs or multi-person release approval. A key-compromise plan should explain how trust can move to a replacement key without leaving supported products unable to receive future security updates.
- Restrict signing-key access.
- Audit signing operations.
- Separate signing from routine development.
- Plan emergency key replacement.
Automatic Updating Needs Deliberate Product Behaviour
Annex I point 2(c) includes automatic security updates where applicable, installed within an appropriate timeframe and enabled as a default setting, together with a clear opt-out mechanism, user notification and the option to postpone temporarily. The existing CRA automatic-update requirement page covers those legal mechanics in detail. From a development perspective, the update architecture must actually support those behaviours reliably without producing inconsistent state or making user controls ineffective.
- Support the intended automatic-update mode.
- Implement user opt-out correctly where applicable.
- Support temporary postponement.
- Notify users about update availability or activity.
Separate Security Fixes From Feature Changes Where Technically Feasible
Annex I Part II point 2 states that where technically feasible, new security updates should be provided separately from functionality updates. Product architecture can make this easier or harder. Teams should consider whether update packaging allows urgent security corrections to ship without waiting for unrelated feature work. A release system that permanently couples every security fix to a large functionality release can increase exposure time after a vulnerability is discovered.
- Support security-only releases where technically feasible.
- Avoid delaying patches for unrelated functionality.
- Document technical constraints that prevent separation.
- Test the security-only update path.
Failed Updates Should Leave the Product in a Safe State
Power loss, storage exhaustion, network interruption, corrupted packages or unexpected dependencies can cause installation failure. ENISA's Secure by Design and Default Playbook recommends that failed updates should not leave the product insecure or unusable. Product teams should define transactional installation, recovery images, staged activation or another safe-failure mechanism appropriate to the product. The recovery path should itself preserve authenticity and integrity controls.
- Test interrupted installation.
- Define safe recovery behaviour.
- Protect recovery artefacts.
- Avoid partial insecure states.
Control Rollback and Downgrade Behaviour
Rollback can help recover from a defective update, but unrestricted downgrade can allow installation of an authentic older version containing known vulnerabilities. The product should distinguish operational rollback from attacker-driven downgrade. Depending on the risk, teams can use minimum supported versions, rollback authorisation, protected version counters or limited recovery windows. The correct design depends on the product and availability requirements.
- Assess downgrade attacks.
- Define authorised rollback conditions.
- Prevent uncontrolled return to vulnerable versions.
- Test recovery and rollback separately.
Target Updates to the Correct Product and Version
Security remediation depends on knowing which product versions are affected and which package belongs to them. Update metadata should therefore identify product family, version, platform or other compatibility information needed to prevent installation of an inappropriate package. The manufacturer should also be able to connect a vulnerability record to the affected version and the update that remediates it.
- Identify affected product versions.
- Validate update compatibility.
- Prevent cross-product installation errors.
- Maintain vulnerability-to-update traceability.
Secure Distribution Continues After Package Creation
Annex I Part II point 7 requires mechanisms to securely distribute updates so vulnerabilities can be fixed or mitigated in a timely manner. The product should be able to locate and obtain the correct update through a trustworthy distribution path, while package-level verification protects against unauthorised content. Distribution capacity and availability should also be considered where a serious vulnerability could require a large installed base to update quickly.
- Protect update discovery.
- Protect distribution metadata.
- Maintain package-level verification.
- Plan sufficient distribution capacity.
Retain Update-System Design and Test Evidence
Annex VII expects the technical documentation to describe the technical solutions chosen for secure distribution of updates. Useful evidence can include update architecture, signing-key design, trust anchors, package format, version-targeting logic, opt-out and postponement behaviour, failure tests, rollback tests and release records. The evidence should identify which product version and update-system version were tested.
- Update architecture.
- Signing and verification design.
- Failure and recovery tests.
- Rollback tests.
- Automatic-update behaviour tests.
- Version-specific release evidence.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.