What is the ENISA Technical Advisory on Secure Update Mechanisms?

The ENISA Technical Advisory on Secure Update Mechanisms is EU agency guidance of 4 November 2026 on how manufacturers sign, deliver, verify and install product updates. The advisory adds no CRA requirements.

The CRA update duties stay in Annex I Part I (2)(c) and (2)(f) and Part II (2), (4), (7) and (8). The advisory still matters. CRA Annex VII point 2(b) asks the technical documentation for "a description of the technical solutions chosen for the secure distribution of updates". The advisory is the first ENISA document that gives that description a structure, from the build pipeline to the update log on the device.

Key takeaways

• The ENISA update mechanisms advisory is guidance for teams that design, implement or operate update mechanisms, in particular at micro, small and medium-sized manufacturers.
• CRA Article 27 gives a presumption of conformity to harmonised standards, common specifications and European cybersecurity certification schemes, and an ENISA technical advisory is on none of those routes.
• The advisory splits an update into seven steps, gives the threats at each step with their STRIDE categories, and lists 38 controls in four stages.
• The trust model treats repositories, CDNs and mirrors as untrusted, so a device trusts an update only through signatures that chain to a provisioned root key.
• Table 8 of the advisory pairs each security claim with evidence and artefacts, which is a ready form for the update part of the technical documentation.

Where does the advisory come from?

The ENISA Technical Advisory on Secure Update Mechanisms is a 26-page guidance document from the EU Agency for Cybersecurity, version 1.0, published on 4 November 2026 under CC BY 4.0 (doi 10.2824/9223658). It describes how manufacturers of products with digital elements can deliver updates securely, in a timely manner and reliably.

ENISA published a draft, version 0.6, in May 2026 and held a public consultation in June and July 2026. It received 12 contributions from manufacturers, practitioners, the open-source community and others. Version 1.0 is the final text, and ENISA says that it may revise the document.

The scope has three limits. The advisory gives no single best architecture and requires no specific update framework, although ENISA states that its controls are consistent with The Update Framework (TUF), Uptane and NIST SP 800-40. It does not explain how to write, test or validate a patch. Open-source update ecosystems and sector rules are outside its scope.

Does the advisory change what the CRA requires?

No. The CRA sets the outcomes, and the advisory describes one way to reach them. Only the first two rows of the table below are law.

Layer	Status	What it asks for
CRA Annex I Part I (2)(c) and (2)(f), Part II (2), (4), (7) and (8)	EU law, applies from 11 December 2027	The text of each point in Annex I. Several points carry qualifiers, such as "where applicable" in Part I (2)(c) and "where technically feasible" in Part II (2)
CRA Annex VII point 2(b)	EU law, applies from 11 December 2027	"a description of the technical solutions chosen for the secure distribution of updates", in the technical documentation
ENISA Technical Advisory on Secure Update Mechanisms	EU agency guidance	Seven life-cycle threats, 38 controls, a worked firmware example and a claims and evidence table

The advisory says so itself. Section 1 states that it is not legal advice, not a formal interpretation of the CRA and not a presumption of conformity, and that compliance depends on the product, its risks and its intended use. ENISA also asks for the controls to be applied in proportion to the risk profile, architecture, resources and deployment context of the product.

What does the advisory add to the CRA text?

The advisory adds the engineering detail that the CRA leaves open. The CRA asks for "mechanisms to securely distribute updates" in Annex I Part II (7) and names no technique. The advisory names the techniques and the failure each one prevents.

Topic	Closest CRA point	Advisory
Trust model	Annex I Part II (7)	The distribution domain is untrusted. Trust comes from signatures that chain to a root key, with a separate operational signing key. Higher-assurance designs add signing roles and threshold signatures (sections 2.1 and 2.3)
Freshness and rollback	No point names it	Metadata carries an expiry, a timestamp or a version number. The device rejects stale or replayed metadata and keeps a protected anti-rollback counter (sections 4.2 and 4.3)
Safe installation	Annex I Part I (2)(h)	Atomic installation, A/B slots or an equivalent, secure boot, and recovery to a known-good version (section 4.3)
Update status	Annex I Part I (2)(f)	Record each outcome in a protected log, report verification failures, show the status to the user or administrator (section 4.4)
Signing keys	No point names it	Protected key storage, separate key roles, rotation and revocation, and a separate recovery process for a compromised root key (sections 4.1 and 4.4)
Service lifetime	Article 13(8)	Update service continuity. The service stays available, moves or retires securely over the supported product lifetime (section 4.2)
Security and functional updates	Annex I Part II (2)	Update structuring and release strategy, with automatic installation of security updates by default where possible (section 4.1)

Which threats does the advisory list?

Section 3 gives one group of threats for each of the seven life-cycle steps, and Annex 1 maps each group to STRIDE categories. Most groups come with a real incident.

Step	Threat	STRIDE categories (Annex 1)	Incident in the advisory
Build, package, establish trust	Build pipeline or signing key compromise	Tampering, spoofing, elevation of privilege	SolarWinds
Publish	Metadata or payload manipulation	Tampering, spoofing, denial of service	Trivy
Check for updates	Redirection, fake update source, replay or freeze	Spoofing, tampering, denial of service	Notepad++
Retrieve	Payload substitution or malicious artefact	Tampering, spoofing, denial of service	ASUS Live Update (ShadowHammer)
Verify	Missing or weak verification	Spoofing, tampering	Notepad++
Install	System compromise or installation failure	Elevation of privilege, tampering, denial of service	CrowdStrike Falcon, SolarWinds
Record status	Failure not detected, reported or acted upon	Repudiation, tampering, denial of service	CrowdStrike Falcon

One incident had no attacker. The CrowdStrike Falcon outage of 2024 was a faulty update, and the advisory uses it for both the install step and the record status step. A threat model of an update mechanism therefore covers defects as well as attacks.

How does the worked example turn controls into evidence?

Section 5 applies the controls to the firmware update of a home thermostat with a built-in update client. The manufacturer keeps a root key offline and signs a manifest with an operational key. The manifest carries a SHA-256 hash, the file size, the target model and version, an expiry time, a rollback counter and the advisory URL. The device downloads to a staging area, checks the key chain, the signature, the hash, the counter and the applicability, then writes the image to the inactive of two slots.

The counter goes up only after the new firmware boots and passes its health checks. A failed boot reverts to the known-good slot. Table 8 then lists 14 security claims with the evidence and the artefacts for each one.

Example claim from Table 8	Example evidence	Example artefacts
Update origin and build inputs are traceable	Controlled build, dependency checks, SBOM	Build logs, SBOM, SCA and SAST results, CI/CD records
The device is protected against downgrade attacks	Version and anti-rollback checks	Anti-rollback state, manifest version, counter or sequence number
Unsuccessful trial activation can fall back to the previous verified firmware	A/B slots, atomic slot switch, known-good state after health checks	Slot records, boot status, health check logs

The three-column form fits the Annex VII point 2(b) description well. A reviewer reads one claim, sees how the manufacturer supports it, and knows which file to ask for.

What should a manufacturer do with the advisory?

Start with the delivery model, because it decides who owns each step. Then work through the steps in order.

1. Name the delivery model. The advisory has four, which are in-band (built-in) updaters, platform-managed updates, out-of-band manual updates and enterprise-managed or staged updates. With a platform such as an app store, the platform does part of the verification. With a manual update, the user does part of it, so clear instructions matter more.
2. Write down the trust anchor and the keys. Record the root key, how it is provisioned, which key signs releases, and how a compromised signing key is replaced. Record the separate process for a compromised root key.
3. Check the seven threats against the product. Put each threat group in the risk assessment, with the assets it targets and the controls that treat it.
4. Separate security updates from functional updates where feasible. Annex I Part II (2) says "where technically feasible, new security updates shall be provided separately from functionality updates". Ship each security update with an advisory message, and consider VEX for machine-readable status.
5. Plan the update service to the end of the support period. Decide how the update hosts, certificates and keys stay valid, and how devices fail safely if the service changes.
6. Record claims and evidence in the Table 8 form. Use the result as the update part of the technical documentation.

How does CVD Portal use the advisory?

CVD Portal generates the STRIDE threat model of a product from a threat catalogue and the asset list of the product. From 4 November 2026 the catalogue includes one threat for each of the seven life-cycle steps of the advisory, each with a CRA Annex I reference and a default mitigation taken from the controls. The regulatory reference lookup in the platform returns the text of version 1.0.

The model proposes the threats, and a person confirms them in the dashboard. For the wider picture of why updates carry legal weight under the CRA, see why does a fridge need a security update.

Primary sources

• ENISA Technical Advisory on Secure Update Mechanisms, version 1.0, 4 November 2026, doi 10.2824/9223658, CC BY 4.0. Sections 1 to 5, Tables 1 to 9 and Annex 1 as cited above.
• Regulation (EU) 2024/2847, the Cyber Resilience Act, CELEX 32024R2847. Article 13(8), Article 27, Annex I and Annex VII point 2(b).