Certificate pinning is a trust control with more risk than reward

At a glance

What this is: This is an analysis of certificate pinning and why it often breaks the ability to recover safely when certificate trust changes.

Why it matters: It matters because IAM, NHI, and platform teams all depend on certificate lifecycle flexibility, and brittle trust controls can turn routine revocation or rotation into an outage event.

By the numbers:

• Only 38% have automated certificate lifecycle management in place.

👉 Read DigiCert's analysis of why certificate pinning creates recovery risk

Context

Certificate pinning is a trust control that restricts which certificate authorities, public keys, or end-entity certificates a client will accept. It is meant to reduce the risk of misissuance, CA compromise, and man-in-the-middle attacks, but it also hard-codes trust assumptions into software and devices that may need to change later.

For identity and access teams, the real issue is lifecycle resilience. Certificates, issuers, and trust stores change over time, and pinning can make ordinary rotation or revocation unusually difficult across workloads, applications, and devices. That puts certificate governance in direct tension with operational continuity.

Key questions

Q: What breaks when certificate pinning is not paired with a recovery path?

A: The biggest failure is that clients can keep rejecting valid replacement certificates after revocation, issuer changes, or key compromise. That turns a routine certificate event into an availability problem. If the pin is widely deployed, the recovery burden shifts from the certificate team to every client, app, or device that recorded the old trust value.

Q: When does certificate pinning create more risk than it reduces?

A: It becomes riskier when the environment changes faster than client updates can be deployed. Public TLS chains, mobile apps, IoT devices, and long-lived software are especially vulnerable because pinned values can outlast safe certificate lifecycles. If replacement is hard, the control is usually too brittle for production use.

Q: What do security teams get wrong about certificate pinning?

A: Teams often treat pinning as a simple hardening layer, when it is really a trust governance decision with operational consequences. The mistake is assuming the pinned value will remain valid for the full lifespan of the application or device. In reality, certificate change is normal, and pinning can make that change difficult to survive.

Q: Who is accountable when a pinned certificate causes an outage?

A: Accountability should sit with the teams that own certificate policy, application release management, and trust-store updates, because pinning crosses all three domains. If the organisation cannot replace certificates quickly, the control design is incomplete. Governance needs to define who can approve changes, test replacements, and retire pinned trust safely.

Technical breakdown

How certificate pinning binds trust to a fixed identity

Certificate pinning works by telling a client to trust only a specific certificate authority, public key, or certificate chain for a given destination. That removes reliance on the full public PKI trust store and narrows the accepted trust path. In practice, the client rejects any certificate that does not match the pre-recorded value, even if the certificate is otherwise valid. This can reduce exposure to rogue issuance or interception, but it also makes trust static at the moment of deployment. Once the pinned value is embedded in code, browser policy, or device firmware, every future certificate change must preserve that exact trust expectation.

Practical implication: Treat pinned trust as a lifecycle dependency, not a one-time hardening choice.

Why pinned certificates become operationally brittle

The brittleness comes from the gap between security intent and real certificate operations. Keys expire, issuers are replaced, revocation happens, and certificate authorities periodically change intermediates or root chains. Pinning reduces the system’s ability to adapt when any of those events occur. If a client only accepts one key and that key is compromised or must be revoked, there may be no safe replacement path unless the client itself is updated. That creates a recovery problem rather than a simple authentication failure. The more widely deployed the pinned trust path is, the harder coordinated remediation becomes.

Practical implication: Assume every pinned trust path will eventually require emergency rework.

Why short-lived intermediates are a governance signal

DigiCert’s move to rotate intermediates more frequently is a response to the governance problems pinning creates. Shorter intermediate lifetimes reduce the incentive to pin those values and limit the blast radius if one issuing chain must be retired. Instead of one long-lived trust anchor affecting many years of issuance, smaller certificate buckets can constrain the operational impact of a change. This is not a cure for certificate risk, but it is a lifecycle design choice that favours replaceability over static trust. That is the more durable pattern for modern certificate governance.

Practical implication: Design trust chains so rotation is expected and survivable.

Threat narrative

Attacker objective: The objective is to force persistent service disruption by making clients refuse all trustworthy replacement certificates.

1. Entry occurs when a client, browser, app, or device records a pinned certificate or public key and begins trusting only that specific identity path.
2. Escalation happens when the pinned key is compromised, the certificate authority must revoke it, or a bogus pin is introduced with a long max-age that outlives safe recovery.
3. Impact is a sustained loss of connectivity because the client continues rejecting valid replacement certificates even after the underlying issue is fixed.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Certificate pinning is a recovery problem disguised as a trust control. The appeal is obvious: reduce the accepted trust surface and block unexpected certificates. The failure is that the control assumes future trust changes can be coordinated everywhere pinning exists. Once that assumption breaks, revocation and reissuance become an availability event, not just a security event. Practitioners should treat pinning as a lifecycle constraint that can outlive the trust it was meant to protect.

Static trust expectations are the wrong default for certificate governance. Public PKI does not behave like a fixed identity registry. Issuers change, lifetimes shrink, and compromised material must be replaced quickly. Pinning hard-codes a trust decision into software that may be deployed for years, which is why it often creates more harm than protection. The better governance question is whether a trust dependency can be rotated without client-wide surgery.

Shorter intermediate lifetimes reduce identity blast radius. DigiCert’s six-month intermediate rotation shows the direction the market is taking: smaller trust epochs and less incentive to lock clients to a single issuer chain. That does not eliminate certificate governance risk, but it makes revocation, deprecation, and issuer change less disruptive. For practitioners, the implication is to prefer trust designs that assume change, not permanence.

Certificate lifecycle management and IAM governance now overlap more than many teams admit. Certificates are credentials, and credentials need ownership, replacement paths, and offboarding logic. When teams do not model certificates as governed identity objects, pinning appears attractive because it promises certainty. In reality, it can create unowned failure states that neither security nor operations can easily unwind. The practical conclusion is that certificate trust policy belongs in lifecycle governance, not just in application code.

From our research:

• Only 38% have automated certificate lifecycle management in place, according to The Critical Gaps in Machine Identity Management report.
• 61% rely on spreadsheets or manual tracking for machine identity management, which helps explain why certificate change events remain operationally fragile.
• For a broader view of lifecycle control gaps, see NHI Lifecycle Management Guide, which connects ownership, rotation, and offboarding into one governance model.

What this signals

Certificate governance is converging with machine identity governance. The operational lesson here is that trust controls fail when they cannot be rotated, replaced, or retired at the speed of change. Teams that still treat certificates as a separate technical domain should expect more overlap between PKI operations, application security, and identity governance over the next cycle.

The practical signal is that replacement-path testing should become a standard part of certificate change control, especially for software with long deployment lifetimes. If a certificate cannot be swapped without touching every client, the trust design is already too rigid for modern operations.

For the broader lifecycle view, the NIST Cybersecurity Framework 2.0 remains useful as a structure for ownership, change management, and recovery, while the OWASP Non-Human Identity Top 10 helps frame credentials as governed identity objects rather than isolated technical artifacts.

For practitioners

• Inventory pinned trust dependencies Identify where public keys, certificate authorities, or end-entity certificates are hard-coded in apps, browsers, firmware, or mobile clients. Document which systems would fail if the issuing chain changed unexpectedly.
• Test certificate replacement paths Run controlled change exercises for revocation, issuer replacement, and intermediate rollover so you know which clients can accept new certificates without redeployment.
• Prefer replaceable trust chains Use trust designs that allow rotation without embedding long-lived pins, and limit the number of systems dependent on any one intermediate or issuer.
• Treat certificate ownership as lifecycle governance Assign clear owners for certificate issuance, rotation, and emergency replacement so no pinned dependency becomes an orphaned control during a change event.

Key takeaways

• Certificate pinning often trades a narrow security benefit for a much larger recovery risk.
• The main failure mode is not misissuance itself, but the inability to replace trust safely when certificates change.
• Practical governance favours rotateable trust chains, clear ownership, and tested replacement paths over static pins.

Key terms

• Certificate Pinning: A trust control that restricts a client to a specific certificate authority, public key, or certificate for a given connection. It can reduce exposure to unexpected certificates, but it also makes trust changes harder because the client may reject valid replacements after rotation or revocation.
• Certificate Lifecycle Management: The governance process for issuing, rotating, renewing, revoking, and retiring certificates across applications and devices. In practice, it determines whether trust can change safely without breaking service, which makes it a core operational discipline rather than a back-office PKI task.
• Trust Anchor: The root or intermediate certificate that a client uses as the basis for validating other certificates. When trust anchors are pinned or otherwise fixed too tightly, they can become a source of outage if the issuer changes or must be replaced quickly.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or operational resilience, it is worth exploring.

This post draws on content published by DigiCert: Stop Certificate Pinning. Read the original.