TL;DR: Encryption alone does not secure sensitive data unless enterprises can govern the full key lifecycle across HSM, software, cloud and hybrid environments, while also preparing for post-quantum cryptography, according to Fortanix. The operational question is no longer whether keys are protected, but whether key management can stay auditable, portable and crypto-agile as infrastructure and algorithms change.
At a glance
What this is: This guide explains how enterprise encryption key management systems differ across HSM, software, cloud-native and hybrid models, and why post-quantum readiness is now part of the selection problem.
Why it matters: It matters because IAM and security teams cannot treat encryption as complete unless key custody, rotation, auditability and crypto-agility are governed as part of the identity and access control model for secrets and machine trust.
Context
Encryption only protects data if the keys behind it are controlled, rotated and retired under a governed lifecycle. In practice, key management becomes the control plane for trust because the compromise of a key can nullify encryption, logging and data separation all at once. For identity and security programmes, that makes key custody part of the broader cryptographic key management problem, not a separate infrastructure detail.
The article frames a real governance tension: enterprises want strong assurance, but they also need scale, portability and resilience across cloud, on-premises and regulated environments. That tension becomes sharper when post-quantum cryptography enters the roadmap, because key systems must adapt without creating blind spots or lock-in.
This is a typical enterprise problem, but the article usefully shows how often teams still evaluate encryption tooling as if keys were static assets rather than governed credentials.
Key questions
Q: How should security teams choose between HSM, software and cloud key management?
A: Choose by the governance burden you need to carry, not by convenience alone. HSMs suit the highest-assurance keys, software and cloud services suit scale and integration, and hybrid models suit fragmented estates. The decision should hinge on custody, auditability, migration tolerance and whether the platform can support future algorithm change without creating new blind spots.
Q: Why does post-quantum cryptography change key management planning?
A: PQC changes planning because enterprises cannot assume today’s algorithms and key handling will remain valid for the full life of the system. Key inventories, dependency mapping and migration paths become critical. If teams cannot discover where cryptographic assets live and how they are used, they will struggle to move to quantum-safe standards in a controlled way.
Q: What breaks when encryption governance and key handling are not coordinated across systems?
A: When encryption governance and key handling are fragmented, organisations can lose visibility into who can decrypt data, where keys are stored, and which systems depend on them. That creates operational risk, weak auditability, and inconsistent recovery procedures. The result is often control drift, slower incident response, and a higher chance of misconfiguration during change or support activity.
Q: Should organisations centralise key management across cloud and on-premises systems?
A: Centralisation helps when the alternative is inconsistent policy, duplicated tooling and weak visibility across environments. The risk is that central policy without local enforcement creates a false sense of control. Organisations should centralise governance, but only if they can still prove where each key lives, who can use it and how revocation works in every platform.
Technical breakdown
Why hardware security modules still matter for key custody
Hardware security modules, or HSMs, keep cryptographic keys inside tamper-resistant hardware so the key material is harder to extract or misuse. That matters when the primary concern is high-assurance custody, especially for payment, government and other regulated workloads. The trade-off is operational rigidity: HSMs are harder to scale across regions and clouds, and they can become a bottleneck when organisations need rapid change. PQC increases that pressure because legacy hardware may not support newer algorithms without redesign. See the Machine Identity, PKI and Certificate Lifecycle Guide. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Practical implication: keep HSM-backed custody for the highest-value keys, but test whether your platform can support crypto-agile migration without a forklift replacement.
How software and cloud key services change the attack surface
Software-based and cloud-native key management services trade hardware isolation for speed, integration and scale. They work well when teams need automation, API access and broad application coverage, but they also increase dependence on the host environment, provider settings and surrounding access controls. If the environment is weak, the key service becomes easier to abuse than a physically isolated HSM. The governance challenge is not just storing keys somewhere else, but ensuring role design, rotation, logging and environment hardening follow the same control standard across every deployment model. See the API Key Management Guide. See the API Key Management Guide.
Practical implication: treat software and cloud KMS deployments as access-controlled services with continuous monitoring, not as set-and-forget vaults.
What crypto-agility means for enterprise key management
Crypto-agility is the ability to change cryptographic algorithms, parameters and key handling without rebuilding the entire security stack. It matters because post-quantum migration will not happen all at once, and different clouds and platforms will move at different speeds. A key management programme that cannot inventory cryptographic assets, map dependencies and stage algorithm change will struggle to adapt. In practice, crypto-agility is less about picking one future-proof product and more about ensuring the organisation can discover, assess and transition cryptographic dependencies in a controlled way. See the Cryptographic Key Management Guide. See the Cryptographic Key Management Guide.
Practical implication: build inventory and migration planning now so algorithm change becomes a governed process rather than an emergency response.
Threat narrative
Attacker objective: The objective is to obtain or abuse key material so protected data, signatures or trusted transactions can be decrypted, altered or impersonated.
- Entry occurs when attackers or insiders target the systems that store or manage cryptographic keys rather than the encrypted data itself.
- Escalation happens if key custody, host hardening or access governance is weak enough to expose unprotected keys or allow misuse of privileged key operations.
- Impact follows when compromised keys undermine confidentiality, integrity or trust across multiple systems, making encryption controls ineffective at scale.
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.
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
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 now a trust-control problem, not a storage problem. The article correctly treats encryption as incomplete unless keys are governed across generation, storage, rotation, retirement and audit. That aligns key custody with identity governance because the real question is who can use the key, when, and under what authority. Practitioners should evaluate key systems as part of the wider control plane for secrets and machine trust.
Crypto-agility is the new design requirement for enterprise encryption. The PQC discussion matters because many current deployments assume algorithms will remain stable for the life of the platform. That assumption is increasingly weak, especially in multi-cloud estates where providers move at different speeds. The governance implication is that inventory, dependency mapping and migration planning matter more than any single key store feature. Practitioners should make crypto-agility a selection criterion, not an afterthought.
Hybrid key management exposes the real organisational problem: fragmented control ownership. Centralising policy across HSMs, cloud KMS and software-defined services only works if teams can see every cryptographic asset and enforce one operating standard. Without that, hybrid architecture becomes another source of drift. This is where cryptographic key management intersects with IAM discipline: inventory, approval, rotation and revocation all need ownership. Practitioners should treat fragmentation as a governance risk, not just an architecture choice.
The article also shows why key management is becoming a board-level resilience issue. Quantum readiness, regulatory pressure and multi-cloud sprawl are converging on the same control gap: organisations often know where encryption exists, but not whether the keys are governable under change. That creates future operational risk long before any quantum event arrives. Practitioners should assess whether their current key model can survive algorithm change, provider migration and incident recovery without service disruption.
Read next: Cryptographic Key Management Guide
What this signals
Crypto-agility is becoming the deciding design principle for enterprise encryption. The practical issue is not whether a platform can store keys today, but whether it can absorb algorithm change, provider migration and audit demands without forcing a redesign. Security teams should plan for cryptographic change as an operating condition, not a future scenario.
When key management spans HSMs, software services and cloud KMS, the main failure mode is control drift. A programme can look well governed in one environment and still leave hidden gaps elsewhere, so the next control step is continuous inventory and policy consistency rather than another isolated tooling purchase.
For practitioners
- Define a single key lifecycle standard Set one policy for key creation, storage, rotation, retirement and revocation across HSM, software and cloud-native services so custody does not vary by platform.
- Inventory cryptographic assets across all environments Build and maintain a complete inventory of keys, certificates and dependent applications across on-premises, multi-cloud and edge estates so crypto-agility planning is evidence based.
- Separate high-assurance keys from routine workloads Keep the most sensitive signing and encryption keys in stronger custody models, and do not assume every workload needs the same protection pattern.
- Test provider and platform migration paths now Validate how keys, policies and dependencies move when workloads change cloud providers or key services, because migration pain is a governance issue before it is a technical one.
- Add PQC readiness to architecture reviews Review whether current systems can support algorithm transitions without redesigning application flows, access controls or audit evidence.
Key takeaways
- Encryption only remains effective when the key lifecycle is governed with the same discipline as the protected data.
- PQC readiness turns cryptographic inventory and migration planning into immediate operating requirements.
- Hybrid estates need one policy model across custody types, or key governance fragments as soon as environments diverge.
Related NHI Mgmt Group resources: Cryptographic Key Management Guide · Machine Identity, PKI and Certificate Lifecycle Guide · API Key Management Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-57, CSA Cloud Controls Matrix and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Part 1 — Key Management Lifecycle | The article is fundamentally about governing key lifecycle across storage, rotation and retirement. |
| Recommendation — Apply key lifecycle governance to inventory, rotate, retire and recover cryptographic keys across all environments. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud key services depend on governed access to cryptographic assets and administrative functions. |
| Recommendation — Enforce IAM controls on who can administer and use cloud key services. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Key systems depend on tightly controlled permissions for key operations and administrative access. |
| Recommendation — Limit cryptographic key operations to explicitly authorised roles and services. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Key compromise enables credential-like abuse and lateral movement across trusted systems. |
| Recommendation — Map key exposure paths to credential access and lateral movement behaviours in detection and response. | ||
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.
- Hardware Security Module: A hardware security module is a tamper-resistant device or service used to generate, store, and use cryptographic keys without exposing them directly to endpoints. For code signing, it reduces the chance that a compromised workstation or build server can steal the signing authority.
- Crypto-Agility: Crypto-agility is the ability to change cryptographic algorithms, certificates, and trust dependencies without redesigning production systems. It matters because cryptographic standards evolve, and organisations need accurate inventories and automated lifecycle controls before they can migrate safely.
- Post-Quantum Cryptography: Cryptographic algorithms designed to remain secure against attacks from sufficiently powerful quantum computers. In practice, PQC is a migration problem as much as an algorithm problem because organisations must replace trust anchors, certificates, and secrets without breaking identity-dependent systems.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity controls to the broader security programme they are already running.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org