Hosted Mender experienced a major incident on September 15, 2026, lasting 47m. The incident has been resolved; the full update timeline is below.
Update timeline
- investigating Sep 15, 2026, 07:30 PM UTC
We are currently investigating this issue which has been reported by customers.
- identified Sep 15, 2026, 07:44 PM UTC
The issue has been identified and a fix is being implemented.
- monitoring Sep 15, 2026, 07:53 PM UTC
A fix has been implemented and we're monitoring the results.
- resolved Sep 15, 2026, 08:18 PM UTC
This incident has been resolved.
- postmortem Sep 16, 2026, 08:35 AM UTC
## Executive Summary We renew the signing key for our apt repositories every two years. The renewal on 2026-09-15 produced a key that Debian 13 \(trixie\) rejects. For about half a day, anyone installing Mender packages on Debian 13 got "`the repository is not signed`" and could not install anything. Existing devices were unaffected. Debian 12 and older were unaffected. No package was altered and nothing was exposed; this was a verification failure, not a security breach. ## What happened A signing key carries a signature saying "`this key is valid`". Renewing the key is supposed to extend that statement. The tool we use replaces it instead, so the renewed key effectively said "`valid as of today`" with no record of having been valid before. Debian 13 shipped a stricter signature checker. It asks whether the key was valid _at the moment the repository was signed_. Our repositories were last signed before the renewal, so the answer was no and it refused them. Debian 12 and older do not ask that question, which is why everything looked fine to us. ## Impact * Debian 13 users could not install or update Mender packages. ## Resolution We rebuilt the key so it carries both its old and its new validity statements. It is the same key with the same fingerprint, so nothing changed for existing devices, and it now satisfies both the old and the new checkers. Verified on Debian 12 and Debian 13, against every repository. **If you applied a workaround, re-fetch the key.** Some users unblocked themselves by fetching the key from `https://downloads.mender.io/repos/device-components/gpg`. During the incident that URL served the old key, which expires on **2026-10-01**, so those installs will start failing again in October. That URL now serves the corrected key, so fetch it once more: ``` curl -fsSL https://downloads.mender.io/repos/device-components/gpg \ | sudo gpg --dearmor -o /usr/share/keyrings/mender.gpg` ``` The expiry should now read 2028-09-14: ``` gpg --show-keys /usr/share/keyrings/mender.gpg ``` Adjust the output path if you installed the key somewhere else; the official docs place it at `/etc/apt/trusted.gpg.d/mender.asc`. No change to your `sources.list` is needed, and devices already running Mender need no action. ## Why we did not catch it 1. We have an internal renewal and verification runbook which doesn't include Debian 13, so we didn't catch it. 2. The repositories kept serving. Only clients on a newer distribution saw a problem, and we had no monitoring for that. ## Actions to avoid this issue the next time * We updated the internal runbook to also include Debian 13 and a note to check for future distributions. * We added a verification pipeline to the renewal process. ## Apology We are sorry. This was our mistake, and it blocked people from installing our software on a current, supported version of Debian. We have updated our internal renewal process to test against current Debian releases, and added a verification pipeline so this is checked automatically the next time. We did not find this ourselves. A customer did, and reported it. We are grateful for that report, which was precise enough that we could reproduce the problem within minutes, but catching this should not have been their job.