Notifications
Clear all
Topic starter
12/07/2026 12:18 pm
TL;DR: Cryptographic key security depends on lifecycle control, access restriction, rotation, revocation, backup, and auditability, according to GlobalSign’s guide to PKI key management. The governance gap is not encryption strength alone, but whether organisations can prove who can use each key, for how long, and how quickly compromised material is removed from service.
NHIMG editorial — based on content published by GlobalSign: 8 best practices for cryptographic key management
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Questions worth separating out
Q: What breaks when cryptographic key lifecycle management is not in place?
A: Without lifecycle management, keys become long-lived trust anchors with no reliable expiry, revocation, or ownership discipline.
Q: Why do cryptographic keys need governance similar to non-human identities?
A: Cryptographic keys function like non-human identities because they authenticate systems, enable privileged actions, and often outlive the humans who created them.
Q: How do security teams know whether key rotation is actually reducing risk?
A: Rotation is working when compromised or stale keys can no longer be used, the replacement process is documented, and revocation is measurable across the estate.
Practitioner guidance
- Centralise key lifecycle ownership Assign one accountable owner for key creation, renewal, rotation, revocation, and deletion so lifecycle decisions do not drift across PKI, platform, and security teams.
- Restrict vault access to named roles Limit cryptographic vault access to specific operational roles, log every administrative action, and review access on a fixed schedule to prevent broad standing access.
- Tie rotation to revocation triggers Define clear triggers for emergency revocation, then pair them with tested recovery procedures so compromised keys can be removed without breaking business-critical services.
What's in the full article
GlobalSign's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on centralising key management so manual spreadsheet tracking does not become the control record.
- Practical discussion of algorithm and key-size selection, including why 2048-bit RSA remains a baseline reference point.
- Specific recommendations for secure vaulting, backup, recovery, and revocation workflows across key types.
- The article's own framing of certificate trust and CA/B forum practices that support the wider PKI trust model.
👉 Read GlobalSign’s guide to cryptographic key lifecycle management and PKI trust →
Cryptographic key lifecycle management: are your PKI controls keeping up?
Explore further
12/07/2026 12:32 pm
Cryptographic keys should be governed as non-human identities, not static infrastructure artefacts. The article makes clear that a key is issued, stored, used, rotated, revoked, and audited in a lifecycle that looks very similar to service accounts and tokens. That means PKI governance and NHI governance are converging on the same control problem: proving access scope and proving removal. Practitioners should manage keys with the same lifecycle discipline they apply to privileged machine identities.
A question worth separating out:
Q: Who should be accountable for revoked or expired keys in PKI programmes?
A: Accountability should sit with the team that owns the key lifecycle, not only the platform that stores the key. In practice that means clear ownership for creation, renewal, rotation, revocation, and audit, plus control evidence for security and compliance teams. If no one owns removal, expired trust persists longer than intended.
👉 Read our full editorial: Cryptographic key lifecycle management is the real PKI control gap
