Android certificate pinning: expiry dates and backup pins

Pinning limits which keys your app trusts for your own servers. On Android you declare SHA-256 hashes of public keys in a pin set. Always include a backup pin, because a key change without one needs an app update to restore connectivity. Pins can carry an expiration date, which prevents lockouts but also lets pinning lapse.

What a pin is

Android's documentation says pins are SHA-256 digests of a certificate's SubjectPublicKeyInfo, base64-encoded. A chain is valid only if it contains at least one pinned key. Only SHA-256 is supported. MASVS-NETWORK-2 describes the goal: instead of trusting all the default root CAs of the device, trust only very specific ones.

The two settings that bite

Backup pins. The docs say to always include a backup pin. Without one, rotating your key or changing CA means connections fail until users update the app. Keep a backup key generated and stored offline, and pin its hash from day one.

Expiration. A pin set can have an expiration date in yyyy-MM-dd format. After that date, pinning is not performed. The docs explain this keeps apps that never update from breaking, but warn that an expiration can let attackers bypass your pins. If you omit it, pins never expire.

So there are two failure modes. No expiry and no backup can brick the app for a user who has not updated. An expiry that is too soon, or that nobody tracks, silently turns pinning off.

Should you pin at all?

The OWASP Mobile Application Security Cheat Sheet says to consider pinning, "weighing its tradeoffs". MASVS-NETWORK-2 applies to endpoints under your control, which is the clean case: you own the server, so you control the key rotation.

A rough decision guide:

1. You control the backend and ship updates reliably: pinning is reasonable, with backup pins.
2. You depend on many third-party endpoints: do not pin those. You cannot control their rotation.
3. Your users run old app versions for long periods: weigh the lockout risk heavily, and consider forced updates.
4. Low risk data: standard TLS with system CAs may be enough.

Pinning is a defense against a certificate authority being misused or a bad CA being trusted. It does not stop data theft from the device itself.

Operational routine

• Pin the public key rather than the leaf certificate, so routine certificate renewals do not break the pin.
• Keep a calendar entry for pin and expiry dates.
• Test the rotation path before you need it: ship a build, rotate the key in staging, confirm the backup pin works.
• Keep a way to push an updated app, and ideally a forced update path (MASVS-CODE-2 asks for a mechanism to enforce app updates).
• Make sure debug builds can use a proxy without weakening release builds. In the config, debug-overrides only applies to debuggable apps.

Common mistakes

• Pinning to the single production key with no spare.
• Setting an expiration to a convenient date and forgetting it.
• Pinning third-party domains.
• Assuming pinning protects against a user who deliberately installs a proxy on their own rooted phone.

See also the companion post on network security config defaults.

Quick check

Sources

• Android developers: Network security configuration
• MASVS-NETWORK-2
• MASVS-CODE-2
• OWASP Mobile Application Security Cheat Sheet

Last reviewed: 19 October 2026.