Yes, but only if installed copies can still verify the update that carries the new key. If an app trusts one public key baked into the build, the update that changes the key must still be signed in a way the old build accepts. Plan the rotation before you need it.
Why rotation is hard for desktop apps
A desktop app holds its trust anchor locally. For a Sparkle app that is the public key in Info.plist. If you lose the private key, or it leaks, you have a problem: the installed base trusts a key you can no longer use safely, and the only way to move them is through an update the old key must approve or another channel they already trust.
What Sparkle says
The Sparkle documentation gives a concrete rule for apps that use both Developer ID code signing and an EdDSA key. You can rotate either the Apple certificate or the EdDSA key in one update, but not both. The reasoning is simple: the update needs at least one anchor the installed app already trusts.
It also notes that with SUVerifyUpdateBeforeExtraction, changing the EdDSA key requires the archive to be a Developer ID signed dmg. And it says to keep private keys safe and backed up, with the -x and -f options for export and import.
What TUF contributes
The Update Framework describes key compromise as one of the attacks update systems face: an attacker steals a signing key and signs malicious files that then pass verification. Its stated goal is to minimize the impact of key compromises. Its metadata includes trusted signing keys, hashes, signatures, version numbers and expiration dates, which is how a client can learn about new keys from signed metadata instead of being stuck with one forever.
A rotation plan you can write down
- Keep two independent anchors if you can, such as an Apple certificate and an update key.
- Store the private keys on a release machine you control, not on the download server.
- Back up each key to a second secure location and test a restore.
- Write the rotation steps now: which anchor changes first, which release carries it, how long you wait before changing the second.
- Ship the first rotation on a calm day as a rehearsal.
Try it yourself
Rotation planning is a continuous task, not a one time event. Open the monitoring demo and look at how ongoing checks surface change over time, then think about how you would watch for an unexpected key or certificate change in your own releases.
Click through it at your own pace, or open it full screen.
Quick check
What if the private key is stolen, not just lost?
Treat it as an incident. Anyone with the key can sign updates that installed copies accept, so you need a path to move users to a new anchor. This is the case the multi anchor plan above is for.
Is a backup of the key enough?
A backup helps with loss, not theft. Test the restore, and limit who can read it.
Safeguard's compliance and evidence automation can keep a record of release controls such as who holds keys and when they were last checked. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
