ENISA's advisory on secure update mechanisms: what it means for app teams
· 5 min read · CRA news
In short: on 4 November 2026 ENISA published version 1 of its Technical Advisory on Secure Update Mechanisms, practical guidance for manufacturers, especially smaller ones, on how to build, sign, deliver and verify updates.
- It splits an update's life into seven steps, from build to recording whether the update installed, and suggests controls for each.
- Its core idea: trust an update because its signature checks out, not because of where it was downloaded from.
- ENISA links the controls to the CRA's update requirements in Annex I, but says the document is not legal advice and gives no presumption of conformity.
- For app teams, the store covers part of the chain. Anything your app downloads and runs by itself is your responsibility.
What ENISA published
The EU cybersecurity agency released the advisory on its product security pages on 4 November 2026. It is written for teams that design or run update mechanisms, with micro, small and medium-sized manufacturers as the main audience, and ENISA notes it may also be useful to larger companies. According to the document, it was revised after a public consultation in June and July 2026 that drew 12 contributions.
The advisory is technology-agnostic and does not prescribe an architecture. It says it is consistent with frameworks such as TUF, Uptane and NIST SP 800-40.
The seven steps
ENISA models the update life cycle as seven steps, grouped into four control stages:
| Stage | Steps | Examples of recommended controls |
|---|---|---|
| Preparation and publication | 1. Build, package, establish trust · 2. Publish | Sign update metadata and bind artefacts to it; keep signing keys in protected hardware with separate roles; isolated builds; approval gates and staged roll-outs; ship security fixes separately from feature changes. |
| Discovery and retrieval | 3. Check for updates · 4. Retrieve | Authenticated sources only, strong TLS with no fallback to insecure protocols; validate redirects; treat CDNs and mirrors as untrusted; security updates on by default where feasible. |
| Verification and installation | 5. Verify · 6. Install | Check signature, hash and applicability before unpacking or running anything; anti-rollback version checks; atomic installs; retry or fall back to a known-good version. |
| Observability and recovery | 7. Record status | Log update outcomes and protect the logs; report verification failures; make status visible; be able to rotate or recover trust anchors. |
On user control, ENISA's position is balanced: users should be informed and may postpone or opt out, but those controls should not block critical fixes.
The advisory ends with a worked example, a fictional smart thermostat receiving a firmware patch, and a table of 14 security claims, each paired with the evidence that would back it up: build logs, an SBOM, CI/CD records, signing and verification logs, and rollback records. ComplexDiscovery, which analysed the advisory on 7 November, reads this as turning the update pipeline into an evidence trail. We agree that this is the most useful part for anyone preparing CRA technical documentation.
How it links to the CRA
The advisory points to several update-related requirements in Annex I of Regulation (EU) 2024/2847, as ENISA lists them:
- Annex I, Part I, point (2)(c): security updates, automatic where applicable, with user controls and notification.
- Annex I, Part I, point (2)(f): integrity protection and reporting of corruption.
- Annex I, Part II, points (2), (7) and (8): timely remediation, separating security from functionality updates where feasible, secure distribution, and prompt dissemination with user notification.
Separately, Article 13(9) requires that each security update made available during the support period stays available for at least 10 years after it is issued, or for the rest of the support period if that is longer. These essential requirements apply from 11 December 2027. Reporting of actively exploited vulnerabilities has applied since 11 September 2026, and a reported vulnerability usually ends in an update, so the two are linked in practice.
ENISA is clear about the limits: the advisory is not legal advice, not a formal interpretation of the CRA, and not a presumption of conformity.
What this means for mobile apps
The advisory's example is a device, not an app, so the translation is ours. For a typical mobile app, Apple's and Google's stores handle much of steps 2 to 6: distribution, signature checks and installation. That does not remove your part of the chain:
- Build and signing (step 1) are still yours. Who can access your upload and signing keys, and could one person push a release alone?
- Anything the app downloads and executes itself, such as over-the-air code bundles, downloadable modules or remotely loaded scripts, is an update channel you run. In our reading, ENISA's controls apply to it in full: signed metadata, verification on the device, no rollback to older vulnerable bundles.
- Separate security fixes from features where you can.
- Minimum supported version. Store auto-update is not universal, so a way to tell users on vulnerable versions to update is your version of "user notification".
- Records (step 7). Release logs, SBOMs per version and roll-out data are the evidence ENISA lists. Keep them.
What we would do this month
- Read the advisory and map its seven steps to your release pipeline, noting which steps the store covers and which you own.
- List every channel through which your app receives code or executable content outside the store, and check each for signing and on-device verification.
- Review who holds signing and upload credentials, and require a second approval for production releases.
- Generate and archive an SBOM for every release build. The free Shipmark GitHub Action can do this in CI.
- Decide your support period and check how long old security updates stay available. Our support period tool works out the dates per app version, and our risk assessment guide shows where update risks belong.
Every security update starts with knowing what is in each app version. Build an SBOM and check it against known vulnerabilities in seconds.
Open the free scannerSources
- ENISA: Technical Advisory on Secure Update Mechanisms, publication page, 4 November 2026.
- ENISA Technical Advisory – Update Mechanisms – v1 (PDF).
- ComplexDiscovery: ENISA's update advisory turns the patch pipeline into an evidence trail, 7 November 2026.
- ENISA: The CRA Single Reporting Platform is launched (application dates).
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex: Article 13(9) and Annex I.
This article summarises an ENISA technical advisory and EU law for practical use. It is not legal advice. Related: CRA vulnerability reporting for app teams · Does the CRA apply to mobile apps?