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.
Why This Matters for Security Teams
Certificate pinning is often sold as a straightforward anti-man-in-the-middle control, but that framing misses the operational risk: pinning is a governance choice about how trust will be renewed, not just a code-level hardening step. When teams pin too tightly, they can create self-inflicted outages during routine certificate renewal, CA migration, device replacement, or emergency revocation. That is why the issue sits alongside machine identity lifecycle management, not beside browser hardening.
NHI Management Group research on machine identity failures shows why this matters: in the Critical Gaps in Machine Identity Management report, certificate expiry is the leading cause of outages for 45% of organisations. The same report shows only 38% have automated certificate lifecycle management in place, which makes brittle pinning even harder to sustain. Security teams that treat pinning as a one-time implementation usually discover the failure mode during renewal, not during design.
In practice, many security teams encounter pinning breakage only after an expired certificate or replaced intermediate has already taken production offline.
How It Works in Practice
The security value of pinning depends on what is pinned and how quickly it can be updated. Teams may pin a leaf certificate, an intermediate, a public key, or a trust anchor. The more specific the pin, the more resistant it is to interception, but the more fragile it becomes when certificates rotate. For that reason, current guidance suggests favouring key-based or trust-store-based approaches over hard-coding a single leaf certificate, especially for long-lived clients.
Operationally, strong pinning should be paired with certificate lifecycle controls, not used as a substitute for them. That means inventorying where pins exist, defining who can approve pin changes, and testing rollover before production changes. The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams toward asset visibility, change management, and recovery planning rather than treating trust as static. It also helps to map pinning decisions to the broader machine identity posture described in Ultimate Guide to NHIs, where certificates are only one part of a wider identity lifecycle.
- Pin the least brittle trust object that still meets the threat model.
- Maintain a documented rollover path for every pinned endpoint.
- Automate renewal, validation, and alerting before expiry windows.
- Test emergency rotation so revocation does not become an outage trigger.
The control breaks down in mobile apps, embedded devices, and offline clients because field updates are slow, certificate distribution is inconsistent, and rollback paths are limited.
Common Variations and Edge Cases
Tighter pinning often increases operational overhead, requiring organisations to balance interception resistance against maintenance burden and outage risk. That tradeoff becomes sharper in environments with frequent certificate issuance, multiple CDNs, or third-party APIs where the service owner may rotate intermediates without notice.
There is no universal standard for pinning every client the same way. Browser ecosystems have largely moved away from traditional static pinning because the blast radius of a bad pin was too high, while some embedded and high-assurance systems still use carefully managed pins. Best practice is evolving toward shorter-lived trust relationships, stronger issuance controls, and runtime validation that can be updated without redeploying every client. The Sisense breach is a reminder that identity and secret handling failures often cascade when trust assumptions become stale. For broader NHI governance, the key question is not whether pinning exists, but whether the organisation can survive certificate change without losing availability or weakening assurance.
In highly regulated or safety-critical systems, pinning may still be justified, but only when certificate lifecycle ownership, recovery testing, and exception handling are explicitly documented.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Pinning failures often stem from weak certificate lifecycle control. |
| NIST CSF 2.0 | PR.AC-4 | Trust enforcement depends on controlling and reviewing identity-related access paths. |
| NIST AI RMF | Governance and lifecycle oversight are needed for trust decisions with operational impact. |
Inventory pinned certificates and automate rotation before expiry or planned trust changes.
Related resources from NHI Mgmt Group
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
