Certificate pinning fits when an app talks to servers you control, carries data worth intercepting and has a team that can plan certificate changes. It makes the app trust only the keys you declared for those domains, so connections through a proxy, an added trust anchor or a mis-issued certificate are refused for those domains. The risk is an outage when a certificate changes. Otukan pins selected domains, ships backup keys and an expiry policy from the first release, rehearses rotation with your team and detects attempts to switch pinning off. Pinning is one layer, not a full network security design.
When pinning fits
Platform guidance
Android’s developer guidance warns against routine pinning because an unplanned certificate change can lock out installed apps. On Android, apps targeting recent platform versions already ignore user-added certificate authorities unless they opt in, which removes one common interception route. On iOS, a user can install a configuration profile and explicitly trust its root, and apps can declare pinned keys for chosen domains. Otukan configures each platform on its own terms.
Threat model
Pinning earns its place when the attacker is on the network path or has convinced the user to trust a new root, and the traffic carries credentials, payment data or account changes. It adds little when the endpoint belongs to a third party whose certificates you cannot track.
Alternatives and companions
| Situation | Better fit | Why |
|---|---|---|
| Endpoints you own, high-value traffic | Public-key pinning with backup keys | Strong control over which server the app trusts |
| Third-party endpoints you do not manage | Standard TLS validation | You cannot plan their certificate changes |
| Worry about scripts calling your API directly | App attestation and API signals | Pinning does not prove the caller is your app |
| Worry about a tampered app removing checks | Runtime integrity | Pinning inside a modified app can be removed |
Network interception more broadly is covered on man-in-the-middle attack prevention.
Pin lifecycle
An outage from pinning is almost always a lifecycle failure. Otukan treats the lifecycle as part of the feature.
- Primary and backup keys. Every pinned domain has at least one standby key held separately, so a compromised or expiring key has a ready replacement.
- Rotation. Your certificate owner moves to a backup key; installed apps keep connecting, and the next release adds a new standby.
- Expiry. The pin set carries an expiry policy, so an app that is never updated does not stay locked to keys from years ago.
- Recovery. A written plan covers the case where every declared key must change, agreed before the first release.
- Rehearsal. A rotation is tested in a non-production environment before the pinned build ships.
Who owns what
Pinning outages usually start with a handover gap: the mobile team ships pins, while a platform or infrastructure team renews certificates on its own schedule. Otukan’s rollout names both owners from the start. The certificate owner confirms which keys are primary and which are standby, and agrees to warn the mobile team before any key change. The mobile team confirms which app versions carry which pin set. Pin mismatch reports then go to both teams, so an unexpected change is noticed by the people who can fix it, not by users who cannot sign in. Frameworks add one more question. Flutter and React Native apps often use their own networking layers, so Otukan confirms that pinning covers the path each framework actually uses on each platform.
For the step-by-step procedure, see the certificate pinning rotation guide.
Three separate checks
Pinning is often confused with checks that sit next to it. Keeping them apart makes each one easier to reason about.
| Check | Question it answers | Where it runs | What defeats it on its own |
|---|---|---|---|
| TLS validation | Is the certificate valid for this host and accepted by the platform? | Operating system network stack | A trusted but hostile root on the device |
| Pinning | Is this the key I declared for this domain? | App, for pinned domains | Code in a modified app that disables the check |
| Runtime integrity | Is the app running as shipped, without hooks or patches? | App, reported to your backend | An attacker hiding hooks on a device they control, which is why your server weighs the signal with others |
Used together, validation confirms the chain, pinning confirms the server and runtime integrity confirms the pin check itself is still in place. Pinning sits alongside the other controls covered on mobile app security.