Public key pinning

Expanded Definition

Public key pinning is a trust restriction that binds a domain to a known certificate authority chain, public key, or key hash so the client will reject unexpected certificates. In NHI and agentic systems, the practical goal is to reduce the chance that a browser, API client, or embedded runtime accepts a fraudulent certificate during TLS negotiation. The concept is closely related to transport trust and certificate lifecycle control, but it is not the same as certificate validation alone. Validation checks whether a certificate is technically valid; pinning narrows what is considered valid for a specific destination.

Industry usage has shifted over time. Browser-level pinning has largely fallen out of favor in the broader web ecosystem because operational mistakes can lock out legitimate users when certificates rotate or intermediates change. That tradeoff is why guidance varies across vendors and platforms. For identity-sensitive services, the safer pattern is often to prefer managed trust stores, strong certificate governance, and monitoring aligned with NIST Cybersecurity Framework 2.0 rather than brittle hard-coding. The most common misapplication is pinning too rigidly to a leaf certificate, which occurs when teams rotate keys or reissue certificates without updating every dependent client.

Examples and Use Cases

Implementing public key pinning rigorously often introduces availability risk, requiring organisations to weigh stronger anti-spoofing assurance against the possibility of self-inflicted outages during certificate rotation.

• Mobile applications pin an API gateway certificate or public key to reduce exposure to enterprise Wi-Fi interception and rogue trust anchors.
• Internal service-to-service clients pin a known CA hierarchy when a narrow set of backend endpoints must be protected from unexpected certificate changes.
• Embedded agents used in NHI workflows pin a management endpoint so token exchange and control-plane traffic cannot be redirected silently.
• Security teams compare pinning against broader NHI lifecycle controls described in the Ultimate Guide to NHIs, especially where certificates back service accounts or automated workloads.
• Operators use pinning during high-risk migrations, then phase it out once certificate issuance, inventory, and revocation handling are stable and observable.

For implementation detail, organisations often pair pinning decisions with the trust concepts described in the IETF's RFC 7469, while treating the mechanism as one option among several rather than a universal default.

Why It Matters in NHI Security

Public key pinning matters because NHI environments depend on automated trust decisions at machine speed. If a service, bot, or agent accepts the wrong certificate, attackers can intercept token exchange, tamper with API calls, or impersonate infrastructure endpoints that hold secrets. The risk is amplified where secrets, certificates, and service identities are already difficult to inventory. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and 71% of NHIs are not rotated within recommended time frames, making certificate and key governance especially fragile in practice.

That operational fragility is why pinning should be evaluated alongside identity governance, not as a standalone safeguard. The strongest use cases are narrow, controlled, and observable, with rollback paths for failed rotations and certificate replacement. The Ultimate Guide to NHIs frames this as a lifecycle issue, not just a transport issue, because trust controls break when inventory, rotation, and offboarding are incomplete. Organisations typically encounter the consequences after a certificate renewal or trust-store change causes automated workloads to fail, at which point public key pinning becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between private key encryption and public key encryption for practitioners?
• How should security teams govern public key vs private key management at scale?
• Recipient Public Key
• Public-Key Cryptography