Notifications
Clear all
Topic starter
11/07/2026 1:59 pm
TL;DR: Encryption is now standard across cloud, APIs, backups, and databases, but the article argues that weak key management leaves the trust layer exposed because attackers steal or abuse keys rather than break cryptography, according to eMudhra. The governing problem is lifecycle control, not algorithm strength, and that makes identity, access, rotation, and revocation the decisive controls.
NHIMG editorial — based on content published by eMudhra: encryption key management and the trust layer in 2026
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
Questions worth separating out
Q: How should security teams manage encryption keys in cloud environments?
A: Security teams should treat encryption keys as privileged assets with clear ownership, least-privilege access, automated rotation, and immediate revocation paths.
Q: Why do encrypted systems still suffer breaches?
A: Because encryption only protects data if the keys and key-management paths remain controlled.
Q: What do organisations get wrong about key rotation?
A: They often treat rotation as a calendar task instead of a lifecycle control tied to exposure risk, ownership, and revocation.
Practitioner guidance
- Inventory all key-using identities Map every service account, pipeline, workload, and admin identity that can create, request, export, or revoke keys.
- Automate key rotation and revocation Replace manual or calendar-based rotation with policy-driven lifecycle controls for application keys, signing keys, and cloud KMS permissions.
- Separate key administration from key usage Remove standing admin rights where the same identity can both manage and consume cryptographic keys.
What's in the full article
eMudhra's full article covers the operational detail this post intentionally leaves for the source:
- Centralised key management patterns for cloud, on-prem, and hybrid estates
- Automation approaches for rotation, revocation, and audit logging
- Identity-based controls for administrators, pipelines, and application workloads
- Governance considerations for compliance reporting and key ownership
👉 Read eMudhra's analysis of why encryption key management controls matter →
Encryption key management failures: what IAM teams are missing?
Explore further
11/07/2026 2:09 pm
Encryption key management is the control plane that determines whether encryption is real security or only mathematical reassurance. The article is correct to separate encryption from governance, because attackers increasingly go after the keys, permissions, and lifecycle gaps that sit behind the cipher. For IAM and PAM teams, the practical conclusion is that key access is privileged access and must be treated with the same discipline as any other high-risk credential.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: Who is accountable when a key compromise affects multiple systems?
A: Accountability usually sits with the team that owns both the identity permissions and the operational lifecycle of the key, not just the platform storing it. If a KMS admin, pipeline owner, or service-account owner can extend key access without review, that governance gap is the root issue. Strong audit trails and separation of duties make accountability visible.
👉 Read our full editorial: Encryption key management failures expose the trust layer in 2026
