Certificate Pinning: What It Is and When to Use It

Certificate pinning is one of those security techniques that sounds simple but can bite you hard if you get it wrong. It can make your mobile app nearly immune to man-in-the-middle attacks, yet a misstep can leave users locked out. Let’s break down what it is, how it works, and the real trade-offs you’ll face when deciding whether to use it.

What exactly is certificate pinning?

Certificate pinning means you embed a copy of a server’s certificate or its public key directly into your mobile app. When your app connects to that server, it compares the server’s presented certificate against the pinned copy. If they don’t match, the connection is rejected — no matter what the device’s trust store says.

This is stricter than standard TLS validation. Normally, your app trusts any certificate signed by a trusted CA. With pinning, you only trust the one you pinned. This stops attackers who have compromised a CA or who are using a forged certificate.

How does it work in practice?

You have two main options: pin the entire certificate or pin just its public key.

Certificate pinning vs public key pinning

Pinning the certificate means you bind to a specific certificate, including its expiration date. When the certificate renews, your app breaks unless you ship an update. Pinning the public key is more flexible because the public key can remain the same across certificate renewals if you reuse the key pair.

Here is a simple comparison:

Approach	What you pin	Effect of certificate renewal	Update needed?
Certificate pinning	Full certificate (including expiry)	Breaks until app updated	Yes, often
Public key pinning	Public key of the certificate	Works if key pair unchanged	Only if key pair changes

Public key pinning is usually the safer choice because it gives you a longer runway between rotations.

When should you use certificate pinning?

You should use pinning only where the risk of interception is high and the cost of failure is acceptable. Here are the scenarios where it makes sense:

• Critical APIs: Your app’s login, payment, or sensitive data endpoints benefit from the extra protection.
• Fixed server set: Your app talks to servers you control and rarely change.
• High-value targets: Financial or healthcare apps where a MITM attack could cause serious harm.
• Managed certificate lifecycle: You have a process to rotate keys and ship app updates or push configuration changes.

When should you avoid it?

Pinning is not a silver bullet. Avoid it when:

• Your server certificates change frequently: Every rotation forces an app update.
• You use third-party APIs: You cannot control their certificate lifecycle.
• Your app updates are slow: Users on old versions will break until they upgrade.
• You lack a fallback mechanism: If no backup pin exists, a single expired cert bricks your app.

How to implement certificate pinning correctly

Here is a step-by-step approach to implement pinning without shooting yourself in the foot:

1. Pin the public key, not the full certificate. Use the SHA-256 hash of the public key to avoid expiration issues.
2. Always include backup pins. Pin at least two public keys — one for your current certificate and one for the next one you plan to rotate to.
3. Add a grace period. Before enforcing pinning, log mismatches so you can detect problems before they break production traffic.
4. Provide an update path. If your app has a configuration update mechanism (like remote config), use it to push new pins without requiring a store update.
5. Test thoroughly. Use a staging environment where you intentionally break the pin to verify that your app handles the failure gracefully.

Certificate pinning in Flutter and React Native

Both frameworks support pinning through platform-specific code or libraries. In Flutter, you can use the http package with a custom SecurityContext or a plugin like flutter_secure_socket. In React Native, libraries like react-native-ssl-pinning let you pin certificates declaratively. The implementation details vary, but the principles are the same — pin the key, include backups, and handle errors.

Keep in mind that pinning adds complexity to your build process. You also will want to integrate pinning checks into your CI/CD pipeline. Our Mobile App Security Audit Checklist for CI/CD can help you include pinning validation as part of your automated tests.

Trade-offs and alternatives

Pinning is not the only way to protect against MITM attacks. You could use certificate transparency, HPKP (HTTP Public Key Pinning), or rely on strong TLS with extended validation certificates. Each has pros and cons. HPKP, for example, was deprecated by browsers because it was too easy to lock users out. Pinning at the app level gives you more control but requires careful lifecycle management.

If you are securing API communication, consider combining pinning with other layers like OAuth tokens and short-lived JWTs. Our guide on How to Secure Mobile App APIs Against Common Threats covers complementary strategies.

For WebViews, pinning works but is trickier because WebViews often handle TLS implicitly. The article Secure WebViews in Flutter and React Native Apps has specific guidance on that case.

What about backup pins and rotation?

Certificate rotation is inevitable. You will get a new certificate every year or two, or sooner if a key is compromised. Plan for it. The safest approach is to pin two keys: the current one and a future one. When you rotate, you replace the old backup with a new one. This way, your app never has a single point of failure.

Some teams go further and implement a mechanism to fetch new pins from a trusted endpoint on startup. This is essentially a dynamic pinning scheme. It adds complexity but removes the need for store updates. Evaluate whether that trade-off is worth it for your use case.

The bottom line

Certificate pinning is a powerful tool, but it is not a default setting. Use it sparingly, pin public keys instead of certificates, and always have a backup plan. If you control the server and can manage updates, it adds a strong layer of defense. If you rely on third-party services or cannot push updates quickly, think twice before pinning.

Frequently asked questions

What is the difference between SSL pinning and certificate pinning?

SSL pinning is an older term that usually means the same as certificate pinning. Both refer to binding a specific certificate or public key to a host. Modern usage prefers ‘certificate pinning’ or ‘public key pinning’ to be precise about what is pinned.

Does certificate pinning prevent all man-in-the-middle attacks?

It prevents most MITM attacks where the attacker uses a forged certificate. However, it cannot stop attacks that occur before the TLS connection, like DNS spoofing with a malicious server that also has the pinned certificate. Pinning is one layer, not a complete solution.

What happens if the pinned certificate expires?

The app will reject connections with the expired certificate, even if the server presents a valid new one. Users will experience errors until you ship an app update with the new pin. This is why public key pinning and backup pins are recommended.

Can I use certificate pinning with third-party APIs?

It is risky because you do not control the third party’s certificate lifecycle. If they rotate their certificate, your app breaks until you update the pin. Only consider it if you have a direct agreement with the provider about their rotation schedule.

Should I pin the leaf certificate or the intermediate CA?

Pinning the leaf certificate or its public key is most specific. Pinning an intermediate CA is simpler but trusts any leaf issued by that CA. The best practice is to pin the leaf certificate’s public key and include a backup pin for the next planned key.