Mobile App Certificate Pinning: Why It Bites You Years Later
Getting a tattoo at 19 is easy. The shop is friendly, the design seems perfect, the friend who's with you also got one, and the whole thing takes an afternoon. The tattoo looks great that night, looks great the next year, and for several years after that, you barely think about it.
Then, in your thirties, the design that seemed perfect at 19 starts to feel less perfect. The font choice is dated. The placement looked better when you were thinner. The Mandarin character you chose turns out to mean something slightly different from what the tattoo artist promised. You investigate removal. The removal takes multiple sessions, costs significantly more than the original tattoo, and leaves a faded outline regardless. The thing you did at 19, for entirely reasonable reasons at the time, persists into your life on a much longer timeline than you imagined.
Certificate pinning in mobile apps has exactly this shape.
A team makes a decision: pin a specific cert (or a specific public key) in the mobile app, so that even if the user's network is compromised, the app will refuse to talk to anything not signed by the pinned cert. The decision is made for good security reasons. It works. Customers install the app. The app talks to the server using the pinned identity. Years pass.
Then the cert needs to rotate - for renewal, for key rotation, for migration to a different CA. The new cert isn't the one pinned in the app. Old app versions still installed on customer devices stop working. Customers complain. The team scrambles to push an app update. Some customers haven't enabled auto-update; they're stuck on a broken version until they manually update. The decision to pin, made years ago for entirely reasonable reasons, is now causing operational pain.
Here's how pinning actually works, why it bites years later, what to do if you're already in the trap, and how to think about pinning if you haven't deployed it yet.
What pinning is and why it exists
Certificate pinning is a security technique where the client (typically a mobile app) doesn't just trust any cert from a trusted CA - it specifically trusts only a particular cert, or a particular public key, or a particular CA.
Why it exists: in TLS, the client trusts any cert signed by any CA in its trust store. If an attacker can get a malicious cert from a compromised or coerced CA, the app would trust it. Pinning narrows the trust - even if a CA goes rogue, the app refuses certs that don't match the pin.
For some threat models, this is genuinely valuable. State-level adversaries who can compromise CAs are a real concern for some apps. Pinning protects against this.
The implementation:
- Cert pinning. Pin a specific certificate. Rotation means updating the pin in the app. Public key pinning. Pin the public key (which survives cert renewal as long as you reuse the key). Rotation means updating the pin only when the key changes. CA pinning. Pin a specific CA. New certs from the same CA work without app updates. Rotation across CAs requires app updates.
Each variant has trade-offs. Public key pinning is the most operationally friendly; cert pinning is the strictest but most fragile.
Why it bites years later
Mobile apps live on customer devices for years after release. Old app versions don't disappear when you ship a new one. The long tail of installed apps is the source of the pain.
Specific failure modes:
Cert rotation that doesn't match the pin. You renew your cert. The new cert has a different signature than what's pinned. Old app versions can't authenticate against the new cert. The app stops working for users on old versions.
CA migration. You switch from one CA to another. Old app versions, pinning the old CA, refuse certs from the new one.
Compromised key emergency rotation. Your private key is compromised. You need to rotate immediately. Old app versions, pinning the old cert or key, will refuse the new one. Your security incident becomes an availability incident.
Backup pin expiry. Good pinning includes backup pins (multiple acceptable identities, in case one needs to rotate). Backup pins also have expiry. If the team that set up the pinning is gone, the backup pin's expiry might surprise you.
Apps that don't auto-update. Some users disable auto-update. Some platforms (older Android, certain enterprise app deployments) don't auto-update at all. The old app versions persist on devices indefinitely.
The pattern: pinning protects against rare adversarial events at the cost of frequent operational pain during normal cert lifecycle. Whether the trade-off makes sense depends on your specific threat model.
If you're already in the trap
If your app already has pinning and you're hitting cert rotation problems, three things help.
One: identify the affected app versions. Which versions have the old pin? How many users are on each? The blast radius is the user count on un-updatable versions.
Two: implement a transition period with multiple acceptable pins. Ship an app update that accepts both the old cert and the new cert. Wait for the user population to migrate to the updated app (typically 30-60 days for most users; longer for slow updaters). Then ship another update that drops the old pin.
Three: have a rotation strategy before you need it. If you're going to keep pinning, document and test the rotation process before an emergency rotation is needed. The rotation involves at least one app store release plus a transition window.
If you're deciding whether to pin
Three questions worth asking before adding pinning.
One: what threat is this addressing? "CAs might be compromised by a state actor and issue malicious certs" is a specific threat. "We want extra security" is not. Be honest about what you're protecting against.
Two: who's affected if pinning causes an outage? Pinning failures affect every customer on the affected app version. The cost of a pinning-induced outage at scale is often higher than the cost of the threat pinning was meant to address.
Three: do you have operational discipline for rotation? Pinning requires regular app updates aligned with cert rotation. If your release process is slow, your update adoption is poor, or your team turnover means the pinning strategy gets lost - pinning is high-risk.
For some apps (high-value financial, government, certain healthcare), the answers favour pinning. For most apps, the answers favour not pinning, or pinning at the CA level (which is more flexible than cert or key pinning).
One small ask
Mobile cert pinning is a powerful security control with operational costs that surface years after the decision. The right call depends on your specific threat model, not on a general "more security is better" reasoning. If you have pinning in place, monitor the pinned cert lifecycle as carefully as any production cert - the failure mode is uniquely customer-visible. TLS Radar tracks the certs your app expects to see; mobile-specific pinning monitoring is its own discipline. The 30-day free trial covers three domains.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.