What Is Certificate Pinning?

Certificate pinning is a security technique where an app or client hardcodes which specific TLS certificate, or which public key, it should trust for a given server — instead of trusting any certificate that chains up to a certificate authority the operating system already trusts. It’s a defense against a narrow but serious threat: an attacker who manages to get a validly signed, technically legitimate certificate for a domain they don’t actually control.

The trust model pinning is reacting to

Normal HTTPS trust works through a chain: your browser or OS ships with a list of trusted certificate authorities (CAs), and it trusts any certificate signed by one of them, for any domain, without further checks. This works well in practice, but it means the security of every HTTPS connection you make ultimately rests on every CA in that trusted list behaving correctly — hundreds of organizations worldwide, any one of which being compromised, coerced, or simply making a mistake could result in a fraudulent certificate being issued for a domain it shouldn’t cover. That certificate would still pass a normal TLS handshake check, because it really is validly signed by a trusted CA — it’s just signed for the wrong party.

This isn’t a hypothetical: CA compromises and mis-issuances have happened, and each one meant an attacker could, in principle, present a validly-signed certificate for a domain to intercept traffic that had no reason to distrust it, enabling a man-in-the-middle attack that a normal TLS check wouldn’t catch.

How pinning closes that gap

Certificate pinning narrows trust from “any certificate signed by any trusted CA” down to “this exact certificate, or this exact public key, and nothing else” for a specific host. The app ships with the expected certificate (or a hash of its public key) baked in, and at connection time it checks the server’s presented certificate against that pinned value in addition to the normal chain-of-trust validation. If a connection presents a certificate that passes standard CA validation but doesn’t match the pin, the app rejects the connection anyway — treating a mismatch as evidence of tampering rather than as a routine certificate rotation.

There are two common things to pin: the leaf certificate itself, or the public key it contains (or that of an intermediate CA in the chain). Pinning the public key rather than the full certificate is more common in practice, because it survives certificate renewal — a server can rotate to a new certificate using the same key pair without breaking pinned clients, whereas pinning the exact certificate breaks the moment that certificate is renewed, even legitimately.

Where pinning is used

Pinning is mostly a mobile-app and native-client technique rather than a browser one. A native app fully controls its own network stack and ships updates on its own schedule, so it can afford to hardcode a pin and trust it until the next app update. Browsers generally moved away from supporting site-defined pinning delivered over HTTP headers (a mechanism called HPKP that has since been deprecated), largely because misconfigured pins had a nasty failure mode: get the pin wrong, or fail to update it before rotating certificates, and you lock every visitor out of your own site with no way to recover short of waiting out the pin’s expiry.

Applications handling especially sensitive traffic — banking apps, password managers, and similar — are the most common adopters, since the cost of an intercepted connection is high enough to justify the operational overhead of managing pins correctly across certificate renewals.

The operational cost

Pinning’s core tradeoff is availability against security. Certificates expire and need to be renewed, sometimes on short notice — a CA gets compromised, a private key leaks, an algorithm gets deprecated. If a client has pinned the old certificate or key and the app can’t be updated fast enough, every pinned client loses connectivity to a server presenting a perfectly legitimate new certificate. Because of this, teams that pin usually pin to a set of keys rather than a single one — for example, both the current key and the next one already generated and waiting to be rotated in — so a planned rotation doesn’t require a synchronized app update to avoid an outage.

Pinning vs other TLS protections

	What it protects against	Cost
Standard CA trust	Unsigned or self-signed certificates	None — the default
HSTS	Downgrade to plain HTTP	Low, browser-supported
Certificate pinning	A validly-signed cert for the wrong party	High — rotation risk, mostly native apps only

HSTS and certificate pinning are often mentioned together but solve different problems: HSTS stops a connection from being silently downgraded to unencrypted HTTP, while pinning stops a connection from trusting the wrong (but validly signed) certificate over an already-encrypted channel. They’re complementary, not substitutes for each other.

An alternative worth knowing: certificate transparency

Rather than pinning at the client, a complementary industry-wide approach is Certificate Transparency — public, append-only logs that record every certificate a participating CA issues, so mis-issued certificates for a domain become publicly auditable shortly after they’re created. This doesn’t prevent a fraudulent certificate from being issued the way pinning does, but it makes issuance visible, which is often enough for a domain owner to catch and revoke a rogue certificate quickly. Many organizations rely on monitoring these logs as a lower-overhead alternative to pinning, particularly for browser-facing traffic where pinning itself isn’t practical.

The takeaway

Certificate pinning trades away some of TLS’s flexibility for protection against a specific, serious threat: a validly signed certificate issued for a domain by a CA the attacker shouldn’t have been able to fool. It’s most practical in native apps that control their own update cadence and can afford the operational discipline of managing pin rotation carefully — get that discipline wrong, and pinning turns from a security feature into a self-inflicted outage. For anything client-controlled and security-critical, it remains one of the few defenses against a compromised or coerced certificate authority.