Why do unmanaged cryptographic keys create more risk than encryption itself?

Why This Matters for Security Teams

Encryption is only as strong as the key lifecycle behind it. When keys are unmanaged, the control plane becomes the real target: attackers do not need to break the cipher if they can find secrets in code, backups, pipelines, endpoints, or overly broad vault access. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks shows how often this gap appears in practice, and the risk is amplified by the scale of service accounts, API keys, and certificates spread across modern estates.

This is also why unmanaged keys create audit exposure. A team can claim data is encrypted and still fail basic questions about who can retrieve, copy, rotate, or revoke the keys that protect it. NIST’s Cybersecurity Framework 2.0 treats identity, access, and recovery as operational controls, not afterthoughts. In practice, many security teams discover key sprawl only after a secret leak, an expired certificate outage, or a third-party incident has already turned encryption into a liability rather than a safeguard.

How It Works in Practice

Good encryption programs treat keys as first-class assets. That means defining ownership, inventorying where keys exist, storing them in approved systems, enforcing rotation, and monitoring use for anomalies. For non-human identities, this is not a one-time setup task. Keys often live in CI/CD variables, containers, infrastructure templates, and application configuration, so lifecycle management must follow the workload, not just the vault.

Current guidance suggests separating data protection from key custody. The data may remain encrypted at rest or in transit, but access should depend on tightly scoped retrieval controls, short-lived credentials, and revocation paths that work fast enough to matter. NHIMG’s NHI Lifecycle Management Guide and Top 10 NHI Issues both reinforce the same operational point: key exposure is usually a governance failure before it becomes a cryptographic failure.

• Centralise key creation and storage in approved secrets managers or HSM-backed services.
• Assign each key to a named workload, owner, and rotation policy.
• Use automated revocation when a workload is retired, compromised, or redeployed.
• Log key access, retrieval, and rotation events for detection and audit.

Where this breaks down is in distributed build systems, legacy applications, and third-party integrations that still require embedded static credentials because they cannot consume short-lived secrets or managed identities.

Common Variations and Edge Cases

Tighter key control often increases operational overhead, requiring organisations to balance cryptographic assurance against deployment speed and application compatibility. That tradeoff is real, especially when teams support mixed environments with old agents, manual release processes, and external partners that expect long-lived credentials.

Best practice is evolving, but there is no universal standard for every workload. Some environments can move quickly to ephemeral secrets and automatic rotation, while others need compensating controls such as network isolation, strict vault permissions, and accelerated monitoring. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because regulators usually care less about the encryption algorithm and more about whether the organisation can prove control over access, rotation, and revocation.

One important edge case is certificate management. Teams sometimes focus on API keys and forget that expired or broadly trusted certificates can create both outages and implicit trust paths. Another is third-party access: a partner may use encrypted transport correctly while retaining static keys indefinitely, which means the protection boundary sits outside direct control. That is why NHIMG’s research on the 2024 ESG Report: Managing Non-Human Identities is a useful reminder that compromise often reflects weak identity governance, not weak encryption. The practical answer is not “encrypt more,” but “manage the keys as aggressively as the data they protect.”

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?
• Why do collaboration tools create such a large secrets risk?