Certificate Pinning: Why It Fails and What to Pair It With

Certificate pinning is one of the few mobile security controls that developers implement willingly, because it is well documented, it lives in code they own, and it addresses an attack everyone understands.

It is also routinely bypassed, and the reason is not a weakness in certificate pinning itself. It is a mistaken assumption about where the control is enforced.

What Certificate Pinning Does

Ordinary TLS validation trusts any certificate signed by a certificate authority the device trusts, and a device trusts a great many. If an attacker can get a certificate the device accepts, they can position themselves between your app and your server and read the traffic.

Certificate pinning narrows that trust. The app is told to accept only a specific certificate or public key, so a technically valid certificate from any other issuer is rejected. It is an effective answer to interception, and it is worth doing.

Why Certificate Pinning Fails

The bypass does not attack the cryptography. It attacks the check.

Hooking the validation function. On a rooted or jailbroken device, a hooking framework intercepts the method that performs pin comparison and forces it to return success. The pin is still in the app. It is simply never consulted.

Patching the binary. The app is decompiled, the validation logic is removed or inverted, and the app is rebuilt and re-signed. This produces a permanently unpinned build that can be distributed to others.

Replacing the network layer. Rather than defeating your check, the attacker substitutes the library that performs it.

All three require the same precondition: the ability to run code inside your app’s process, or to modify the app before it runs. That is the actual vulnerability, and certificate pinning cannot address it because pinning is one of the things being modified.

Two Operational Problems With Certificate Pinning

Before the security discussion, two practical failures worth planning for.

Certificate rotation. If you pin a leaf certificate and it is renewed, every installed copy of your app stops connecting until users update. Teams that have been burned by this once often disable pinning rather than fix it. Pinning the intermediate or the public key, and shipping a backup pin, avoids the outage.

Silent breakage. Pinning failures often look like generic network errors to users and to your support team. Without telemetry distinguishing a pin failure from a connectivity failure, you cannot tell an expiry problem from an active interception attempt.

What to Pair Certificate Pinning With

Pinning becomes strong when the conditions required to bypass it are themselves detected.

That last one is the general principle. A client-side check is a signal to the server, not a decision the server should rely on. If removing certificate pinning on the device changes what your backend will accept, the security was in the wrong place.

A Reasonable Position

Implement pinning. Pin the public key rather than the leaf certificate, ship a backup pin, and instrument failures so you can tell expiry from attack.

Then treat it as one layer rather than the answer. On an unmodified device, pinning stops interception cleanly. On a compromised device, what protects the connection is the detection of the tooling used to break the pin, not the pin itself.

Where SecIron Fits

Conclusion

Certificate pinning fails for a reason worth generalising: it is a decision made by code running on hardware you do not own. That is true of every client-side control, which is why the question is never whether a single control is strong but whether the conditions needed to defeat it are visible to you.

Pin your connections. Then make sure your app can tell when someone is standing next to the pin with a hooking framework.

Ready to launch a secure app?

Bring us your app and we will attempt the pinning bypass ourselves, then show you what a protected build does differently.

Contact us