What are the key certificate pinning best practices?

What certificate pinning is trying to protect

certificate pinning is a client-side trust decision, not just a transport setting. The client is told to accept only a known public key or certificate set, which can reduce exposure to hostile trust anchors, some interception patterns, and unexpected certificate substitution. That protection only works if the application owner can control updates, revocation handling, and recovery when the server certificate changes.

For mobile and distributed clients, the strongest fit is usually a Mobile App Security Guide style implementation where trust decisions, key storage, and app release handling are already under product control. When pinning is used in environments that also rely on service-to-service trust, Guide to SPIFFE and SPIRE is a useful adjacent model because it shows how certificate-bearing identities are rotated and validated as part of a managed trust system.

Good pinning practice is therefore about narrowing trust without creating a brittle single point of failure. A pinned client should still be able to survive routine certificate renewal, CA changes, backend migration, or emergency key replacement without bricking connectivity.

How to pin without creating an outage

The practical rule is to pin to a public key or to a small, preplanned set of acceptable certificates, not to one exact leaf certificate. That approach preserves continuity during normal renewal and avoids forcing an emergency app update every time the certificate changes. It also makes recovery possible if the original certificate is compromised, revoked, or replaced.

Pinning works best when certificate lifecycle handling is already deliberate. The Machine Identity, PKI and Certificate Lifecycle Guide is the right companion for understanding why rotation, expiry management, and crypto agility matter when certificates function as machine identities. For organisations that want a more formal key-lifecycle view, NIST SP 800-57 Key Management frames the same problem as a lifecycle control issue, not a one-time configuration choice.

Operationally, the safest design is to publish a pin set with overlap, test it in preproduction, and ensure the client can accept a new certificate before the old one is retired. That gives you a migration window instead of a hard cutover.

What to monitor and prepare before you ship

Pinning should be monitored like an availability control as much as a security control. Failed handshakes, spikes in TLS errors, and unexpected certificate expiry or replacement events should be visible quickly, because a pin mismatch can look identical to a genuine attack from the client’s point of view. If the application is customer-facing or high-availability, you also need a documented rollback path and a way to disable or update pins safely.

Certificate issuance and rotation norms matter here, especially for public trust. The CA/Browser Forum is the reference point for public certificate baseline expectations, so it is sensible to align pinning assumptions with how public TLS certificates are actually issued and renewed. Where pinning is part of a broader API client trust model, RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens shows the related pattern of binding access to certificate-backed client identity.

In practice, teams that do not rehearse certificate rollover often discover the pin only when production traffic fails. The control is only safe if you can prove that a replacement certificate will be accepted before the current one expires.

Risk and Threat Considerations

Pinning reduces some trust-impersonation risk, but it also raises the operational cost of mistakes. A bad pin, an unplanned certificate change, or a broken recovery path can turn a security control into an outage trigger, especially when multiple client versions are in the wild.

Failure mechanism: The client rejects all TLS sessions that do not match the pinned value, so normal rotation, CA change, or emergency replacement fails unless the application already trusts the new key or certificate set.

Impact: Users can lose connectivity immediately, incident response can be slowed, and a rushed fix can weaken trust controls more than the original problem.

Practitioner Guidance

What to prioritise: Treat pinning as a lifecycle control first and an anti-interception control second. The first question is whether you can reliably distribute and recover pins across all client versions you already have in the field.

What to verify: Confirm that the client accepts the next certificate before the current one is retired, that the fallback process is tested, and that failed handshakes are observable from day one. If those conditions are missing, pinning is too risky to tighten further.

Common mistake: Hard-coding a single leaf certificate and assuming rotation will be “handled later” is the fastest way to convert routine maintenance into a production incident.

Practitioner takeaway: Good pinning limits trust exposure only when the organisation can also prove certificate continuity, rotation readiness, and safe recovery under failure.

Related resources from NHI Mgmt Group

• What are the key Configuration Assessment best practices?
• What are the key Memorized secret best practices?
• What are the key Container Image Analysis best practices?
• What are the key application security testing best practices?