The helpdesk ticket usually reads the same way. A handful of users cannot reach one specific application, only on the corporate network, only since last Tuesday. Everything else works. The application vendor says their service is fine, and they are right. What changed is that your secure web gateway started inspecting encrypted traffic, and that application pins its certificate.
Certificate pinning sits in an awkward spot. It is a genuine defence against a class of attacks that ordinary certificate validation cannot stop, and it is simultaneously one of the most reliable ways to break your own application for everyone, everywhere, at once. Both statements are true, which is why the advice you find online splits neatly into developer documentation that explains how to implement it and vendor blogs that tell you never to touch it.
This article takes the middle position, because that is where the operational reality lives: what pinning actually does, what the industry learned when it tried to make pinning a web standard, where it still earns its place, and what to do when it collides with the security controls on your own network.
What certificate pinning is
Certificate pinning is a client-side control that forces an application to check a server’s TLS certificate against a hardcoded list of expected values, instead of trusting any certificate that chains to a recognised authority. If the presented certificate does not match the pin, the connection is refused, even when it is technically valid and signed by a trusted root.
To see why that matters, consider what normal validation does. When a client connects to a server, it receives a certificate chain and checks whether it ends at a root certificate in the device’s trust store. That store contains hundreds of authorities. Any one of them can issue a certificate for any domain. Standard validation asks “did somebody trustworthy vouch for this?”, not “did the right party vouch for this?” — and if a single authority is compromised, coerced, or tricked, the answer to the first question stays yes.
Pinning replaces that broad question with a narrow one. The application carries its own expectation of the server’s cryptographic identity and enforces it regardless of what the operating system thinks.
What exactly gets pinned
The choice of what to pin determines how fragile the arrangement is, and it is where most pinning failures originate.
Leaf certificate pinning binds the client to one specific end-entity certificate. It is the tightest restriction and the most brittle: the moment that certificate is renewed, the hash changes and every client must be updated in lockstep.
Intermediate CA pinning targets the authority that signs the leaf. Backend teams can then rotate leaf certificates freely, as long as they keep buying from the same intermediate. The catch is that you have handed trust back to the CA infrastructure, and intermediates rotate more often than most teams expect.
SPKI pinning hashes only the Subject Public Key Info structure — the public key itself, not the certificate wrapped around it. This is the option worth knowing. When a certificate expires, an administrator can generate a new signing request using the existing key pair; the new certificate has fresh dates and a new serial number, but an identical SPKI hash. Pinned clients never notice. That property is what makes pinning survivable at all, and OWASP’s guidance treats SPKI as the default choice.
Static and dynamic pins
Static pinning bakes the pin set into the application at build time — an Android network security configuration file, or a trust-evaluation callback on iOS. It is easy to audit and easy to reason about, and it welds your network operations to your app release cycle.
Dynamic pinning separates the two. The application ships with bootstrap pins and then fetches a signed pin manifest from a management endpoint or a device management profile, using a signing key that has nothing to do with the web PKI. When a backend key has to change in a hurry, security operations updates the manifest instead of shipping an emergency build through an app store review queue. Any organisation running pinning at scale ends up here eventually.
The lesson the web already learned
In April 2015 the IETF standardised pinning for browsers as HTTP Public Key Pinning, RFC 7469. A site sent a header listing SPKI hashes and a duration; browsers cached that list and enforced it strictly for the stated period, with no click-through warning. The specification even required a backup pin for a key not currently in use, precisely because the authors could see the danger.
It was not enough. Two failure modes finished HPKP off.
HPKP suicide was the self-inflicted version. An operator lost a backup key, or rotated to a new authority without updating the header first, and every returning visitor was locked out for the full cached duration — often months. Deploying a new, perfectly valid certificate did not help, because the browser was not asking whether the certificate was valid. There was no remote undo.
RansomPKP was the malicious version. An attacker with brief control of a web server injected a pin header referencing keys only they possessed, with a long lifetime, and left. The site owner cleaned up the intrusion and then discovered that every visitor who had received the poisoned header could no longer reach the site — and that the attacker was willing to sell the matching private keys.
Chrome announced deprecation in late 2017 and removed enforcement in Chrome 67 in May 2018; Firefox followed. The replacement was not another client-side lock but ecosystem-wide visibility. Certificate Transparency requires authorities to log every issued certificate to public, append-only logs, and browsers reject certificates that lack proof of logging, so a fraudulent certificate for your domain becomes something you can detect within minutes rather than something you must pre-emptively block. DNS CAA records let you declare which authorities may issue for your domains at all, and baseline requirements oblige public CAs to honour that declaration.
The shift is worth stating plainly, because it explains the whole modern posture: the web moved from active client-side prevention to fast ecosystem-wide detection, and it did so because prevention kept shooting the wrong target.
Where pinning breaks your operations
The TLS inspection collision
This is the failure that lands on your desk rather than a developer’s. A secure web gateway inspects encrypted traffic by terminating the session: it validates the real server’s certificate on its own outbound connection, then generates a synthetic certificate for that hostname, signs it with an internal enterprise root, and presents it to the client. Managed devices accept this because the enterprise root was installed in their trust store.
A pinned application does not care what is in the trust store. It extracts the public key from whatever certificate arrives, compares the SPKI hash to its pin, finds the gateway’s key instead of the server’s, and concludes that it is being intercepted — which, from its point of view, is exactly right. It fails closed, and the user gets a network error with no useful detail.
Three bypass patterns exist, in descending order of precision. Destination bypass rules exempt specific hostnames or address ranges from inspection, so the genuine chain reaches the client untouched. Category bypasses do the same for whole classes of destination — finance and healthcare endpoints are the usual candidates, since those are the applications most likely to pin. Process-level exceptions on the endpoint suppress redirection for a specific signed binary. Each is a hole in your inspection coverage, so the smallest workable exemption is the right one; our guide to encrypted traffic inspection in modern SASE covers how those policies fit together.
The rotation problem
Pins have to be maintained, and the maintenance interval is shrinking. Public TLS certificate lifetimes are contracting on a fixed industry schedule, which multiplies the number of rotation events a pinned deployment has to survive without incident.
Automation makes this sharper than it sounds. Most ACME clients generate a fresh key pair on renewal unless explicitly told to reuse the existing one. That single default turns a routine renewal into a global outage for pinned clients: the certificate is valid, the chain is fine, and every pinned application on earth rejects it because the public key changed.
The clearest published evidence of this comes from Cloudflare. During 2024 the company migrated default edge certificate issuance between authorities while intermediate keys rotated at Google Trust Services and Let’s Encrypt. Pinning-related customer outages in the second and third quarters of that year exceeded the total recorded across the previous three years combined. The pattern was consistent: pins set years earlier and forgotten, sometimes compiled into third-party SDKs without the app owner’s knowledge, discovered only when the backend presented a valid certificate from a different authority and every client hard-failed at once.
Where pinning genuinely earns its place
Set against that, pinning stops attacks that nothing else in the transport layer stops.
A compromised or coerced certificate authority can issue a technically valid certificate for your domain. Standard validation accepts it. A pinned client does not.
A malicious root injected into the local trust store — by malware with administrative rights, or by a hostile device management profile — gives an attacker transparent interception of everything on that device. Pinning lets one high-value application opt out of the operating system’s trust decisions entirely.
A BGP hijack timed against automated domain validation lets an attacker redirect traffic just long enough to satisfy an HTTP or DNS challenge and obtain a genuinely signed certificate. The paperwork is legitimate; only the key is wrong, which is precisely what a pin checks.
This is why OWASP’s Mobile Application Security Verification Standard requires identity pinning at its Level 2 profile, the profile intended for banking, healthcare and other high-value transactional apps. Note the boundary the standard draws: pin endpoints under your own control, never third-party analytics, payment gateways or SaaS dependencies whose certificate lifecycle somebody else manages. Pinning something you do not operate is a scheduled outage with someone else’s hand on the trigger.
The decision, by scenario
| Scenario | Pin? | Why |
|---|---|---|
| Native mobile banking or fintech app | Yes — SPKI with backup pins | High interception risk on untrusted networks; required for OWASP MASVS Level 2 |
| Standard enterprise web application | No | Browsers removed HPKP; rely on Certificate Transparency monitoring, CAA and HSTS |
| Corporate app used behind a secure web gateway | No, or an explicit inspection bypass | Pinning and inspection cannot both win; decide deliberately which one you need |
| Managed IoT or edge fleet talking to your own API | Yes — SPKI, dynamic where possible | Controlled fleet, controlled backend, no surprise authority changes |
| ZTNA client agent | No — use mTLS | Static pins block the automated enrolment and rotation the model depends on |
Pinning, mTLS and Certificate Transparency are not alternatives
These three controls get compared as if you must choose one. They answer different questions.
Pinning is unidirectional: it constrains which server keys a client will accept, and tells the server nothing about who is calling. Mutual TLS is bidirectional: the server demands a client certificate and verifies possession of the matching private key, which produces a cryptographic identity you can write access policy against. Certificate Transparency is neither — it is ecosystem-wide detection that tells you when someone issues a certificate for your domain that you did not ask for.
In a high-assurance design they compose. A mobile client pins the SPKI of your public API gateway, so a hostile network cannot interpose itself. Inside that tunnel, the client presents a device certificate issued through your own enrolment process, and the gateway maps that identity to per-application access rights. Transparency monitoring runs alongside both, watching for issuance you did not authorise. Add token-level controls at the application layer — the ground covered in API tokens explained — and each layer covers a different failure of the one beneath it.
One boundary is worth stating, because it is a common misreading: pinning protects the transport between an app and its backend. It does not stop adversary-in-the-middle phishing against browser sessions, where the victim is talked into visiting the attacker’s proxy and the TLS is entirely legitimate. That threat needs different countermeasures, which we set out in how AiTM phishing works and what stops it.
Both camps are right about something
The case for aggressive pinning is made by application security teams in finance and healthcare, and it rests on timing. Certificate Transparency is detection, not prevention. A fraudulent certificate exists and works from the moment it is issued; a monitoring alert reaches your security operations centre minutes or hours later, and revocation propagates unevenly after that. For an application moving money, the window between issuance and response is a window in which credentials and session tokens leave the device. A pin closes that window arithmetically rather than procedurally.
The case against any pinning is made by infrastructure and network teams, and it rests on failure statistics. Certificate lifetimes are contracting, backends move between authorities for resilience, automated renewal regenerates keys by default, and every one of those normal events is a global outage for a pinned client that was not updated in time. The Cloudflare data is the empirical version of this argument. And on corporate networks, pinning forces inspection bypasses that reduce the coverage of the malware and data-loss controls you deployed on purpose.
The honest resolution follows the deployment, not the ideology. For websites and browser-based applications, pinning is settled: it is gone, and Certificate Transparency plus CAA plus HSTS is the answer. For corporate applications on managed devices, prefer device posture, identity-gated access and mTLS over server pinning, so your gateway can do the inspection you bought it for. For native mobile applications in high-assurance sectors, pin — but only with SPKI hashes, only for endpoints you control, always with backup pins and a remote update path, and always with telemetry that tells you a pin is failing before your users do.
Decide it once, deliberately
Most pinning incidents are not caused by a wrong decision. They are caused by no decision at all: a pin compiled in years ago by someone who has left, or buried in a third-party SDK, discovered on the day a certificate rotates. Inventory where pinning exists in the applications you operate, write down for each one whether it is still justified, and make sure the ones you keep have backup pins and a way to update them without an app store release.
For the other half of the problem — the applications you do not control colliding with your own inspection policy — the fix is policy design rather than code. Jimber’s secure web gateway is part of one EU-sovereign SASE platform, which means inspection policy, bypass rules and the access controls around them live in a single console rather than three, and exemptions stay narrow and reviewable instead of accumulating quietly. Book a demo to see how that policy layer works in practice, or read more about the secure web gateway first.
Frequently asked questions
Is certificate pinning still recommended in 2026?
Not for websites or standard enterprise web applications: browsers removed HPKP support in 2018, and Certificate Transparency with CAA records covers that ground without the outage risk. SPKI pinning remains recommended for high-assurance native mobile applications under OWASP MASVS Level 2, provided backup pins and a remote update mechanism exist.
Why was HTTP Public Key Pinning deprecated?
HPKP created two failure modes browsers could not accept. Operators locked their own visitors out for months by losing backup keys or rotating authorities without updating headers, and attackers with brief server access injected hostile pin headers to hold sites hostage after being evicted. Chrome removed enforcement in Chrome 67 in May 2018; Firefox followed.
How does certificate pinning break enterprise TLS inspection?
An inspecting gateway terminates the TLS session and presents a synthetic certificate signed by an internal enterprise root. Pinned applications ignore the operating system trust store entirely and compare the presented public key against their pin. Because the key belongs to the gateway rather than the real server, validation fails and the application closes the connection.
What is the difference between leaf pinning and SPKI pinning?
Leaf pinning binds the client to one exact certificate, so every renewal requires a synchronised client update. SPKI pinning hashes only the public key structure, so a certificate can be reissued with new dates and serial numbers without breaking clients, as long as the same key pair is reused. SPKI is the safer default.
How is pinning different from mutual TLS?
Pinning is a one-way control: the client restricts which server keys it will accept, and the server learns nothing about the client. Mutual TLS authenticates both sides, giving the server a verified client identity it can enforce access policy against. In zero-trust designs mTLS provides the identity layer; pinning, where used, hardens the transport around it.
How do I fix an app that a secure web gateway has broken?
Create a targeted inspection bypass rather than disabling inspection broadly. Exempt the specific destination hostnames or address ranges the application uses, so the genuine certificate chain reaches the client untouched. Keep the exemption as narrow as possible and review it periodically, because every bypass is traffic your gateway no longer inspects.
What happens when a pinned certificate rotates?
If the backend key changes without a matching pin update, every affected client rejects all connections immediately and stays broken until an updated configuration reaches it. With SPKI pinning this is avoidable by reusing the existing key pair on renewal — but note that most automated renewal clients regenerate keys by default unless configured otherwise.
Should we pin third-party services and payment gateways?
No. OWASP guidance restricts pinning to endpoints under your own control, because a third party can change certificates, keys or authorities at any time without telling you. Pinning a dependency you do not operate hands an outage trigger to someone with no obligation to coordinate with your release schedule.
