Certificate Pinning Explained: Risks, Failures and Alternatives

Certificate pinning began as a reasonable instinct. If you want to be sure you are talking to the right server, why not hard-code the expected certificate or key and refuse anything else?

In an era of less mature certificate ecosystems, that instinct had merit. Today, in most environments, it has become a source of fragility that can take a service offline and leave teams with few good options.

This article explains what certificate pinning is, how it works, why it now tends to cause more problems than it solves, what to do when a pin fails, and what to use instead.

What certificate pinning is

Pinning means binding a client to a specific certificate or public key, so that the client will only trust connections presenting that exact pin. Rather than accepting any certificate that chains to a trusted authority, the client demands a particular one.

HTTP Public Key Pinning, or HPKP, was a browser-based mechanism that attempted to standardise this for the web. The underlying idea appears in mobile apps, embedded devices and other clients too: embed the expected identity and reject anything that does not match.

On paper, this narrows trust to exactly what you expect. In practice, it couples your client tightly to a certificate that, by design, is meant to change.

How pinning works

Normal certificate validation asks whether the presented certificate chains to a root the client already trusts, whether it has expired, and whether the name matches. Pinning adds a further check: does this specific certificate, key or issuer match the value I was given in advance?

If that check fails, the connection is refused — regardless of whether the certificate is otherwise entirely valid. That is the whole point, and it is also the whole problem.

Three levels of pinning

• Certificate pinning. The client stores a hash of the full end-entity certificate. Maximum specificity, and maximum fragility — the pin breaks on every renewal, even when the key stays the same.
• Public key pinning. The client stores a hash of the public key rather than the certificate. This survives certificate renewal provided the key pair is reused, which is why it is the more common approach. It still breaks on key rotation, and reusing keys across renewals is itself poor practice.
• CA or intermediate pinning. The client pins the issuing authority rather than the leaf. More tolerant of renewal, but it breaks when the CA rotates its intermediates — which several authorities now do deliberately.

Where the pin lives

In a mobile application the pin is typically compiled into the app, which means changing it requires an app release and every user updating. In an embedded device it may be in firmware, with the same problem and a slower update path. HPKP delivered pins over HTTP headers with a max-age, which created the possibility of pinning a site into unreachability for the duration of that header.

The common factor is that the pin is easy to deploy and hard to change. Certificates are the opposite.

Where pinning goes wrong

Lockout after key compromise or loss

If a pinned key is compromised, lost, or simply needs rotating, every client holding the old pin will reject the new certificate. Instead of a routine renewal, you face an outage that can only be resolved by updating every client — which for distributed or mobile clients can be slow or impossible.

Malicious pin hijacking

Pinning mechanisms can themselves be abused. A misapplied or hostile pin can lock legitimate users out of a service, turning a protective control into a denial-of-service vector.

Fragility around revocation

When a certificate authority needs to revoke and reissue, pinning fights against the very agility that revocation requires. The control meant to harden trust ends up obstructing the response to a security event.

Collision with shortening certificate lifetimes

This is the newest problem and the one that will retire pinning in most environments. Public TLS certificate lifetimes are falling to 47 days by 2029. Certificate pinning at that cadence means updating pins roughly eight times a year across every client. It is not sustainable, and the industry knows it.

These failure modes are well understood, which is why HPKP was deprecated and why the wider industry now treats pinning as a practice to approach with great caution. Some certificate authorities deliberately rotate intermediate certificates on a regular cadence, in part to discourage brittle pinning.

Certificate pinning failure: what to do

If a pin has broken and a service is down, the diagnosis and the options are both narrow.

Recognising it

Pinning failures rarely announce themselves. The certificate is valid, the chain is intact, the hostname matches, and a browser would accept it — but the pinned client refuses. Symptoms usually present as an application error rather than a certificate error, which is what makes diagnosis slow.

The tell is that the failure correlates with a certificate change and affects only the pinned clients. If a service works in a browser but fails in the mobile app, and a renewal happened recently, that is almost always the cause.

Immediate options

• Revert to the previous certificate if it has not expired and the private key is still available. This buys time, and it is usually the only fast fix.
• Reissue with the original key pair if public key pinning was used and the key is retained. The pin survives certificate renewal.
• Push a client update. The correct long-term fix and almost never fast enough. App store review, device update windows and user adoption rates all work against you.
• Disable pin enforcement remotely if a kill switch was built in. Most implementations do not include one, which is a design lesson for anyone still pinning.

Afterwards

Treat a pinning failure as a signal rather than an incident to close. It indicates a client coupled to something designed to change, and the next renewal will do the same thing unless the coupling is removed.

When pinning is still justified

The argument against pinning is not absolute. There are contexts where it remains defensible.

• You control both ends. A mobile app talking to a backend you operate, where you can coordinate certificate changes with app releases, is a genuinely different situation from pinning against a third-party service.
• The threat model justifies it. High-assurance applications where a compromised or coerced certificate authority is a realistic concern — some financial, government and defence contexts qualify.
• There is no trust store to rely on. Embedded devices without a maintained set of trusted roots have fewer alternatives.

Where pinning is retained, it should be public key pinning rather than certificate pinning, it should include backup pins for a key you have not yet deployed, and it must include a remote kill switch. Pinning without a backup pin and a disable mechanism is an outage waiting for a trigger.

What to use instead

The concern behind pinning is legitimate: how do you stop a certificate being issued for your domain by an authority you did not authorise? Several mechanisms now address that without coupling clients to a specific certificate.

• CAA records. A DNS record specifying which certificate authorities are permitted to issue for your domain. CAs are required to check it, so this prevents the misissuance rather than detecting it afterwards.
• Certificate Transparency monitoring. Every publicly trusted certificate is logged to public, append-only logs. Monitoring those logs tells you if a certificate is issued for your domain, even if it is never deployed. This is detection rather than prevention, but it covers the case CAA cannot.
• Trust store hygiene. In controlled environments, managing which roots clients trust achieves much of what pinning attempted, without binding to individual certificates.
• Private PKI for internal services. Where you control both ends, issuing from your own PKI gives you the narrow trust boundary pinning was reaching for, with none of the rigidity.
• Short certificate lifetimes. The CA/Browser Forum's own reasoning for reducing validity is partly that shorter lifetimes limit exposure without depending on revocation working. That logic applies to pinning too.

The better instinct: agility, not rigidity

The deeper lesson is about how trust should behave at scale. Pinning assumes certificates are stable. Modern infrastructure assumes the opposite: certificates are short-lived, they rotate frequently, and the system has to absorb that change without drama.

The resilient posture is not to freeze a certificate in place, but to make change routine and well-governed.

That is the logic of certificate lifecycle management. When you have full visibility of your certificates and automated processes for renewal and rotation, the events that break a pinned system become ordinary operations. Our articles on why traditional certificate management is no longer enough and overcoming resistance to automation make the same point from different angles: rigidity is the risk, and automation is the answer.

It is also the same argument that applies to crypto-agility. A system that cannot tolerate a certificate changing will not tolerate an algorithm changing either, and the post-quantum transition will require exactly that.

If you currently rely on pinning

Removing pinning is not something to do blindly, particularly in mobile or embedded clients where it may have been added deliberately. The right approach is to understand why it was introduced, what threat it was meant to address, and whether that threat is better handled another way.

In most modern web contexts, robust certificate management and proper trust-store hygiene achieve the goal without the fragility.

• Inventory where pinning is in use and why. This is harder than it sounds, since pins are often added by individual development teams and documented nowhere.
• Assess the real outage risk if a pinned key had to change today. How long would a client update take to reach 95% of users?
• Check whether backup pins and a disable mechanism exist. If not, that is the most urgent fix regardless of the longer-term decision.
• Plan a transition to automated certificate management with a controlled rollback path.

How Unsung helps

Pinning usually surfaces during a migration or a certificate estate assessment, because it is one of the dependencies that causes an otherwise routine change to break something. Identifying it requires application-level engagement rather than infrastructure analysis alone.

A PKI health check establishes where these dependencies sit, and our PKI consultancy team can plan the transition to an automated model without disrupting the clients currently relying on it.

Talk to our team if pinning is on your risk register.