It depends on the platform. On Windows, an unstamped package stops installing after expiry but an installed app keeps running. On Apple, store apps are unaffected but new uploads fail, and in-house apps stop. On Android, an expired key blocks smooth updates. A timestamp fixes the Windows case.
The comparison
| Platform | What breaks on expiry | What protects you |
|---|---|---|
| Windows MSIX | New installs of an untimestamped package fail. Installed apps keep running. | A timestamp when signing |
| PowerShell scripts | A signature is valid until expiry, or as long as a timestamp can verify signing time | A timestamp |
| Apple App Store distribution | Existing store apps unaffected. New uploads signed with it fail. | Renewing before expiry |
| Apple in-house distribution | Users can no longer run apps signed with it | Renewing before expiry |
| Android | Users can no longer seamlessly upgrade to new versions | A long validity period, 25 years or more |
Each row comes from the vendor pages listed under sources.
Why they differ
The platforms answer different questions at different times. Windows checks a package's signature when it installs, so time of signing matters and a timestamp can prove it. Apple checks distribution identity at upload for the store, but on device for in-house apps, so the break shows up in different places. Android treats the key as the identity of the app across updates, so expiry affects every future update, not a single install.
Definitions
A timestamp is a signed record of when a signature was made. Validity is the start and end date of a certificate or key. Renewal means getting a new certificate before the old one expires, which on some platforms means a new identity and on others the same one.
A single expiry inventory
Make one list for the whole team. For every signing certificate or key, record:
- Platform and purpose, such as Windows installer or iOS store builds.
- Owner, a named person and a backup.
- Where the private key lives.
- Expiry date and the date you will start renewal.
- What breaks if it lapses, taken from the table above.
- Where the renewed key must be updated, such as CI secrets and profiles.
Review the list monthly, and again before each major release.
Renewal order of operations
- Get the new certificate or key issued.
- Update CI secrets in a test environment and build.
- Verify the signature and timestamp on the test build.
- Switch the release job to the new identity.
- Keep the old identity available until the last build using it is out of support.
- Record the change.
A related renewal plan for the shorter Windows validity period is at /resources/blog/code-signing-certificate-460-day-validity-renewal-plan.
A note on revocation
Expiry is a planned event. Revocation after a key theft is not, and the response is different. For a theft, follow the incident steps in /resources/blog/stolen-code-signing-certificate-response-runbook.
Where Safeguard fits
Expiry planning keeps releases flowing. Safeguard checks what is inside them with dependency scanning and SBOMs, and offers a free scan at gold.safeguard.sh/scan.
Quick check
Which platform keeps installed apps running after expiry?
Microsoft says an installed MSIX app keeps running. Apple says existing App Store apps are unaffected, though in-house apps stop.
What single step helps Windows signatures survive expiry?
Timestamping at signing time. Microsoft says a timestamped package still installs after the certificate expires.
Sources
- Microsoft Learn: Sign an MSIX package
- Microsoft Learn: about_Signing
- Apple Developer: Certificates
- Android Developers: Sign your app
Last reviewed: 19 October 2026.
