SSL pinning is when an app trusts not just any valid certificate from any certificate authority, but a specific certificate or public key for the server, built directly into the code ahead of time.
Why pinning is used
Pinning protects against a situation where the connection presents a certificate that can formally be trusted, but it was not issued for the real server: a rogue certificate authority, interception at the level of a corporate network, or a compromised authority that issued someone else's certificate for the needed name.
What pinning does not protect against: a breach of the server itself, a vulnerability in the app's own code, or data leaking after the encrypted connection has already been set up. It only checks who the connection is actually made with, not what happens afterward.
How trust usually works without pinning
Without pinning, an app checks only one thing: whether the server's certificate is signed by one of the authorities the operating system trusts. Any of the hundreds of such authorities is formally equal to the rest. The app does not care which authority issued the certificate, as long as the chain of signatures leads up to a trusted root.
What exactly gets pinned
Different parts of the certificate can be pinned, and the choice determines how often the app will need an update.
| What is pinned | How fragile it is at certificate renewal |
|---|---|
| The whole certificate | The most fragile option: it changes at every renewal, even if the key stayed the same |
| The public key | Survives renewal if the key did not change, breaks only when the key itself changes |
| The intermediate authority | The most durable, but weaker protection — trust shifts to the whole authority |
The main danger
When the server's certificate is renewed as planned, an app with outdated pinning stops connecting to the server for every single user at once — and this happens not gradually but right after the certificate switches over. The only fix is updating the app itself, and that update does not reach users instantly or reach all of them.
This exact trait is the main reason pinning often gets removed after the first painful certificate-change incident.
What is done instead and alongside pinning
Several practices reduce the risk without abandoning the idea entirely.
A backup pinned key, added ahead of time, allows the working certificate to be replaced without updating the app — trust holds because one of the pinned options still matches. The lifetime of the pinning itself is limited in time, so an outdated pin does not stay in the app forever. On the domain side, a similarly spirited protection is the CAA record: it limits which certificate authorities are even allowed to issue a certificate for the domain — more detail is in the article CAA DNS record.
When pinning helps and when it hurts
The decision depends on who controls updating the client and how quickly updates reach users.
| App type | How appropriate pinning is |
|---|---|
| A banking or payment mobile app | Appropriate with a working backup key and update control in place |
| A mass consumer app with rare updates | Risky: a mass outage for all users at once |
| An internal client that connects to its own server | Convenient — both sides are controlled by the same team |
| A regular website opened in a browser | Not used: browsers do not support pinning controlled by the site |
Frequently asked questions
What is SSL pinning in simple terms?
It is a way for an app to trust not just any valid certificate, but a specific certificate or server key built into the code ahead of time. Even a formally correct certificate from another source is accepted only if it matches the pinned sample.
Does a regular website need pinning?
No, browsers do not give websites a way to set their own pinning, and a regular site relies on the operating system's standard certificate check. Pinning is used in custom mobile apps and API clients, where the developer controls both the client and the server.
What happens when the certificate is renewed?
If an app pinned the whole certificate or the key, and renewal changed exactly that pinned part, the app will stop connecting to the server for all users at once. A backup pinned key added in advance helps avoid this, since it survives the renewal.
How is pinning different from HSTS?
HSTS forces the browser to reach a site only over a secured connection and refuses attempts to downgrade it to plain HTTP. Pinning is about trusting a specific certificate or key inside an already secured connection, and it is normally used not in a browser but in a separate app.
Conclusion
Pinning is worth adding deliberately and together with a backup key, not by default: the cost of a mistake is a complete app outage for every user at once. What certificate types exist in general is covered in the article types of SSL certificates.