Notifications
Clear all
Topic starter
25/06/2026 10:37 pm
TL;DR: Firefox 32 added support for Public Key Pinning, which helps browsers reject certificates that do not match a site’s pinned and trusted certificate authorities and reduces exposure to man-in-the-middle attacks, according to DigiCert. The change strengthens transport trust, but it also shifts more responsibility to certificate governance and mis-issuance handling.
NHIMG editorial — based on content published by DigiCert: Firefox 32 Supports Public Key Pinning
By the numbers:
- Firefox 32+ will support built-in pins and pinning will be enforced by default.
- Firefox 32 for Windows, Mac, Linux, and Android was launched on September 2, 2014.
Questions worth separating out
Q: How should security teams govern certificate trust for high-value sites?
A: Security teams should treat certificate trust as a governed identity control, not a static browser setting.
Q: Why do public key pinning failures matter to IAM and NHI programmes?
A: Pinning failures matter because certificates are identity evidence for websites, APIs, and workloads.
Q: What do organisations get wrong about certificate pinning?
A: The most common mistake is assuming pinning is only a defensive browser feature.
Practitioner guidance
- Inventory every domain that depends on certificate trust Map which public-facing services, APIs, and partner endpoints rely on pinned or CA-sensitive certificates.
- Test certificate replacement before enforcing pinning Stage renewal and CA migration exercises for pinned domains, then validate the full chain in browser and automation paths before production cutover.
- Align trust governance with certificate lifecycle control Tie certificate issuance, replacement, revocation, and emergency rollback to the same change-management process used for access-critical identity assets.
What's in the full article
DigiCert's full blog post covers the browser-side implementation detail this post intentionally leaves for the source:
- How Firefox handles built-in pins versus site-advertised PKP support in practice
- Which domains Mozilla had already pinned at the time and how pinned trust is surfaced to users
- Why some users saw secure connection failures over WiFi and what that means for troubleshooting
- Where to find the Public Key Pinning wiki for checking pinned domains and browser behaviour
👉 Read DigiCert’s explanation of Firefox 32 public key pinning →
Public key pinning in Firefox 32: what changed for site trust?
Explore further
25/06/2026 11:14 pm
Public Key Pinning is a certificate governance control, not just a browser feature. The article frames PKP as a user protection measure, but the deeper issue is trust boundary enforcement at the certificate layer. When a browser rejects a mismatched chain, the organisation’s certificate lifecycle, CA selection, and recovery process become part of its access-control model. Practitioners should treat pinning as governed identity infrastructure, not a cosmetic hardening option.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
A question worth separating out:
Q: Who should own certificate trust decisions in an organisation?
A: Certificate trust should sit with the teams that own identity, platform, and security operations together. Browser trust rules affect availability, spoofing resistance, and endpoint assurance, so ownership cannot live only with infrastructure or only with application teams. Shared governance is the only durable model.
👉 Read our full editorial: Firefox 32 public key pinning changes site trust controls
