Certificate pinning is one of those security measures that is genuinely useful and genuinely able to take your app offline if you get it wrong. The idea is simple: your app refuses to trust any server certificate except the specific one you pinned, which blocks an attacker who presents an otherwise valid certificate. The catch is operational, since a certificate rotation without an updated pin can brick every installed copy of your app until users update. Here is what pinning protects against, when it is worth the commitment, and how to do it without locking yourself out.
Short answer
Certificate pinning makes your app trust only a specific server certificate or public key, rather than any certificate a trusted authority issued, which defends against interception by a rogue or compromised certificate authority and by intercepting proxies. Per OWASP's guidance, it is valuable for high-sensitivity apps where you control the backend, but it carries real operational risk: if you rotate certificates without shipping an updated pin, the app cannot connect until users update. So pin the public key rather than the leaf certificate, include backup pins, and only adopt pinning with a rotation plan. It is strong defense-in-depth for the right app, not a default for every app.
What you should know
- Pinning restricts trust: the app accepts only your pinned certificate or key.
- It blocks rogue-CA interception: even a valid attacker certificate is rejected.
- It is an operational commitment: a bad rotation can break the app.
- Pin the public key, not the leaf: and include backup pins.
- It is for sensitive apps: not a universal default.
What is certificate pinning?
It is restricting which certificate your app will accept for a given server. Normally an app trusts any certificate signed by a certificate authority in the device's trust store, so a connection succeeds as long as the certificate chains to a trusted CA. Pinning narrows that: the app stores a known value, ideally the hash of your server's public key, and rejects the connection if the server's certificate does not match, even if it is otherwise valid. That closes a gap, because an attacker who can get a certificate issued by a trusted CA, through a compromised or coerced CA, or a user-installed CA on the device, could otherwise intercept traffic with a valid-looking certificate. Pinning means only your specific key is accepted, so such a certificate is refused.
When does pinning help, and when does it hurt?
It helps against interception and hurts when operations go wrong. The table weighs it.
| Situation | Pinning effect |
|---|---|
| Sensitive app, you control the backend | Helps; blocks rogue-CA and proxy interception |
| Intercepting proxy or compromised CA | Helps; the attacker certificate is rejected |
| Certificate rotated without an updated pin | Hurts; the app cannot connect until users update |
| No backup pin and the key changes | Hurts; risk of bricking installed apps |
| Rooted or jailbroken device | Limited; pinning can be bypassed on a compromised device |
The benefit is real for apps handling sensitive data on a backend you operate, where pinning meaningfully raises the bar against interception. The risk is equally real: pinning ties your app to a specific key, so a rotation that does not account for the pin takes the app offline, which is why it demands a rotation plan and backup pins.
How do you pin without bricking your app?
Pin carefully, and never without a recovery path. Pin the public key, using a Subject Public Key Info hash, rather than the leaf certificate, so renewing the certificate with the same key does not break the pin. Always include at least one backup pin for a key you control but have not deployed yet, so you can rotate to it without an app update. On Android, you can configure pins in the network security config or use a library's certificate pinner; on iOS, you implement server trust evaluation in your URLSession delegate. Plan rotations ahead, deploy a new pin in an app update before the old certificate expires, and monitor so a pin mismatch does not silently cut off users. The discipline is that pinning is a commitment you maintain, not a setting you enable once.
What to watch out for
The first trap is adopting pinning without a rotation plan, which is how teams brick their own apps when a certificate changes. The second is pinning the leaf certificate instead of the public key, so an ordinary renewal breaks the pin. The third is treating pinning as absolute, when it raises the bar but can be bypassed on a rooted or jailbroken device, so it is defense-in-depth, not a guarantee. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA against OWASP MASVS and reports on your network and transport configuration, helping you confirm your pinning and HTTPS posture before you ship. The pinning logic itself you implement and maintain in the app.
What to take away
- Certificate pinning makes your app trust only a specific server key, blocking interception via a rogue or compromised certificate authority.
- It is valuable for sensitive apps on a backend you control, but it is an operational commitment that can break the app if a rotation is mishandled.
- Pin the public key rather than the leaf certificate, include backup pins, and adopt pinning only with a rotation plan.
- It is defense-in-depth, not absolute, and a pre-submission scan such as PTKD.com helps you verify your transport and pinning posture.
