Pin only if you control both the app and the server, can update the pins without a painful app release, and face a threat that normal certificate checks do not cover. The OWASP Pinning Cheat Sheet says there is almost no situation where you should consider it, because outage risk usually outweighs the benefit.
What pinning does
Pinning ties a host to an expected certificate or public key. When the app connects, it compares what the server presents with the stored pin and refuses to continue on a mismatch. A set of acceptable pins is called a pinset.
OWASP describes two attacker cases pinning addresses: someone gets a rogue certificate for your domain from a trusted certificate authority, or someone injects a malicious authority into the device's trust store. It also notes that an attacker who can alter the trust store may be able to change the app itself, potentially defeating pinning.
When not to pin
The OWASP cheat sheet gives a blunt list. Do not pin if:
- you do not control both the client and the server side of the connection
- you cannot update the pinset securely
- updating the pinset is disruptive, for example it needs an app redeployment, unless you control forced updates
- you cannot predict the certificate key pair before it goes into service
- it is not a native mobile application
Most consumer apps fail at least one of these. An app in the store may stay on an old version for months, so a rotated certificate can break every user who has not updated.
When pinning can make sense
Pinning is easier to defend when the app talks to one backend you run, you can force upgrades, the data is high value, and you have a rehearsed process for rotating keys. A banking style app that can enforce a minimum version is a typical fit. Even then you need backup pins, expiry planning and monitoring for pin failures.
A decision table
| Situation | Suggested choice |
|---|---|
| App talks to many third party hosts you do not control | Do not pin those hosts |
| Single owned backend, forced updates possible | Consider pinning with backup pins |
| Single owned backend, no forced updates | Lean towards not pinning |
| Web app or hybrid web view | Do not pin, it is not a native mobile app |
| Corporate network with an inspecting proxy | Plan for a documented, approved exception |
| Short lived certificates and fast rotation | Pin public keys rather than whole certificates, or skip |
What to do instead of, or alongside, pinning
Pinning is one layer. Strong baseline TLS, correct certificate validation and short token lifetimes carry most of the weight. On iOS, App Transport Security already requires HTTPS and enforces minimum TLS and certificate standards by default. Add server side controls that do not depend on the client, since attackers can modify the client.
If you decide to pin, treat it as an operational commitment. Put pin expiry dates in a calendar, test the failure path in a staging build, and keep a documented rollback.
Related reading
- Android certificate pinning expiry and backup pins
- HTTP public key pinning, RFC 7469 and the lessons on pinning risk
Safeguard's SBOM and dependency scanning covers the networking libraries inside your app, so you know which one makes the connections you are thinking about pinning. A free scan is available at gold.safeguard.sh/scan.
Quick check
Does pinning replace normal certificate validation?
No. Pinning adds an extra check on top of the standard validation the platform already performs.
Should users be allowed to click past a pin failure?
OWASP advises against it, noting that users will click past warnings. If your threat model needs pinning, do not offer a bypass.
Sources
Last reviewed: 19 October 2026.
