ENISA published version 1.0 of the Technical Advisory on Secure Update Mechanisms on 4 November 2026. The advisory gives manufacturers 38 controls to sign, deliver, verify and install product updates, and links them to CRA Annex I.
Key takeaways
- Version 1.0 replaces the May 2026 draft, version 0.6, after a public consultation in June and July 2026 that received 12 contributions.
- The 38 controls are in four stages. Preparation and publication has 12, discovery and retrieval has 9, verification and installation has 9, and observability and recovery has 8.
- The trust model treats update repositories, CDNs and mirrors as untrusted. A device accepts an update only after it verifies signed metadata up to a provisioned root key.
- Section 1 of the advisory states that it is not legal advice, not a formal interpretation of the CRA and not a presumption of conformity.
What is in the advisory
The advisory splits an update into seven steps. They are build and sign, publish, check for updates, retrieve, verify, install and record status. Section 3 gives the threats at each step and a real incident for most of them.
| Step | Threat | Incident in the advisory |
|---|---|---|
| Build, package, establish trust | Build pipeline or signing key compromise | SolarWinds |
| Publish | Metadata or payload manipulation | Trivy |
| Check for updates | Redirection, fake update source, replay or freeze | Notepad++ |
| Retrieve | Payload substitution or malicious artefact | ASUS Live Update (ShadowHammer), 2019 |
| Verify | Missing or weak verification, downgrade | Notepad++ |
| Install | System compromise or installation failure | CrowdStrike Falcon, 2024 |
| Record status | Failure not detected, reported or acted upon | CrowdStrike Falcon, 2024 |
Section 5 applies the controls to a thermostat firmware update. The example uses a root key kept offline, a separate signing key, a signed manifest with a SHA-256 hash, two firmware slots and an anti-rollback counter. Table 8 then lists the security claims a manufacturer can make for that design and the evidence for each claim.
What changed from the draft
Most changes between version 0.6 and version 1.0 are editorial. The changes below matter to a manufacturer.
| Change in version 1.0 | Section |
|---|---|
| New control "Update service continuity". Plan how the update service stays available, moves or retires over the supported product lifetime. Clients fail safely and do not fall back to unauthenticated or insecure update sources. | 4.2 |
| New control "Secure boot integration". The product verifies bootable images against protected trust anchors before they run. Secure boot is also added to the baseline trust model and to the install threats. | 2.1, 3.6, 4.3 |
| VEX is named as a machine-readable way to tell users whether a vulnerability affects a product, version or configuration. | 4.1 |
| An update can have several parts, such as bootloader, application firmware, modem firmware and configuration. Each part can have its own applicability, version and rollback rules. | 2.1 |
| Loss of power or connectivity can interrupt an update, in particular on embedded products. | 2.1 |
| In the example, the anti-rollback counter goes up only after the new firmware boots and passes health checks. | 5.3.3 |
| The Annex I references use the numbering of the regulation, for example Part II point (7). The draft wrote 2.7. | 1 |
Which CRA requirements does the advisory name?
Section 1 names six points of CRA Annex I. The right-hand column is our reading, because the advisory maps no single control to a single point. Read each point in the CRA text, because several carry qualifiers such as "where applicable" and "where technically feasible".
| CRA point | Advisory controls that support it |
|---|---|
| Annex I Part I (2)(c) | Support for automated update retrieval, controlled update discovery and notification |
| Annex I Part I (2)(f) | Signature verification, integrity enforcement, integrity failure reporting |
| Annex I Part II (2) | Update structuring and release strategy |
| Annex I Part II (4) | Advisory linkage and user-facing information |
| Annex I Part II (7) | Trusted update source, strong transport security, separation of trust domains |
| Annex I Part II (8) | Controlled-release workflow, advisory linkage and user-facing information |
The CRA text is in Annex I of Regulation (EU) 2024/2847. The advisory names no single architecture and requires no specific update framework. ENISA states that the controls are consistent with The Update Framework (TUF), Uptane and NIST SP 800-40. Open-source update ecosystems and sector rules are outside its scope, and ENISA says that later advisories can cover them.
What changes in CVD Portal
When CVD Portal generates the STRIDE threat model of a product, it now uses the seven update life-cycle threats of the advisory next to the core CRA threat catalogue. Each threat carries a CRA Annex I reference and a default mitigation taken from the controls of the advisory. The regulatory reference lookup returns the text of version 1.0.
We explain how the advisory relates to the legal duties in what is the ENISA Technical Advisory on Secure Update Mechanisms.
Sources
- ENISA Technical Advisory on Secure Update Mechanisms, version 1.0, 4 November 2026, doi 10.2824/9223658, CC BY 4.0.
- Regulation (EU) 2024/2847, the Cyber Resilience Act, CELEX 32024R2847, Annex I.
Add the seven update life-cycle threats to the threat model of each product.
Start a trial