The safest approach is to pin the public key rather than a single leaf certificate when server certificates change regularly. That lets teams renew certificates without forcing an app update every time. Include backup keys, test the pinning path in staging, and plan a controlled rollout so availability does not suffer when the server chain changes.
How to pin for stability, not fragility
Certificate pinning works best when it anchors trust to something that survives normal renewal. Pinning a public key, or a small set of approved keys, avoids tying the app to one leaf certificate that will eventually rotate. That gives teams room to renew chains, change intermediates, or move between certificate authorities without turning every server-side change into an app emergency.
The practical trade-off is that stronger pinning narrows the failure window but raises the cost of bad change management. Teams should treat pin material as part of release engineering, not a one-time security setting. For mobile apps, the useful question is not just “is the connection pinned?” but “can the app still connect after the next legitimate certificate lifecycle event?”
Design the pin set for controlled change
A resilient pinning design usually includes more than one trusted key path. A backup pin lets you introduce a replacement certificate or key without breaking clients that have not yet updated. It also reduces the chance that a single operational mistake, such as an unexpected reissue or CA change, becomes a production outage.
Teams should prefer a pinning model that can be updated through a planned app release, with a clear overlap period where old and new pins both work. This is especially important when the server chain changes regularly, because a pinning scheme that assumes long-lived server certificates will eventually become a support burden.
- Pin at the key or SPKI level where possible, rather than hard-coding one leaf certificate.
- Keep at least one backup pin that is already tested against staging and pre-production.
- Document the exact event that triggers a pin update, such as CA migration, key rollover, or certificate reissuance.
How to test pinning without surprising users
Pinning failures are easy to miss until a real certificate change lands in production. The safest way to avoid that is to exercise the full pinning path in staging, including the planned renewal workflow, the app’s fallback behaviour, and any offline or retry logic. That test should prove both that the app rejects untrusted certificates and that it accepts the new legitimate chain during the intended cutover.
Staged testing also helps teams spot hidden dependencies, such as pinned intermediates, network libraries with their own trust logic, or platform settings that behave differently across iOS and Android. A pinning implementation can look correct in code and still fail when the server chain is rebuilt or the TLS termination path changes.
- Validate the exact certificate chain the app will see in production, not just the chain you expect from the CA.
- Test rollout with a subset of users or environments before broad deployment.
- Verify that monitoring catches both pin failures and successful fallback to the new key path.
When certificate changes are legitimate, availability is the first risk
Certificate pinning can turn a normal lifecycle event into an outage if the app trusts only one exact certificate. That is why controlled rollout matters: the goal is to preserve security while keeping availability intact when the server chain changes. For teams that manage mobile clients at scale, the main operational danger is not an attacker bypassing pinning, but an overly rigid implementation blocking legitimate service access.
Planning for certificate rotation also means deciding how the app behaves during transition. If the new server certificate is live before the app update reaches everyone, the app must still connect safely. If the app update arrives first, the server must continue to support the current pin set until the old client population has aged out.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-57 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V12 — Secure Communication | Certificate pinning is a mobile transport trust control that affects TLS validation. |
| Recommendation — Validate server certificates and pinning behaviour in the secure communication test path. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Pinned keys and certificate material are trust material whose mishandling breaks mobile trust. |
| Recommendation — Protect pin material and rotate it through controlled, tested change windows. | ||
| NIST SP 800-57 | Key Management | The question centers on key rotation and lifecycle planning for stable trust. |
| Recommendation — Plan key rollover and overlap periods so renewed certificates do not break clients. | ||
| NIST SP 800-53 Rev 5 | SC-17 — Public Key Infrastructure Certificates | Certificate-based trust and validation are directly involved in pinning and renewal. |
| Recommendation — Use certificate lifecycle controls that preserve trusted paths during renewal. | ||
Practitioner Guidance
What to verify: Confirm that the app validates the intended chain in staging, accepts the next approved key during overlap, and fails closed only when the certificate is truly untrusted. If your pinning logic cannot tolerate a routine renewal event, the design is too brittle for production.
Implementation sequence: Introduce the backup pin, test the new chain in a non-production environment, publish the app update with both pins active, then retire the old pin only after telemetry shows the updated client base is stable. Keep server and mobile release ownership aligned so neither side breaks the other’s timeline.
Practitioner takeaway: Good pinning protects against interception without making certificate lifecycle management impossible. If you cannot rotate keys and certificates safely, you have not designed pinning, you have created an availability dependency.
Related resources from NHI Mgmt Group
- Guide: Mobile App Security Testing Guide
- How should mobile app teams implement Scoped Storage without breaking legitimate file workflows?
- How should mobile app teams implement obfuscation to make reverse engineering harder without breaking app behaviour?
- How should security teams apply mobile app controls without breaking legitimate access?
- How should organisations implement DMARC without breaking legitimate mail flow?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org