TL;DR: Enterprise breaches increasingly hinge on exposed encryption keys, API keys, signing keys, and TLS private keys rather than passwords or MFA, according to eMudhra. The trust assumption that identity controls alone can protect cryptographic material is collapsing, and key governance is now an identity security requirement, not a backend convenience.
At a glance
What this is: This is an analysis of why key management now sits inside the identity trust chain, with the central finding that keys, not passwords, increasingly determine whether enterprise controls hold or fail.
Why it matters: It matters because IAM, PAM, PKI and workload governance all lose effectiveness when keys are unowned, unrotated, or spread across cloud, CI/CD and application silos.
Context
Key management is the discipline of generating, storing, rotating, revoking and retiring cryptographic keys. In this article, eMudhra argues that the real enterprise trust problem is no longer just user authentication, but who holds the keys that authenticate people, devices, workloads and services.
The governance gap is structural. IAM, PKI and MFA cover parts of the trust chain, but they do not by themselves control the lifecycle of encryption keys, signing keys, API keys, TLS private keys and SSH keys across cloud services, CI/CD pipelines, apps and endpoints.
That makes key management an identity security issue, not a backend housekeeping function. Once keys sprawl across environments without central policy, visibility and accountability collapse, and the trust fabric becomes only as strong as its weakest unmanaged key.
Key questions
Q: How should security teams govern keys that are embedded in cloud, CI/CD and application workflows?
A: Treat keys as governed identity assets, not as implementation leftovers. Create one accountable lifecycle for issuance, storage, rotation, revocation and retirement, then map every runtime location where a key can be copied or reused. If a key cannot be owned, rotated and retired on demand, it is an unmanaged trust dependency.
Q: Why do unmanaged keys create more identity risk than IAM policies can absorb?
A: Because IAM controls who may log in, while keys often control what the workload, service or application can actually do once trust is established. A leaked or unrotated key bypasses the usual user-centric assumptions and can persist across systems far longer than a session or login event. That makes cryptographic lifecycle control essential to identity governance.
Q: What are the signs that enterprise key management for IP security is failing?
A: Common warning signs include manual key handling, delayed rotation, inconsistent expiration practices, and scattered access controls across teams. Risk also rises when keys are stored in software without strong protection, backup and recovery are ad hoc, or no one can clearly say who can create, use, or revoke a key. These gaps usually precede exposure.
Q: What is the difference between certificate management and PKI governance?
A: Certificate management is the operational handling of issuance, renewal, rotation, and revocation. PKI governance is broader. It defines the policy, ownership, architecture, and control model that make those operations consistent across the enterprise. Strong governance gives certificate management structure, while weak governance usually leads to silos, drift, and uneven enforcement across teams.
Technical breakdown
Why IAM and MFA stop at the trust boundary
IAM verifies who a subject is, MFA proves the login event, and PKI binds identity to certificates. None of those layers is designed to own the lifecycle of cryptographic material at scale. Keys can exist in developer laptops, pipeline variables, cloud KMS silos, container images and application config files, each with different ownership and revocation paths. That fragmentation turns cryptographic governance into a distributed problem rather than a single control point. The operational failure is not absence of identity controls, but absence of a unified trust layer for the credentials that those controls depend on.
Practical implication: treat key lifecycle governance as a distinct control domain, not as a side effect of IAM or PKI.
How key sprawl creates silent exposure across cloud and CI/CD
The article describes a common failure pattern: keys are created in uncontrolled places, then copied into scripts, configs and runtime environments where they are difficult to inventory. Cloud provider KMS tools help with storage, but they do not automatically remove cross-environment sprawl or ownership ambiguity. In CI/CD and containerised systems, a single exposed key can propagate through build artefacts, secrets stores and mounted volumes. The risk is that the enterprise believes it has centralised trust while keys remain scattered and persistent in places not designed for governed identity lifecycle management.
Practical implication: inventory where keys are born and where they persist, then remove unmanaged creation paths and static copies.
Why rotation and revocation define cryptographic governance
A key that is never rotated or revoked behaves like standing privilege. The article’s core point is that key management is not just storage, but lifecycle control. Rotation shortens exposure windows, revocation cuts off compromised access, and auditability provides evidence that the trust chain is under governance. When those functions are fragmented across separate teams or tools, expired certificates, dormant keys and incomplete audit trails become operationally normal rather than exceptional. That is the point where a trust architecture starts to fail silently.
Practical implication: enforce rotation, expiry and revocation as lifecycle controls with ownership, logging and approval attached.
Threat narrative
Attacker objective: The attacker’s objective is to obtain cryptographic trust material that lets them impersonate, decrypt or sign across multiple systems.
- Entry begins when a cryptographic key is created or copied into an uncontrolled location such as a laptop, pipeline, application config file or cloud instance.
- Credential use escalates when that key is reused across services, environments or workloads without central revocation or ownership.
- Impact follows when a compromised key breaks the trust chain for authentication, signing or encryption across dependent systems.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
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
Key management is the trust layer IAM never covered: IAM, MFA and PKI authenticate identities, but they do not on their own govern the lifecycle of cryptographic material that those identities rely on. When keys are scattered across cloud services, CI/CD, apps and endpoints, the trust boundary moves outside the reach of traditional identity governance. Practitioners should treat key lifecycle ownership as a first-class governance domain, not an implementation detail.
Standing cryptographic privilege is the real exposure pattern: Keys that are created once, copied widely and never revoked function like persistent access paths. That is why the article’s framing matters for NHI governance as well as human IAM: the control failure is not simply leakage, it is unbounded duration of access through reusable trust material. Practitioners should evaluate whether any key in the estate can outlive the business event that created it.
Crypto sprawl creates an identity blast radius: A single key can authenticate a workload, unlock a secret, or sign software in ways that are difficult to trace after the fact. This is the same governance problem that appears in overprivileged NHI, but expressed through cryptographic credentials rather than tokens alone. The practical conclusion is to govern keys as identity-bearing assets with inventory, ownership and lifecycle accountability.
Trust fabric fragmentation is now a board-level issue: The article is right to link key management with Zero Trust because the model fails when trust is delegated to disconnected stores, tools and teams. Regulators and CISOs are converging on the same point from different angles: if the organisation cannot explain who can create, use, rotate and retire keys, it cannot credibly claim control over its trust boundary. Practitioners should expect key governance to become part of broader identity assurance and resilience conversations.
Cryptographic governance needs the same discipline as identity governance: Key creation, issuance, rotation and retirement are lifecycle events, not isolated technical tasks. The organisations that manage keys well are the ones that can align cryptographic policy with access policy, audit evidence and operational ownership. For identity teams, that means the next maturity step is not another login control, but a governed trust fabric across people, machines and workloads.
From our research library:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- Read next: Cryptographic Key Management Guide
What this signals
Cryptographic trust fabric: key governance is becoming the connective tissue between IAM, PKI, MFA and workload identity, because the control plane is only as strong as the keys that anchor it. For teams running hybrid estates, the next programme question is whether they can explain key ownership and retirement across every environment, not just in a vault.
The practical shift is from protecting login events to protecting the artefacts that make login, signing and encryption possible. That means identity and security teams should expect key inventory, rotation evidence and revocation workflows to appear alongside access reviews in governance conversations.
Where organisations still treat keys as back-end implementation detail, exposure persists in cloud services, CI/CD pipelines and application runtimes. The control problem is not lack of tooling alone, but lack of a lifecycle model that connects cryptographic events to identity assurance.
For practitioners
- Inventory all key creation paths Map where encryption keys, signing keys, API keys, TLS private keys and SSH keys are created, copied and stored across cloud, CI/CD, endpoints and applications.
- Centralise key lifecycle ownership Assign clear owners for issuance, rotation, revocation and retirement so every key has an accountable lifecycle, not just a place where it is stored.
- Remove static keys from delivery pipelines Replace hardcoded or long-lived keys in build systems, deployment scripts and container images with governed delivery paths and short-lived access.
- Tie audit evidence to cryptographic events Record who created, used, rotated and retired each key so operational teams can prove control over the trust chain during reviews or incidents.
Key takeaways
- Keys now represent a primary trust dependency in enterprise security, and identity controls alone do not govern their lifecycle.
- The article’s risk case is rooted in sprawl, with keys spread across cloud services, pipelines, apps and endpoints without central ownership.
- The decisive control change is to manage keys as identity-bearing assets with inventory, rotation, revocation and audit evidence.
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 exposed in laptops, pipelines and configs. |
| NHI-07 — Long-Lived Secrets | The article argues that keys become dangerous when they are never rotated or retired. | |
| Recommendation — Scan for leaked keys across code, logs and pipeline artefacts and revoke exposed credentials immediately. Enforce short-lived credentials and rotation rules for every key that can be reused across systems. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 directly maps to authenticator and credential lifecycle governance. |
| Recommendation — Apply IA-5 to define issuance, rotation, revocation and retirement for cryptographic authenticators. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The threat pattern is credential capture through exposed keys and tokens. |
| Recommendation — Map key exposure to TA0006 and prioritise detection for stores, pipelines and config files. | ||
Key terms
- Key Management: Key management is the controlled lifecycle of cryptographic keys, from generation and storage through rotation, use, and retirement. In enterprise environments it is the governance layer that determines whether keys remain trustworthy across users, workloads, devices, and applications.
- Trust Fabric: A trust fabric is the combined identity, access, monitoring, and oversight layer that lets humans and non-human actors operate safely in the same environment. For AI deployments, it determines whether an agent's actions are bounded, attributable, and reversible when behaviour changes.
- Cryptographic lifecycle management: The governance of cryptographic assets from issuance through rotation, renewal, retirement, and replacement. In practice, this means assigning owners, tracking expiry, monitoring usage, and making sure certificate and algorithm changes are handled as part of normal identity and service operations.
- Key Sprawl: The condition where keys are scattered across clouds, pipelines, applications, and local systems without central visibility. Sprawl makes it harder to know which keys are active, who owns them, and whether they are safe to keep in circulation.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 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