ENISA's Secure Update Mechanisms Advisory: A CRA Guide

ENISA wants your feedback before 10 July 2026. Its second product-security technical advisory, Secure Update Mechanisms, is out as a draft and the consultation is open now.

Here is why it matters. The advisory takes the Cyber Resilience Act's requirement to deliver secure updates and breaks it into seven steps, each tied to a real-world failure. Four were attacks: SolarWinds, ASUS, Notepad++, and Trivy. One, the 2024 CrowdStrike outage, was a faulty release rather than an attack. ENISA then maps each step to controls that reduce the likelihood or impact of that threat or failure. This guide pulls out the parts a micro, small, or medium manufacturer needs, ties them to your CRA obligations, adds our own view on tooling and what to prioritise, and walks through the thermostat example ENISA uses to tie it together.

What the advisory is, and what it is not

The ENISA Technical Advisory on Secure Update Mechanisms is a draft dated May 2026, labelled Version 0.1 in its page headers. The published file is named v0.6, which appears to be a typo. ENISA opened it for public consultation with a feedback survey that closes on 10 July 2026.

It targets manufacturers of products with digital elements, and in particular the teams that design, build, or operate update mechanisms. ENISA wrote it for micro, small, and medium manufacturers who need to understand common update threats and apply a set of controls without standing up a large security team.

Be clear about its limits. ENISA states three of them directly:

What it does give you is a shared map. The same seven-step lifecycle runs through the threats section and the controls section, so a control always points back to the threat it answers.

The update lifecycle, in seven steps

ENISA describes any update, whether firmware, a binary, a delta patch, a signature file, or a config change, as moving through the same seven steps. Five actors carry them: the producer (manufacturer), the publication service, the update repository, the client updater, and the endpoint.

The seven steps run across three trust zones. The producer trust domain is where the update is built and signed. The distribution domain, which includes repositories and CDNs, is treated as less trusted. The device trust domain is where the update is verified and installed.

The single most useful idea in the document sits behind that diagram.

How updates actually reach the device

The lifecycle is the same everywhere. Who runs each step is not. ENISA names four delivery models, and the model decides where your controls have to live. The matrix below shows who runs each step, so you can see which cells are yours to build.

The examples ENISA gives: in-band covers desktop app updaters, in-product plugin updaters, and browser auto-update. Platform-managed covers mobile app stores, Linux package repositories, MDM platforms, and browser extension stores. Out-of-band manual covers an installer from a vendor website, a patch via a secure portal, or an emailed package. Enterprise or staged covers WSUS-like staging, enterprise mirrors, patch management servers, and air-gapped transfer.

For simple designs, ENISA describes a device that trusts a root public key plus one operational signing key. More advanced designs use separate signing roles, and higher-assurance deployments add threshold signatures, where more than one key holder must approve a sensitive change. TUF and Uptane formalise that role separation. You do not have to adopt either to meet the baseline.

Seven ways the update channel gets attacked

This is the part to read twice. ENISA walks each lifecycle step, states the threat, the impact, and a real incident. The pattern is consistent: a compromise early in the chain stays invisible if later steps treat everything as normal. The table below is the advisory's section 3, condensed, with the primary control added from its section 4.

The threat model ENISA assumes is broad. Attackers may target build pipelines, signing keys, publication services, repositories, CDNs, DNS, metadata replay, client-side update state, or the installation workflow. The mix of malicious cases (SolarWinds, ASUS) and a non-malicious one (CrowdStrike) is deliberate. A secure update mechanism has to survive both an attacker and a bad release.

STRIDE at a glance

The advisory's Annex 1 maps the threats to Microsoft STRIDE categories. It is an indicative mapping, not exhaustive, and several threats span more than one category. If you run one threat-modelling session this year, use this table as the agenda: walk your update channel stage by stage and ask which STRIDE category bites hardest at each. For a lean team, the Tampering and Spoofing rows at the Retrieve and Check steps deserve the most time, because that is where the ASUS and Notepad++ attacks landed.

The controls, grouped the way ENISA groups them

Section 4 gathers the controls into four stages and aligns them with the ENISA Secure by Design and Default playbook. The full advisory lists 36 named recommendations. The tables below keep the highest-value ones per stage. Read the source for the complete set.

Preparation and publication

This stage covers building, authorising, and publishing the update and its metadata.

Discovery and retrieval

This stage decides how clients find and download updates without being redirected or fed stale data.

Verification and installation

This is the primary trust-decision point. If it fails, earlier compromises become valid updates.

1. Signature verification. Verify the authenticity of metadata, and confirm the artefact is cryptographically bound to it.
2. Applicability validation. Confirm the update fits this product, version, and configuration before installing.
3. Integrity enforcement. Validate the artefact hash and reject any corrupted or modified content before install.
4. Version control and anti-rollback. Block installation of older or unauthorised versions using rollback counters or monotonic sequence numbers.
5. Authorised installation context. Only trusted, authorised components may start and run the install, with least-privilege restrictions. This is the control for the elevated-privilege threat at the install step.
6. Atomic update behaviour. The system transitions fully to the new version or safely stays on the previous one, with recovery on failure.

Observability and recovery

This stage records outcomes, surfaces failures, and lets the device recover.

How teams build this with open-source tools

ENISA keeps the advisory technology-agnostic and names frameworks and guidance such as TUF, Uptane, SLSA, in-toto, and NIST SP 800-40, without recommending specific tools. That is the right call for a regulator, but it leaves the practical question open. The mapping below is ours, not ENISA's. None of these tools is a compliance certificate. They implement the engineering. You still own the evidence.

Build the updater in dependency order

This part is our guidance, not ENISA's. One caveat first: this is not a shortlist to stop at. The CRA requires every essential requirement that applies to your product, based on your risk assessment under Annex I, so the goal is the full set of controls. What follows is the order we would build them in, so a small team is not paralysed by 36 recommendations. The foundation makes the later controls meaningful, so the sequence matters.

1. Sign the metadata and verify on the device. Provision a root trust anchor and check the signature before anything installs. Do this first, because every other control assumes the device only accepts authentic updates. Without it, the rest is decoration.
2. Lock down transport. TLS for discovery and retrieval, and treat any CDN or mirror as untrusted. This is mostly configuration, so it is cheap, and it closes the ASUS-style retrieval attack.
3. Add hash and applicability checks. Small additions at the verify step: confirm the artefact hash matches the signed manifest, and that the update fits this model and version. Low effort once signing is in place.
4. Scope anti-rollback early. It is the hardest control to retrofit, because it needs protected counter state and bootloader cooperation, so plan it now even though it lands later. It is the freeze and downgrade defence ENISA stresses most.
5. Make installs atomic, with rollback. A/B or redundant slots, so a bad release (the CrowdStrike failure mode) does not brick the device. This is a large lift if hand-rolled, which is why a maintained framework usually wins here.
6. Record and report outcomes. A tamper-proof update log and failure reporting, so you can detect a problem and prove what happened. This is also what your CRA evidence draws on.

A worked example: shipping a thermostat patch

ENISA closes with a concrete example, and it is the clearest part of the document. An embedded IoT thermostat at version 1.0.0 needs a security update that patches EUVDB-202X-Y, an input validation flaw. The device uses an in-band updater. The example is illustrative, not a universal blueprint.

The manufacturer runs two signing levels. A root signing authority stays offline and authorises an operational vendor signing key used for routine releases. That split lets the vendor key rotate without changing the device's root trust anchor.

The device ships with the parts shown below.

Preparation. The build runs in a controlled environment with only authorised code and dependencies. An SBOM is generated and vulnerability-checked. The manufacturer produces a signed manifest.json carrying the SHA-256 hash and file size, the applicable product and version, freshness and anti-rollback fields (timestamp, expiry, rollback counter), and advisory information (severity, advisory URL). A byte-level change to the package produces a different hash, caught on device.

openssl dgst -sha256 -sign keys/vendor_private.pem \
  -out repo/manifest.json.sig repo/manifest.json

Discovery. The thermostat checks for updates over TLS, validating the server certificate against ca.pem. The update_type and severity fields let it tell a security update from a routine release and notify the user accordingly. Downloads land in staging, so a power loss mid-download never touches the running firmware.

curl --tlsv1.2 --cacert /etc/ssl/certs/ca.pem \
  https://updates.acme.com/device/manifest.json -o manifest.json

Verification and install. Before installing, the device runs five checks in order. If any fails, it aborts.

The anti-rollback check carries the most weight. The device's rollback counter only goes up after new firmware boots and passes its health checks, so a failed or malicious update cannot quietly raise the floor and lock out a later fix. On success, the firmware writes to the inactive slot and activates with an atomic slot switch, so a known-good version always remains. Observability records every attempt in a permission-restricted update.log with timestamp and status. If the vendor key is ever compromised, the manufacturer signs and ships a new vendor key that the root key authorises. The root key is never updated through this channel. Root compromise needs a separate secure process such as factory reset.

What this means for your CRA file

The advisory's final table pairs each security claim with example evidence and artefacts. That mapping is the bridge to your technical documentation. The CRA's technical documentation asks for both: a description of your secure-update solution (Annex VII) and the evidence behind it, including an SBOM and test reports. A description with nothing behind it is the weak spot.

The example's security claims, and the evidence that backs each one, look like this.

Each row supports one or more CRA Annex I requirements, from integrity and secure distribution to monitoring and availability. See the CRA security update requirements for the article-level detail.

If you cannot produce the right-hand column today, that gap is your work item. A VEX record and an SBOM-driven dependency check cover two of these rows directly. Your supplier due diligence covers the build-trust row for components you did not write.

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.