What is certificate pinning and should you use it?

Certificate pinning means an app accepts only a specific certificate or public key for a host, instead of trusting any certificate a trusted authority has signed. It blocks some man-in-the-middle attacks, but a bad pin update can lock out every user, so use it only when you control both ends.

What problem does pinning try to solve?

Normal TLS trusts a long list of certificate authorities. If an attacker gets a rogue certificate for your domain from one of them, or adds their own authority to a device's trust store, the client will accept the fake. OWASP's Pinning Cheat Sheet names exactly these two cases. Pinning shrinks the set of acceptable answers: the host is associated with its expected certificate or public key, and anything else is refused.

If more than one value is acceptable, the app holds a pinset and the presented credential must match one element.

What do you pin: the certificate or the key?

Android's network security configuration documentation shows the common approach: pin the hash of the public key (the SubjectPublicKeyInfo of the X.509 certificate). A chain is valid only if it contains at least one pinned key. Pinning the key instead of the whole certificate means you can renew the certificate without changing the pin, as long as you reuse the key pair.

Android's documentation also says to always include a backup key. If you are forced to change keys or certificate authorities, a backup pin keeps connectivity alive. Without it, you have to ship an app update to restore connections.

Is pinning a good idea?

OWASP is blunt. Its cheat sheet says the answer to "Should I pin?" is probably never, and that the risk of outages almost always outweighs the security gain, given advances in the certificate ecosystem. It lists cases where you should not pin:

• You do not control both client and server.
• You cannot update the pinset securely.
• Updating the pinset is disruptive, such as needing a full redeployment.
• You cannot predict the next certificate key pair before it goes into service.
• It is not a native mobile application.

One stated exception is environments where you control redeployment, such as forced updates inside a company.

What about the HTTP header version?

RFC 7469 defined an HTTP header for public key pinning on the web. It is a Standards Track document, but browser support for the header has changed since publication. Check current browser documentation before you build anything on it. For browsers, certificate transparency and short lived certificates are the usual alternatives to review.

What does an outage look like? A constructed example

A mobile team pins the leaf certificate of its API. Eleven months later the certificate renews automatically, with a new key pair, because the hosting platform rotates keys. Nobody told the mobile team. Every installed copy of the old app now fails every request. The fix needs a new release, store review and users updating. A backup pin for a key held offline, or pinning an intermediate you control, would have avoided it.

How to check or apply this

1. Decide whether you control both client and server and can force updates. If not, do not pin.
2. Pin the public key hash, not the leaf certificate, and include at least one backup key.
3. Document who owns key rotation and require the mobile team to sign off on it.
4. Test the failure path: what does the user see when a pin fails, and can you ship a fix?
5. Avoid pin expiry shortcuts without thought. Android notes that setting an expiry may let attackers bypass pinning once it lapses.
6. Plan for corporate interception proxies if your users are inside managed networks.

Quick check

Sources

• OWASP Pinning Cheat Sheet
• Android Developers, Network security configuration
• RFC 7469, Public Key Pinning Extension for HTTP

Last reviewed: 18 October 2026.