Fundamentals

What Is Certificate Pinning?

Certificate pinning is when a client — typically a mobile app — is hardcoded to only trust one specific certificate (or public key) for a given domain, rather than trusting any certificate signed by any CA in the system trust store. It's a defense against a compromised or rogue CA issuing a fraudulent certificate for your domain that would otherwise be trusted.

The trade-off

Pinning is powerful but brittle. If the pinned certificate is renewed or reissued — which happens routinely, often every 90 days with Let's Encrypt — and the app wasn't updated with the new pin first, the app breaks completely for every user until it's fixed. This has caused real, high-profile outages for major apps.

Where it's actually used

Why pinning is risky for anything using short-lived, frequently renewed certificates

Because Let's Encrypt certificates renew every 90 days, an app pinned to a specific certificate rather than a more stable underlying key or CA would break on every single renewal unless updated in lockstep — this is why pinning implementations typically pin to a public key or intermediate CA rather than the leaf certificate itself, giving some flexibility across routine renewals.

A real-world example of pinning going wrong

Several major apps have experienced widely publicized outages when a pinned certificate was renewed or reissued and the app wasn't updated with the new pin in time — a cautionary pattern that's made many organizations more conservative about adopting pinning without a very deliberate, well-tested update process in place.

How pinning differs from simply checking the certificate is from a trusted CA

Standard TLS validation trusts any certificate signed by any CA in the trust store; pinning goes further by trusting only one specific certificate or key for a given domain, rejecting even a certificate that's otherwise perfectly validly issued by a legitimate CA if it doesn't match the pinned value.

The specific HTTP Public Key Pinning feature browsers eventually removed

Browsers once supported HPKP, letting a website specify pinned keys via an HTTP header for browser-level enforcement — it was deprecated and removed from major browsers specifically because a misconfigured or mismanaged pin could permanently lock out legitimate visitors with no recovery path, a risk judged to outweigh its security benefit for the general web.

Where pinning remains standard practice today despite these risks

Banking apps, payment applications, and other high-security mobile software continue to use certificate or public-key pinning deliberately, accepting the operational risk because the security benefit, protection against a compromised or coerced CA, is judged to outweigh the brittleness for these specific, carefully managed, high-value use cases.

Why this remains a deliberate, narrow tool rather than a general recommendation

Pinning's operational risk means it's best reserved for specific, high-value, carefully managed applications rather than treated as a general hardening step every site should adopt — for most websites, standard certificate validation through the normal trust store already provides adequate protection.

What alternative approaches exist for organizations wanting pinning's benefits without its risks

Certificate Transparency monitoring, covered elsewhere in this category, offers organizations a way to detect unauthorized certificate issuance without the operational fragility pinning introduces — a meaningfully different but complementary approach some organizations prefer as a lower-risk alternative or supplement to pinning.

A closing thought

A quick closing thought: pinning represents a deliberate trade of flexibility for security assurance — understanding when that trade makes sense, and when it doesn't, is more valuable than simply knowing the mechanism exists.