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.
At a glance
What this is: This analysis says encryption is widely deployed, but weak cryptographic key management leaves the trust layer exposed because attackers steal, misuse, or abuse keys instead of breaking cryptography.
Why it matters: IAM, PAM, and NHI teams need to treat key access, rotation, and revocation as governance controls, because encryption only protects data when the keys are tightly controlled across the full lifecycle.
Context
Encryption key management is the control layer that decides who can access, rotate, revoke, and audit the keys that protect data. When that layer is weak, encryption still exists, but the protection it is supposed to deliver becomes unreliable.
The article frames this as a governance failure across cloud, APIs, databases, backups, and hybrid environments. The identity question is not whether data is encrypted, but whether the identities and processes behind the keys are controlled with enough discipline to prevent silent misuse.
Key questions
Q: What breaks when key management is weak under GDPR encryption requirements?
A: Weak key management breaks the value of encryption itself. If keys are not restricted, logged, and held separately from the data, the organisation may still face breach notification duties and regulatory criticism. Examiners will look for demonstrable control, not assumptions. Poor lifecycle management also turns algorithm changes and certificate expiry into compliance and operational incidents.
Q: Why do keys matter more than encryption algorithms in modern breaches?
A: Because attackers increasingly target the control plane around cryptography instead of the mathematics of encryption itself. Once they obtain a valid key, they can bypass confidentiality protections, impersonate trusted systems, or decrypt data without needing to defeat the algorithm.
Q: What are the signs that lifecycle governance is failing?
A: Look for dormant entitlements that stay active, high-risk grants that go unnoticed, and role changes that do not immediately trigger review. Those are observable signs that access governance is operating on stale state instead of current identity context.
Q: How do security teams reduce the blast radius of a compromised key?
A: By limiting which identities can administer keys, enforcing immediate revocation paths, and reducing reuse across environments and services. The smaller the number of systems and roles tied to one key, the less damage a compromise can spread.
Technical breakdown
Why encryption strength does not equal trust-layer control
Encryption protects confidentiality only if the keys remain governed. In practice, the protection boundary shifts from the cipher to the identities, services, and administrators that can access key material. That means the real risk surface is KMS permissions, application secrets, API keys, signing keys, and storage encryption keys. If those are overexposed, reused, or left untracked, the strongest cryptography still leaves data effectively open to anyone who can obtain the key.
Practical implication: treat key access as the primary control point, not encryption status alone.
How key lifecycle failures become a hidden access problem
Key lifecycle management covers generation, access, usage, rotation, and revocation. The article shows that failures usually arise when these steps are handled manually or reviewed too late for dynamic cloud and DevOps environments. Short-lived workloads, CI/CD pipelines, and microservices can create and consume keys faster than periodic review cycles can see them. Once that happens, access persists beyond the point where anyone can confidently account for it.
Practical implication: align key lifecycle controls with the speed of the systems that create and consume them.
Why KMS governance now behaves like identity governance
A key management system is not just a storage vault. It is an identity control plane for cryptographic authority, because every key action is ultimately tied to an authenticated actor, a service, or a process. That makes least privilege, separation of duties, logging, and revocation central to KMS security. When too many people or services can act on keys, the KMS becomes a governance gap rather than a protection layer.
Practical implication: apply identity governance discipline to key administration, not just to user accounts.
Threat narrative
Attacker objective: The objective is to turn key access into durable control over protected data and the systems that depend on it.
- Entry occurs when an attacker gains access to exposed or overprivileged keys rather than attempting to break the encryption itself.
- Escalation follows when those keys are reused across services, allowing the attacker to unlock multiple systems or bypass normal monitoring.
- Impact occurs when the attacker uses the compromised keys for persistent access, decryption, or signing activity that blends into legitimate operations.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- GoTo breach 2023: An attacker took GoTo's encrypted backups for five products and a key for part of them from cloud storage shared with LastPass, GoTo said in January 2023.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Encryption has become a trust assumption problem, not a cryptography problem. The article is right to shift attention away from algorithm strength and toward who can control the keys that make encryption meaningful. In modern estates, the key management layer defines whether encryption is protection or theatre. For practitioners, this means the decisive control is governance over the key holder, not reassurance from the cipher.
Key lifecycle management is now the real boundary of operational trust. Manual rotation, delayed revocation, and weak visibility create a gap between when access should end and when it actually does. That gap is where exposure accumulates across cloud, APIs, backups, and databases. The implication is that teams must stop treating lifecycle governance as administrative overhead and start treating it as a core security boundary.
Identity governance must extend to cryptographic authority. Keys are acted on by people, service accounts, automation, and platform processes, so the control problem is fundamentally about entitlement. If too many identities can administer, export, or reuse keys, the KMS becomes an escalation path. Practitioners should read this as a reminder that key management is identity management by another name.
Trust layer exposure is the right concept for board-level risk framing. This article names the failure clearly: systems can look encrypted and still remain compromise-ready if key control is weak. That framing is useful because it explains why breaches persist even in mature environments. The practical conclusion is that boards should ask how trust is governed, not simply whether encryption is enabled.
Cryptographic governance belongs in the same conversation as PAM and secrets control. The article shows that privileged access to keys can be more consequential than many application-layer permissions. That makes key administration a high-risk function that should be audited like any other privileged pathway. For security leaders, the takeaway is to unify key governance with privileged access oversight rather than manage it as a separate silo.
What this signals
Trust-layer governance is the new centre of gravity. Encryption has become a baseline, but the security outcome now depends on whether identity controls reach the key lifecycle itself. If a team cannot answer who can use, rotate, or revoke keys, then the environment is encrypted without being governed.
Cryptographic authority should be treated like privileged access. The article’s strongest point is that key misuse behaves like escalation, not like a simple configuration mistake. That is why key administration deserves the same separation of duties, auditability, and lifecycle discipline used for other high-risk privileges.
For practitioners
- Define key administrators as privileged identities Inventory every human and non-human identity that can create, export, rotate, revoke, or delegate cryptographic keys, then apply least privilege and separation of duties to those roles.
- Automate rotation and revocation windows Replace periodic manual review with policy-driven rotation and immediate revocation for exposed, stale, or high-value keys across cloud, API, database, and backup estates.
- Log every key action as an identity event Capture create, use, rotate, disable, and revoke events with actor identity, system context, and target key so security teams can trace key abuse as access governance failures.
- Separate key storage from operational authority Keep storage controls, usage rights, and administrative authority distinct so the team that runs applications cannot also silently manage the trust material that secures them.
Key takeaways
- Weak key management, not weak encryption, is the failure mode that turns protected systems into exploitable ones.
- The operational evidence is visible in overprivileged access, delayed rotation, and poor revocation across cloud and hybrid estates.
- Teams that treat key governance as identity governance reduce the chance that encryption becomes a false assurance layer.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on keys and secrets that expose encrypted data when mishandled. |
| NHI-07 — Long-Lived Secrets | Manual rotation delays and stale keys are a central failure mode in the article. | |
| Recommendation — Scan for exposed keys and secrets, then revoke and replace any credential that can unlock protected data. Shorten key lifetimes and automate rotation so stale cryptographic material cannot persist unnoticed. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Key lifecycle handling maps directly to management of authenticators and their rotation. |
| AC-6 — Least Privilege | Overprivileged access to keys is one of the article's core governance failures. | |
| Recommendation — Use IA-5 to enforce controlled issuance, rotation, and revocation for cryptographic authenticators. Restrict key administration to the minimum set of identities that genuinely need that authority. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The threat pattern is key theft leading to decryption, persistence, and data exposure. |
| Recommendation — Map key theft to credential access and prioritise detections around privileged key use and abuse. | ||
Key terms
- Cryptographic Key Management: Cryptographic key management is the discipline of generating, storing, using, rotating, revoking, and auditing the keys that protect encrypted systems. In practice, it is the governance layer that determines whether encryption remains trustworthy across cloud, pipeline, and workload environments.
- Trust layer: A governance layer that sits between AI capability and enterprise data or actions. It combines identity, data classification, access control, and behavioural policy so organisations can decide what an AI system may see, infer, or do at runtime.
- Key Lifecycle Management: Key lifecycle management is the set of controls that govern cryptographic keys from creation through rotation, revocation, and retirement. It is not just storage protection. It is the operational discipline that keeps keys current, traceable, and removable when trust relationships change.
- Cryptographic Governance: The policy and oversight layer that determines how keys, certificates, and trust rules are approved, controlled, and audited. It turns cryptographic operations into a managed identity function by binding trust decisions to ownership, lifecycle, and compliance requirements.
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or privileged access programme, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org