Notifications
Clear all
Topic starter
11/07/2026 8:34 pm
TL;DR: Enterprises still treat key management as a deployment task, but keys are living credentials that must be created, rotated, revoked, and audited across their full lifecycle, according to eMudhra’s analysis. Static governance leaves encryption, PKI, and identity controls exposed to drift, privilege creep, and audit failure.
NHIMG editorial — based on content published by eMudhra: Why enterprises fail at key management and how to fix it
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
A: Teams should govern cryptographic material as an identity asset, not as a standalone technical control.
Q: Why do fragmented key stores create so much security risk?
A: Fragmentation breaks visibility and weakens accountability.
Q: What do teams get wrong about key rotation and revocation?
A: They often treat both as after-the-fact maintenance rather than built-in governance.
Practitioner guidance
- Inventory every cryptographic key class Build a single register for application keys, signing keys, API keys, and certificates, then reconcile it against cloud accounts, CI/CD systems, and application owners on a continuous basis.
- Move rotation and revocation into lifecycle policy Define rotation intervals, revocation triggers, and archival rules for each key type, then automate those events so they occur without relying on manual follow-up.
- Separate key administration from key usage Assign distinct roles for creating, rotating, exporting, and using keys, and require approvals for high-risk actions so no one identity can both administer and consume the same trust material.
What's in the full article
eMudhra's full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step breakdown of key-management mistakes across lifecycle, storage, integration, RBAC, and automation.
- Specific examples of how scattered keys appear in cloud accounts, databases, and application environments.
- Operational guidance on centralising key governance across hybrid and multi-cloud estates.
- The article's own framing of how digital trust changes when key management is treated as a business enabler.
👉 Read eMudhra's analysis of key management mistakes and lifecycle controls →
Key management lifecycle gaps: what IAM teams need to fix?
Explore further
11/07/2026 9:01 pm
Key management should be treated as NHI governance, not as a one-time deployment task. The article is right to frame keys as living assets because creation, rotation, revocation, and archival are lifecycle controls, not setup steps. That is the same governance pattern identity teams already apply to service accounts and other non-human identities. The practical implication is that key management belongs in continuous lifecycle governance, not in a finished-project mindset.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
A question worth separating out:
Q: Who should be accountable for key management failures?
A: Accountability should sit with the system or service owner, supported by IAM, PKI, and security operations. The failure is rarely just technical. It is a governance issue when no one owns the inventory, no one validates rotation, and no one can prove who used a key and why.
👉 Read our full editorial: Enterprise key management fails when lifecycle governance is static
