The problem HPKP set out to solve is genuine. The web trusts a large number of certificate authorities, and your browser will accept a certificate for any domain if any trusted CA signed it. If even one CA is compromised or tricked into issuing a certificate for a domain it should not have, an attacker can present that certificate and impersonate the site. This has happened. The 2011 compromise of the DigiNotar CA led to fraudulent certificates for major services being used against real users.
HTTP Public Key Pinning, standardized as RFC 7469 in 2015, was the answer. Let a site declare, in advance, a short list of keys that are the only ones allowed to represent it. Then a rogue certificate from some unrelated CA, however validly signed, gets rejected because its key is not on the list.
How the Header Worked
A site sent a response header, Public-Key-Pins, containing one or more hashes of allowed public keys, a lifetime, and options. A pin was a SHA-256 hash of a key in the certificate chain, and the specification required at least two: the key in current use, and at least one backup key not yet deployed.
On the first visit, the browser recorded the pins and how long to remember them, set by a max-age value that could stretch to months. On every later visit within that window, the browser required that at least one pinned key appear somewhere in the certificate chain the server presented. If none did, the connection was refused outright, with no click-through and no override. That strictness was the entire point. A pin the user could bypass would defend against nothing.
Trust on first use, then enforce. The browser believes the pins it saw on an earlier visit and will hard-fail any future connection whose certificate chain does not contain one of them, for the full pinned lifetime.
This is trust-on-first-use pinning, a cousin of the TOFU model used elsewhere in security. And like all TOFU designs, its safety depends entirely on the first observation being honest and the remembered value staying correct. That is exactly where it fell apart.
Failure One: Pinning Suicide
Because the browser enforces the pins strictly for the full lifetime, a site that loses control of its pinned keys locks itself out of its own users' browsers. Operators called this HPKP suicide.
Consider the ways it happens. Your certificate provider changes the key on renewal and you forgot to pin a backup that matches. Your backup key is destroyed in a server rebuild. You migrate CDNs and the new provider controls the keys. In each case, returning visitors within the max-age window get a hard failure with no recourse, and you cannot fix it by deploying a new certificate, because the new certificate's key is not pinned. You have to wait for the pins to expire in each user's browser, which could be months.
A defense that hard-fails for months on a configuration mistake is not a defense a busy operations team can safely deploy. The blast radius of a small error was the whole site, for a long time, with no undo. Why careful operators avoided HPKP even when they understood it
Failure Two: Hostile Pinning
The second failure turned the feature into a weapon. Suppose an attacker briefly gains the ability to serve responses for a site, through a server compromise, a misconfigured shared host, or a subdomain they control. They can send a Public-Key-Pins header pinning keys that only they hold, with a long lifetime.
Now visitors' browsers have recorded pins for keys the legitimate owner does not have. When the owner regains control and serves their real certificate, browsers reject it, because it does not match the attacker's pins. The rightful operator is locked out of their own audience until the malicious pins expire. Researchers called this RansomPKP or hostile pinning, and it inverts the whole purpose of the mechanism: the tool built to stop impersonation becomes a tool for denial of service against the true owner.
Why Browsers Walked Away
The combination proved fatal. HPKP demanded flawless key management, punished mistakes with long outages, offered a path for attackers to lock owners out, and delivered its benefit only to the small number of sites that could operate it safely. Adoption stayed very low. Google announced deprecation and removed support from Chrome in early 2019. Other browsers followed or never fully committed. The header still exists in old documentation, but sending it does nothing in a current browser.
| Property | The verdict |
|---|---|
| Threat addressed | Real. Mis-issued certificates from any trusted CA could impersonate a site. |
| Operational safety | Poor. A single key-management error caused a long, unrecoverable outage. |
| Abuse potential | High. Hostile pinning let a temporary intruder deny service to the real owner. |
| Outcome | Deprecated and removed. Replaced by a detection-based approach. |
What Replaced It
The web did not abandon the underlying goal of catching mis-issued certificates. It changed strategy from prevention by pinning to detection by transparency. Certificate Transparency requires certificates to be recorded in public, append-only logs. A domain owner, or anyone, can monitor those logs and spot a certificate they never requested. Instead of every browser rigidly enforcing a brittle local rule, the ecosystem makes mis-issuance visible so it can be revoked and the responsible CA held accountable. CT is now effectively mandatory for public certificates, and it carries none of HPKP's self-destruct risk.
It is worth separating this from a mechanism that survives and is still useful. Certificate pinning inside a mobile app is a different animal. The app ships with the pins baked in, the developer controls both the pins and the keys, and an update can change them safely. That controlled, first-party pinning avoids exactly the two failures that killed HPKP, because there is no untrusted first observation and no way for an outsider to plant a pin.
The lasting lesson is about operational blast radius, not cryptography. HPKP's cryptography was fine. It failed because it gave operators a loaded footgun and gave attackers a lever, and a security feature that is dangerous to run is a feature that does not get run. The best defenses fail safe, degrade gracefully, and forgive the ordinary mistakes that real teams make under pressure. HPKP did none of those, and that, not any flaw in the math, is why it is gone.