If you know about how TLS works, you know the system leans heavily on Certificate Authorities (CAs) to vouch for a server’s identity. That trust model works well most of the time, but it has a weak point: any CA in the hundreds trusted by your browser or operating system can issue a valid certificate for any domain. If even one of those CAs is compromised, tricked, or coerced, an attacker can obtain a certificate that looks completely legitimate for a site they don’t own. Certificate pinning is a defense against exactly that scenario.

The problem pinning solves

Normal TLS validation asks one question: “Is this certificate signed by a CA my system trusts?” It doesn’t ask “Is this the specific certificate this site normally uses?” That distinction matters. History has already shown the risk isn’t theoretical — several CAs have mis-issued or been tricked into issuing certificates for domains they had no business certifying, and in at least one well-known 2011 case, a compromised CA was used to issue certificates later used for real-world surveillance of users in another country.

Pinning closes this gap by having a client remember (or “pin”) the specific certificate, or specific public key, that a legitimate server presents. On future connections, the client checks not just “is this signed by a trusted CA” but “does this match what I expect from this exact server.” If a different, otherwise-valid certificate shows up, the connection is rejected — even though a browser without pinning would accept it without complaint.

What actually gets pinned

There are two common approaches:

Pinning the certificate itself. The client stores a hash of the full certificate and compares it on every connection. This is simple, but brittle: when the certificate is renewed (which happens regularly, often annually or even every 90 days with providers like Let’s Encrypt), the pin breaks and needs updating.

Pinning the public key. This is the more common and more practical approach. Instead of hashing the whole certificate, you hash the Subject Public Key Info (SPKI) — essentially just the public key. This survives certificate renewal as long as the underlying key pair doesn’t change, and it lets you generate a new certificate from the same key without breaking anything on the client side.

Most modern implementations pin the public key rather than the full certificate, precisely because it decouples “which CA signed this” and “when does this certificate expire” from the actual security check.

Where pinning lives today

It’s worth being clear about where this technique is actually used, because its history is a bit of a cautionary tale.

HTTP Public Key Pinning (HPKP), a mechanism that let a website tell browsers which keys to pin via an HTTP header, was standardized and briefly deployed in the mid-2010s. It was removed from major browsers by 2018. The reason: it turned out to be a liability. If a site misconfigured its pins, or an attacker managed to get a malicious pin set (via a compromised admin account, for instance), visitors could be locked out of the site entirely, sometimes permanently, with no way to recover short of the pin’s expiration. The mechanism that was supposed to prevent hijacking became, in the wrong hands, a way to hold a domain hostage. Browser vendors decided the operational risk outweighed the security benefit and dropped support in favor of newer approaches.

Mobile app pinning, on the other hand, is alive and well, and it’s where pinning genuinely earns its keep today. If you control both the client (your iOS or Android app) and the server it talks to, you can hardcode the expected public key (or a backup key) directly into the app binary. Unlike a website visited by arbitrary browsers, you fully control the update cycle, so if a pin needs to change, you ship an app update. This significantly reduces the “lock yourself out” risk that killed HPKP, because you’re not relying on a dynamic, remotely-set header that any attacker with server access could tamper with.

Certificate Transparency (CT), rather than pinning, has become the mainstream tool for the browser-facing version of this problem. CT requires certificates to be logged in public, append-only logs, so mis-issued certificates become detectable — anyone can monitor the logs for certificates issued for their domain that they didn’t request. It’s a detection-and-accountability mechanism rather than a hard block, which turned out to be a better fit for the open, decentralized nature of the web.

Practical guidance if you’re implementing pinning

If you’re building a mobile app and want to add pinning:

• Pin the SPKI hash, not the full certificate, so routine renewals don’t break your app.
• Always include a backup pin for a second key pair you control but haven’t deployed yet. If your primary key is ever compromised or you need to rotate for any reason, you can switch to the backup without needing to push an emergency app update to avoid locking users out.
• Set a reasonable pin lifetime and have a rotation plan. Pins that are pinned “forever” with no path to update are how sites get bricked.
• Test failure behavior deliberately. Decide what the app does when a pin mismatch occurs — hard failure, or a soft warning with fallback — and make sure that decision is intentional, not accidental.
• Consider whether you need it at all. For most consumer web traffic, standard CA validation plus Certificate Transparency monitoring is a reasonable trust model. Pinning adds real operational risk in exchange for protection against a fairly narrow threat (a legitimate-looking but fraudulent certificate for your exact domain), so it’s most justified in high-value, tightly-controlled environments: banking apps, government or enterprise clients, or anywhere the cost of a mis-issued certificate is severe and you have the operational maturity to manage pin rotation safely.

How MIC Solutions can help..

Certificate pinning is a “trust, but verify more specifically” mechanism layered on top of the standard CA-based TLS model. It was tried at the web-header level and largely retired because the failure mode was too punishing for the open web. It remains a solid, targeted tool in mobile apps and other environments where you control both ends of the connection and can manage the operational overhead responsibly. The general lesson underneath it applies broadly to security engineering: a control that prevents impersonation is only as good as its worst-case failure mode, and if that failure mode is “the legitimate user gets locked out with no recovery path,” the control needs careful guardrails — or it needs to be rethought entirely.

If you are considering using Certificate Pinning, or would like MIC Solution to assess whether your organisation should use, we would happy to help.