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.
Expanded Definition
Certificate pinning is a connection trust control that narrows acceptable server identity to a known certificate, public key, or certificate authority path. In NHI and application security, it is used to reduce the chance that a client will trust an unexpected certificate during TLS negotiation, especially where interception risk or trust-store compromise is a concern. The control is closely related to transport trust and identity binding, but it is not the same as general TLS validation. Standard guidance varies across vendors and implementation patterns, so the exact pinning scope, rotation strategy, and fallback behavior should be documented explicitly rather than assumed.
For a broader identity governance context, pinning should be understood alongside the lifecycle issues described in the Ultimate Guide to NHIs — What are Non-Human Identities and the control expectations reflected in the NIST Cybersecurity Framework 2.0. The most common misapplication is pinning an entire certificate with no rotation plan, which occurs when teams hard-code trust anchors and then fail to update clients before renewal or revocation events.
Examples and Use Cases
Implementing certificate pinning rigorously often introduces operational fragility, requiring organisations to weigh tighter trust enforcement against the cost of certificate rotation failures and emergency client updates.
- Mobile apps pin a backend public key so that a stolen or rogue CA certificate does not silently expand trust to an impostor endpoint.
- Service-to-service clients pin an expected certificate chain for an internal API, while still coordinating renewal windows with platform teams.
- High-risk administrative tools pin the certificate of a sensitive management endpoint to reduce exposure during certificate-store compromise.
- Security teams compare pinning outcomes with machine identity lessons from the Critical Gaps in Machine Identity Management report, especially where certificate lifecycle discipline is weak.
- Network defenders align pinning decisions with transport assurance expectations in the NIST Cybersecurity Framework 2.0, particularly when controlling trusted channels for sensitive workloads.
In practice, teams often choose public-key pinning rather than whole-certificate pinning when they expect certificate renewal but want a stable cryptographic trust anchor. Others restrict pinning to narrow use cases such as mobile clients, embedded devices, or privileged tooling where the client population is tightly managed. The key decision is whether the security benefit justifies the recovery burden if a certificate is rotated unexpectedly.
Why It Matters in NHI Security
Certificate pinning matters because NHI environments depend on machine-to-machine trust that must survive renewal, revocation, and infrastructure change. When pinning is too rigid, a routine certificate update can break service authentication and interrupt workloads. When it is too loose, the client may accept certificates that undermine the intended trust boundary. NHI governance must therefore treat pinning as part of the broader certificate lifecycle, not as a one-time hardening step. This is especially important given NHIMG research showing that Only 38% have automated certificate lifecycle management in place, which increases the chance that pinned trust will fail during renewal events. The issue also intersects with secrets and workload identity practices described in the Ultimate Guide to NHIs — What are Non-Human Identities, where rotation and visibility are recurring control gaps.
Organisations typically encounter the consequences only after a certificate expiration, unexpected revocation, or endpoint migration, at which point certificate pinning becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers certificate and secret lifecycle weaknesses that pinning can amplify. |
| NIST CSF 2.0 | PR.DS-2 | Addresses data in transit protections where certificate trust controls apply. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust requires explicit trust decisions for workload connections and identities. |
Treat pinned certificates as governed NHI assets and rehearse rotation before deployment.
Related resources from NHI Mgmt Group
- How should teams manage shrinking certificate lifecycles in NHI environments?
- What is the difference between certificate management and NHI governance?
- Should organisations treat certificate expiry as an operational risk or a security risk?
- How should security teams govern certificate lifecycles across hybrid environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
