Certificate Pinning: A CTO's Decision Framework

Part of the Machine Identity Management guide.

The Executive Summary You Need Before the Architecture Review

Certificate pinning is a security control that restricts which TLS certificates your applications will accept. Instead of trusting the entire public certificate authority system, pinned applications trust only specific certificates or keys that you've pre-approved.

The security benefit is real: pinning protects against compromised certificate authorities, man-in-the-middle interception, and certain classes of supply chain attack. The problem is that pinning also introduces operational fragility that, in the wrong context, creates more downtime risk than the threats it mitigates.

This isn't a question your security team can answer in isolation. It's a business decision about where your risk tolerance sits on the spectrum between “vulnerable to CA compromise” and “vulnerable to self-inflicted outages.”

The Core Trade-Off

Pinning reduces your exposure to external certificate trust failures (a CA gets compromised, a government compels certificate issuance, an attacker obtains a fraudulent certificate).

Pinning increases your exposure to internal operational failures (a certificate rotates without updating the pins, a CA migration breaks all pinned clients, an emergency re-issuance locks out your own users).

For most organisations, the external threats are low-probability, high-impact events. The internal operational failures are high-probability, high-impact events — especially if your certificate lifecycle management isn't fully automated.

The honest question: Is your certificate operations mature enough that adding pinning won't create more incidents than it prevents?

Decision Matrix by Application Type

Mobile Applications — Usually Yes

Why it fits: You control the client binary. You control the API it connects to. You have an update mechanism (app store releases). The threat model is strong — users connect from untrusted networks, compromised Wi-Fi, and devices with modified trust stores.

Business case: If your mobile app handles financial transactions, health data, authentication tokens, or any regulated data category, pinning is a defensible and often expected control. Auditors and regulators view mobile pinning favourably.

The catch: Your pin update cycle is gated by app store review times (hours to days) and user update behaviour (weeks to months). If you need to change pins faster than your slowest user updates, you need a remote pin configuration mechanism — which adds infrastructure complexity.

Recommendation: Implement pinning for mobile apps that handle sensitive data. Pin at the CA level (not the individual certificate) and build a remote configuration fallback from day one. Budget for the engineering work to get this right — retrofitting a remote pin update after an incident is significantly more expensive.

Web Applications (Browser-Based) — No

Why it doesn't fit: Browsers removed support for HTTP Public Key Pinning (HPKP) in 2018 after widespread incidents where misconfigured pins locked users out of websites for extended periods. There is no browser-native pinning mechanism available today.

What to do instead: Rely on Certificate Transparency monitoring. Every publicly-trusted certificate is logged in public, auditable records. Set up monitoring to alert you if an unexpected certificate appears for your domains. Combine this with CAA (Certificate Authority Authorisation) DNS records to restrict which CAs can issue certificates for your domains.

Business case: These alternatives provide detection and prevention without any risk of self-inflicted lockout. For web applications, this is the correct trade-off.

Internal Service-to-Service APIs — Depends on Your Infrastructure Maturity

Why it might fit: In a microservices or zero trust architecture, services authenticate each other using mutual TLS. Pinning the internal CA or specific service identities adds defence-in-depth against an attacker who has gained network access but hasn't compromised your internal CA.

Why it might not fit: If you're running an internal PKI with automated certificate issuance (HashiCorp Vault, AWS Private CA, or similar), the certificates are already scoped and short-lived. Pinning adds value only if you're concerned about a scenario where the attacker has compromised network access and can present a certificate from a CA you don't control — which, in an internal environment using a private CA, requires the attacker to have modified the service's trust configuration.

Recommendation: If your internal services already use mutual TLS with a private CA and short-lived certificates (hours to days), the marginal security benefit of pinning is small relative to the operational complexity. If your internal certificates are long-lived and issued by a public CA, pinning at the CA level is worth considering — but the better investment is migrating to a private CA with automated short-lived issuance.

IoT and Embedded Devices — Yes, but Only with Remote Update Capability

Why it fits: IoT devices operate in physically untrusted environments, connect over networks you don't control, and are high-value targets for interception (industrial control systems, medical devices, payment terminals).

The critical business constraint: Unlike mobile apps, IoT devices often can't be updated quickly — or at all, in some cases. If your device's pin configuration is baked into firmware that requires a physical service visit to update, pinning is a time bomb. You will eventually need to rotate the pinned certificates or keys, and when that day arrives, every device with outdated pins becomes non-functional.

Recommendation: Implement pinning only if you have a verified, tested, reliable over-the-air (OTA) pin update mechanism. The engineering cost of building this is significant but non-negotiable. If OTA updates aren't feasible for your device category, invest in other controls — mutual TLS with a private CA, device attestation, or network-level segmentation — rather than pinning.

Third-Party API Integrations — Rarely

Why it's tempting: You connect to a payment processor, banking API, or regulatory endpoint. Pinning their certificate protects against a compromised CA issuing a fake certificate for their domain.

Why it's usually wrong: You don't control their certificate lifecycle. Payment processors change CAs. Banking platforms rotate certificates on schedules they don't publish. Regulatory systems get migrated to new infrastructure. Every one of these events breaks your pinned integration.

The business cost: A broken payment integration is a revenue-stopping event. The security scenario you're protecting against (a targeted CA compromise aimed at intercepting your specific API traffic) is orders of magnitude less likely than the operational scenario (your partner rotates certificates and doesn't give you advance notice).

Recommendation: Don't pin third-party API certificates unless the partner explicitly supports it with published pin sets and committed advance notification of changes. This is rare. For most integrations, CT monitoring and standard TLS validation provide sufficient security without the operational coupling.

Desktop Applications — Case by Case

Why it's complicated: Desktop applications sit between mobile (where you control the binary) and web (where you don't control the trust store). You distribute the application, but users install it on machines with varying configurations, and your update mechanism may or may not be reliable.

Recommendation: If the application connects exclusively to your infrastructure and you have a mandatory auto-update mechanism, treat it like a mobile app — pinning is viable. If users can defer updates or the application connects to multiple third-party services, the operational risk typically outweighs the security benefit.

The Questions to Ask Your Engineering Team

Before approving or rejecting a pinning proposal, these are the questions that determine whether it will work:

1. How fast can we push updated pins to 95% of clients? If the answer is “hours,” pinning is operationally viable. If the answer is “weeks” or “it depends on user behaviour,” you need a remote configuration mechanism or you shouldn't pin.

2. What happens if we need to change CAs with 24 hours' notice? CA incidents happen. Symantec was distrusted over 18 months. Others have had shorter disruptions. If your pinning locks you to one CA with no backup, you've traded a security control for a vendor dependency with no escape hatch.

3. Do we have pin failure telemetry? If a pinning check fails, does the client report it? Without telemetry, the first sign of a pinning problem is user-reported outages. With telemetry, you catch misconfigurations during staged rollouts before they reach all users.

4. Is this documented in our incident runbooks? Certificate rotation, CA migration, and emergency re-issuance should all have documented procedures that account for pinning. If “update the pins” isn't in the runbook, it won't happen smoothly when it needs to.

5. Who owns the pin configuration lifecycle? Pinning that's set up by one team and forgotten is pinning that will cause an incident. There needs to be an explicit owner who reviews pin configurations during every certificate or CA change.

The Cost Equation

Implementing pinning correctly isn't free. Budget for:

• Initial implementation: Engineering time to add pinning to clients, build pin configuration management, implement telemetry. Typically 2–4 weeks of engineering effort for a mobile app.
• Remote pin update infrastructure: If required, a secure configuration service that can push pin updates to clients without a full application release. This is a separate system that needs its own availability guarantees.
• Ongoing operational cost: Every certificate rotation, CA change, or infrastructure migration now has an additional step. Multiply by the number of pinned clients.
• Incident response complexity: Certificate-related incidents now require coordinating pin updates across client populations. This adds time to your incident resolution.

For mobile apps handling sensitive data, this cost is justified. For most other application types, the same engineering investment in automated certificate lifecycle management delivers better security outcomes with lower operational risk.

The Recommendation

Pin when you control both endpoints, have a reliable update mechanism, and handle data sensitive enough to justify the operational overhead. For everything else, invest in Certificate Transparency monitoring, CAA records, and automated certificate lifecycle management — these provide strong security without the fragility.

The organisations that get pinning right are the ones that have already solved certificate automation. Pinning on top of mature automation is a reasonable defence-in-depth measure. Pinning on top of manual certificate management is a future outage.

Pinning decisions are downstream of certificate lifecycle maturity. If you're evaluating your organisation's readiness, start with an infrastructure assessment.