Certificate Pinning: When to Use It, When to Kill It

Certificate pinning narrows trust from “any CA in the store” to specific certs, keys, or issuers. Used well, it hardens high-risk clients; used badly, it causes self-inflicted outages. This page explains how pinning variants behave, why browser HPKP was abandoned, where pinning remains defensible, and which modern controls often replace it.

Certificate Pinning: When to Use It, When to Kill It

TL;DR: Pinning blocks rogue CA issuance but ties availability to pin updates—HPKP proved that without a safe rotation story, pinning becomes a denial-of-service risk; use it only where you control the client and can update pins reliably, otherwise prefer CT monitoring, CAA, and solid lifecycle automation.

Overview

For executives: Pinning trades a class of security incidents (fraudulent public certs) for a class of availability incidents (every client rejects until updated). If you cannot answer how fast 100% of clients pick up new pins, pinning can cost more than it saves.

For security leaders: The threat—any trusted CA can technically issue for any name—remains real. Pinning is a prevention control at the client; Certificate Transparency and monitoring are detection controls. Most browser-facing properties rely on the latter because pinning untrusted user devices does not scale.

For engineers: Leaf pins break on every cert rotation; SPKI pins survive renewal only while the key stays the same; CA pins spare leaf rotation but bind you to issuer choice and complicate multi-CA resilience. Pick the variant that matches your rotation and release cadence, and ship backup pins and remote update before enforcement.

Operational context: The history of pinning (especially HPKP) is a case study in controls that are technically sound and operationally catastrophic when mis-deployed. The lesson is not “never pin”—it is “never pin without an update and escape path you have actually tested.”

---

Problem Statement

• Trust store is broad: Hundreds of CAs can chain to a valid server cert for your hostname; a compromised or coerced CA can issue a cert your clients will accept unless you narrow trust.
• Leaf pinning is brittle: The certificate will change on schedule or emergency; pinned clients fail closed with no graceful degradation.
• SPKI pinning still breaks on key rotation: Better for renewals that reuse keys, but key rotation is a security best practice—deferring rotation to preserve pins trades risks.
• CA pinning locks strategy: You trade leaf flexibility for issuer coupling—CA incidents, distrust events, or multi-CA failover become pin and process work.
• HPKP demonstrated systemic failure modes: Misconfiguration, lost keys, missing backup pins, and hostile pinning created lockouts and long-lived browser cache damage; major browsers removed HPKP.
• Browser and unmanaged clients are the wrong layer: End-user browsers cannot be pinned safely at scale; HPKP is gone; CT is the ecosystem response for the web.
• Short lifetimes and multi-CA multiply rotation events: The more often names or issuers change, the more often pins must move in lockstep with releases or remote config.

Failure scenario: A team ships hard-coded leaf pins in a mobile app without backup pins or remote override. The CA rotates the leaf earlier than the next app release; every installed client refuses the connection until users update—while competitors without pinning stay online. Alternatively, a mistaken HPKP header (historically) pinned the wrong SPKI for months, effectively bricking the site for cached users.

---

The Promise and the Wreckage

Certificate pinning was supposed to fix a fundamental weakness in TLS: the fact that any of the hundreds of certificate authorities in your trust store can issue a certificate for any domain. A compromised or coerced CA could issue a fraudulent certificate for your API, and your client would accept it without question.

Pinning said: do not trust the system. Trust this specific certificate, or this specific public key, or this specific CA—and reject everything else.

It worked. It also bricked applications, caused outages, and created operational nightmares so severe that browsers killed their own pinning mechanism. The history of certificate pinning is a case study in security controls that are technically correct and operationally catastrophic.

For how chains and trust anchors work in the abstract, see Trust models and TLS protocol.

How Pinning Works

At its core, pinning associates a host with an expected cryptographic identity. Instead of accepting any certificate signed by any trusted CA, the client checks whether the certificate (or its public key, or the issuing CA’s public key) matches a pre-configured value.

There are several variants, and the differences matter.

Certificate pinning

Pin the exact leaf certificate. The client stores the full certificate or its hash and compares on every connection.

Failure mode: When the certificate rotates—which it will, on a schedule you may or may not control—every pinned client breaks instantly. There is no graceful degradation. The connection is refused.

Public key pinning

Pin the Subject Public Key Info (SPKI) hash instead of the full certificate. As long as you reuse the same key pair when renewing, the pin remains valid.

Failure mode: Better than certificate pinning, but key rotation (which you should be doing) still breaks clients. If you are pinning the key to avoid rotating it, you have traded one security problem for another.

See Certificate anatomy for how the leaf certificate and keys relate to validation.

CA pinning

Pin the issuing CA’s public key. Any certificate from that CA passes validation; certificates from other CAs are rejected.

Failure mode: The most operationally forgiving variant. You can rotate leaf certificates freely. But you are now locked to a single CA. If that CA has an incident, has a policy change you disagree with, or gets distrusted by platforms, you are stuck.

CA distrust and migration patterns: CA distrust migration playbook.

The HPKP Disaster

HTTP Public Key Pinning (HPKP) was the browser-native implementation. It let servers send an HTTP header that instructed browsers to pin the site’s public key for a specified duration.

On paper, it was elegant. In practice, it was a footgun of extraordinary calibre.

The problems were predictable:

• Accidental lockout. Misconfigure the header, lose your key, or fail to include a backup pin, and your site becomes permanently inaccessible to browsers that cached the pin. For the entire max-age duration. Which could be months.
• Hostile pinning. An attacker who briefly compromised your server could set HPKP headers with their own pins and a long max-age, effectively hijacking your domain for the pin duration—even after you regained control.
• No recovery mechanism. There was no “unpin” instruction. Once a browser had cached a pin, only time (or clearing browser data) could remove it.

Chrome removed HPKP support in 2018. Firefox followed. The standard was effectively abandoned.

The lesson was not that pinning is bad. It is that pinning without a reliable update mechanism is a denial-of-service vulnerability you deploy against yourself.

Where Pinning Still Makes Sense

Despite the HPKP wreckage, certificate pinning remains a legitimate security control in specific contexts where you control both endpoints and have a reliable mechanism to update pins.

Mobile applications

This is the most common and most defensible use of pinning today. Your mobile app connects to your API. You control the app binary. You control the server certificate. Pinning prevents:

• Man-in-the-middle attacks on untrusted networks
• Compromised device trust stores (common on rooted/jailbroken devices)
• Surveillance proxies in corporate or state-controlled networks

Implementation approach:

• Pin the SPKI hash of your CA’s intermediate certificate, not the leaf. This gives you room to rotate leaf certificates without app updates.
• Always include at least one backup pin for a different CA’s intermediate. If your primary CA has an incident, you can switch without an emergency app release.
• Use a pinning library with reporting—OkHttp’s CertificatePinner on Android, TrustKit on iOS—so you get telemetry on pin failures before they become outages.
• Implement a pin expiry or remote kill switch. Hard-coded pins with no escape hatch are the mobile equivalent of HPKP’s max-age problem. If your pins need to change and your app update has not rolled out, you need a fallback.

IoT and embedded devices

Devices that connect to a single backend and have limited update mechanisms. The threat model is similar to mobile—untrusted networks, potentially compromised environments—but the update problem is worse.

The critical question: Can you update the pins remotely? If yes, pinning is viable. If the device’s pin list is baked into firmware that requires physical access to update, pinning is a ticking time bomb. You will eventually need to rotate, and when you do, every device with the old pin becomes a brick.

Internal service-to-service communication (mutual TLS)

In a zero-trust or service mesh architecture, services authenticate each other using mutual TLS. Pinning the internal CA—or even specific service identities—adds a layer beyond standard certificate validation.

This works because you control the entire certificate lifecycle: issuance, rotation, and revocation all happen within your infrastructure. The operational risks of pinning are manageable when you also control the CA.

See Mutual TLS patterns, mTLS, and Service mesh certificates.

High-value API integrations

If you are building a client that connects to exactly one external API—a payment processor, a banking API, a regulatory reporting endpoint—pinning that API’s CA certificate reduces your exposure to CA compromise.

The trade-off: you are coupling your client to their CA choice. If they switch CAs (and you would be surprised how rarely providers communicate this in advance), your integration breaks. Pin the CA, not the leaf, and monitor for changes.

When to Kill Your Pins

Pinning should be removed when the operational cost exceeds the security benefit, or when better alternatives exist.

You do not control the client

If end users access your service through browsers, pinning is effectively dead. HPKP is gone. Browsers rely on Certificate Transparency instead—a monitoring approach rather than a blocking approach. CT logs let you detect mis-issuance after the fact, without the self-DoS risk of pinning.

Your certificate lifecycle is unpredictable

If you are moving to shorter-lived certificates (90 days, 30 days, or less), pinning the leaf or key becomes increasingly fragile. Every rotation is a potential breakage point. Pin the CA if you must, but consider whether CT monitoring gives you sufficient protection without the operational coupling.

Shorter public TLS maxima: 47-day TLS certificates and Certificate automation readiness.

You are moving to multi-CA

Modern certificate strategies often involve multiple CAs for redundancy—if one CA has an outage or policy issue, you failover to another. Pinning to a single CA directly contradicts this resilience pattern.

If you need pinning and multi-CA, pin at the CA level for both CAs. But recognise you are maintaining a pin set that must be updated every time you add or remove a CA from your rotation.

Your update mechanism is unreliable

This is the most important criterion. If you cannot reliably push updated pins to all clients before the old pins break, do not pin. The security benefit of pinning is real but bounded. A self-inflicted outage affecting all clients is unbounded.

Ask yourself: if we need to change our pins tomorrow, what percentage of clients will have the update within 24 hours? 48 hours? A week? If the answer does not satisfy your availability requirements, pinning is the wrong control.

Lifecycle and rotation discipline: Certificate lifecycle management and Certificate rotation strategies.

Modern Alternatives to Pinning

The security problems that motivated pinning have not disappeared. The solutions have evolved.

Certificate Transparency monitoring

CT logs provide public, auditable records of every certificate issued by public CAs. Instead of blocking untrusted certificates at the client, you monitor for unexpected issuance and respond.

This is a detection control rather than a prevention control. For many threat models, detection within hours plus rapid revocation is sufficient—and it does not carry the self-DoS risk.

Operational starting points: Monitoring and alerting and discovery-oriented Inventory and discovery (including CT tooling references).

CAA records

DNS Certification Authority Authorisation (CAA) records specify which CAs are permitted to issue certificates for your domain. It is not as strong as pinning (a compromised CA could ignore CAA), but it prevents accidental mis-issuance and reduces your attack surface at the CA level.

Context on mis-issuance and CAA: Common vulnerabilities and Threat models and attack vectors.

Expect-CT and SCT validation

Signed Certificate Timestamps (SCTs) prove a certificate has been logged in CT. Requiring SCTs (where applicable) supports the goal that publicly trusted certificates are auditable. The Expect-CT HTTP header was part of this story but is deprecated in major browsers; focus on CT logging policy, embedded SCTs, and monitoring rather than header-based enforcement on the open web.

---

Checklist

If you have decided pinning is appropriate for your use case:

• Pin the SPKI hash of an intermediate CA certificate, not the leaf certificate.
• Include at least two pins—your primary CA and a backup CA—so you can rotate without downtime.
• Build a remote pin update mechanism before you deploy pinning. Not after.
• Implement pin failure reporting. Clients should report when they reject a pin, so you see problems before users report them.
• Set a pin expiry. Hard-code a date after which pinning is disabled and standard validation applies. This is your safety net.
• Test pin rotation in staging before every certificate change. Every time. No exceptions.
• Document your pin rotation runbook. When (not if) you need to change pins, the process should be mechanical, not improvisational.

---

The Bottom Line

Certificate pinning is a powerful control deployed in the wrong places far too often. It belongs in controlled client environments—mobile apps, IoT devices, internal services—where you own both sides of the connection and can reliably update pin configurations.

It does not belong in browsers (where it is already dead), in clients you do not control (where it is a liability), or in environments where your certificate lifecycle is not fully automated (where it is a future outage).

The best pinning implementation is one you have thought through carefully enough that you might decide you do not need it.

---

Related Documentation

• Certificate anatomy — leaf, chain, and SPKI in context
• Trust models — why the default trust store is broad
• TLS protocol — how validation and the handshake relate to pinning decisions
• Common vulnerabilities — CA and mis-issuance patterns, including CAA discussion
• Private key protection — key rotation and storage implications for SPKI pins
• Certificate lifecycle management — coupling pins to issuance and renewal
• Monitoring and alerting — CT and certificate monitoring operations
• Mutual TLS patterns — pinning in internal, CA-controlled environments

---

Certificate pinning decisions are tightly coupled to your certificate lifecycle automation. If you are evaluating whether pinning fits your architecture, talk to us about the full picture.