RFC 7469 defined HTTP public key pinning and also documented how it can backfire: a lost key locks users out, a broad includeSubDomains setting breaks hosts you forgot, and an attacker with a valid certificate can pin your domain to their keys. Those lessons apply to every pinning scheme, in browsers or apps.
Note: check current browser support before relying on the HTTP header itself. This post is about what the specification teaches, not a recommendation to deploy it.
What pinning is
Pinning tells a client to accept just certificates whose public key matches a remembered fingerprint, so a compromised or misbehaving certificate authority cannot vouch for your host. RFC 7469 did this with a response header carrying one or more pin values plus a max-age. The goal, in the RFC's words, is to reduce man in the middle attacks caused by compromised authorities.
Risk 1: losing the key
If the sole pinned key is gone, clients refuse your site until the pin expires. The RFC's answer is the backup pin, a fingerprint of a secondary, not yet deployed key pair that you keep offline. If you lose the primary, you deploy the backup and clients that saw the pin accept it. The takeaway for any pinning: always ship at least one backup, and test the switch before you need it.
Risk 2: scope you did not mean
The includeSubDomains directive extends pins to every subdomain. The RFC's security section warns about using it safely, and suggests using the same pin set across hosts under a parent domain if you use it. A forgotten staging host with a different certificate then fails for pinned clients.
Risk 3: hostile pinning
The RFC names the case where an attacker obtains a valid certificate, through misissuance or by being a prior owner of a domain, and sends a pinning header that pins to keys they choose. A client that has no earlier pin may record the attacker's. That is a denial of service that outlasts the attack itself.
Applying this to your own pinning
| Decision | Safer choice |
|---|---|
| What to pin | A public key you control, plus a backup key |
| How long | Short enough to recover from a mistake |
| Scope | Named hosts, not every subdomain |
| Rotation | Practice on a schedule, not during an outage |
| Fallback | A remote way to update pins without an app release |
Do not pin to an intermediate certificate you do not control. Authorities can change them. See should you pin Let's Encrypt intermediates. For mobile specifics, read Android pinning, expiry and backup pins.
Where Safeguard fits
Safeguard scans dependencies and SBOMs for known vulnerabilities, including those in the TLS and crypto libraries your projects pull in, and you can try it with the free scan at gold.safeguard.sh/scan.
Quick check
What is a backup pin?
A fingerprint for the public key of a secondary key pair that is not deployed yet and is kept offline, so you can switch to it if the primary is lost.
Is pinning always a good idea?
No. It trades risk of interception for risk of lockout. Use it where you control both ends and can update pins safely.
Sources
Last reviewed: 19 October 2026.
