RFC 7469 defines HTTP Public Key Pinning (HPKP), a security mechanism that let websites tell browsers: "When you connect to me, only trust these specific cryptographic keys." It's one of the most fascinating RFCs in the security canon—not because it succeeded, but because it was technically correct, practically catastrophic, and ultimately killed off by the very browsers that implemented it.

The problem it solved was real and urgent. The TLS certificate authority (CA) system has a fundamental weakness: any of the hundreds of trusted CAs can issue a certificate for any domain. In 2011, the Dutch CA DigiNotar was compromised, and attackers minted fraudulent certificates for *.google.com, enabling man-in-the-middle attacks against Iranian Gmail users. That wasn't hypothetical—it happened. Google discovered it only because Chrome happened to have hardcoded "pins" for Google's own domains.

HPKP generalized that hardcoded approach into a standard HTTP header. A server would send:

Public-Key-Pins: pin-sha256="base64=="; pin-sha256="backup-base64=="; max-age=5184000

The browser would remember those pins and, for the specified duration, refuse any TLS connection to that domain that didn't chain through one of the pinned public keys. The design had several thoughtful requirements:

• Backup pins were mandatory. You had to include at least one pin not currently in your certificate chain—a disaster recovery key. This was meant to prevent you from locking yourself out if your primary key was lost.
• Report-Only mode via Public-Key-Pins-Report-Only let you monitor without enforcement, sending JSON violation reports to a specified URI.
• includeSubDomains extended pinning across all subdomains, similar to HSTS.
• max-age controlled how long browsers remembered pins, with the RFC recommending 60 days.

So why did it die? HPKP had a design flaw that couldn't be patched: it gave site operators a loaded weapon with no safety. If you pinned the wrong keys—through misconfiguration, key loss, CA migration, or an attacker who briefly gained control of your HTTP headers—your site became permanently unreachable to browsers that had cached the pins. This became known as "HPKP Suicide". Worse, researchers demonstrated "RansomPKP": an attacker with temporary access to your server could set hostile pins with a long max-age, effectively holding your domain hostage.

The backup pin requirement wasn't enough protection. Operators forgot to keep backup keys accessible, or their CAs rotated intermediates unexpectedly. A single operational mistake could brick your domain for months. Google themselves, who championed the spec, recognized the risk-reward ratio was terrible for most sites.

Chrome removed HPKP support in 2018 (Chrome 72). Firefox followed. The mechanism was effectively dead within three years of its RFC publication. Its spiritual successor is Certificate Transparency (CT), specified in RFC 6962 and its updates, which solves the rogue-CA problem through public, auditable logs rather than fragile per-site pinning. CT lets anyone detect a misissued certificate after the fact, without requiring each site operator to manage cryptographic pins.

The Report-Only mode from HPKP did survive conceptually—the Expect-CT header (now also deprecated since CT is mandatory in most browsers) borrowed the same reporting pattern. Today, the entire problem space is handled by CT enforcement baked into browser root programs: CAs must log certificates publicly, or browsers reject them.