Certificate Pinning: Why a Once-Sensible Practice Has Become a Liability

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, why it now tends to cause more problems than it solves, and why a disciplined, automated approach to certificates is the more resilient path.

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. 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 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.

Where pinning goes wrong

Lockout after key compromise or loss

If a pinned key is compromised, lost, or simply needs to be rotated, 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 that was meant to harden trust ends up obstructing the response to a security event.

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.

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.

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.
• Assess the real outage risk if a pinned key had to change today.
• Plan a transition to automated certificate management with a controlled rollback path.

‍