Enterprise key management explained: what a key management system does, its components, KMaaS vs HSM vs cloud KMS, how to choose and how to roll it out.
Enterprise key management is the centralised management of cryptographic keys across an organisation's applications, clouds and SaaS services. It covers how keys are generated, stored, used, rotated, revoked and destroyed, under one policy, with one audit trail. An enterprise key management system (EKMS) is the software, and often the hardware, that enforces that policy.
Most organisations don't lack encryption. What they lack is control over the keys behind it. Keys are spread across cloud KMS services, HSMs, SaaS "customer-managed keys" and application secrets, each with its own console, administrators and logs. When a regulator asks who can decrypt a given dataset, the answer is hard to assemble.
This guide is for security architects and CISOs choosing how to manage keys in 2026. It defines the terms (enterprise key management, key management system, HSM, key management as a service, MPC), lists the components of a key management system, walks through the key lifecycle as NIST describes it, compares KMaaS, HSM and cloud KMS, and ends with selection criteria, a rollout plan and a FAQ.
Enterprise key management (EKM) is the discipline; a key management system (KMS) is the tool that implements it. A KMS generates keys, stores them or delegates storage to hardware, controls who and what may use them, performs or brokers cryptographic operations, and records every action. "Enterprise" means the scope is the whole estate, not one application or one cloud account.
AWS KMS, Azure Key Vault and Google Cloud KMS are key management systems, but each covers one cloud. Enterprise key management sits above them: one policy, one inventory and one audit trail across clouds, SaaS, databases and on-premises systems, and the option to keep some keys outside the provider that stores the data.
Keys typically live in cloud KMS services, SaaS platforms, databases with transparent data encryption, on-premises HSMs and vault software. Each is a separate key store with its own rotation schedule, access model and log format. The consequences:
The core control in key management is that the party that stores your data should not also be the only party that controls the key that decrypts it. When a cloud or SaaS provider generates and holds the key in its own KMS, the provider's operators, its legal obligations and its incidents are all part of your threat model. External key management, often called hold your own key (HYOK), moves the key outside the provider's control. Our hold your own key (HYOK) guide covers the patterns in detail.
Financial and critical-infrastructure regulators increasingly ask firms to show how cryptographic keys are governed, not just that data is encrypted. For the specifics, see our guides to DORA encryption requirements, NIS2 encryption requirements and FINMA Guidance 05/2026 for Swiss banks. The common thread: a documented key lifecycle, restricted and logged access, and the ability to change algorithms as post-quantum migration progresses.
NIST SP 800-130, A Framework for Designing Cryptographic Key Management Systems, describes what a key management system has to specify: its security policy, roles, key types and metadata, key-management functions, and how it is protected and recovered. In product terms, most enterprise key management systems are built from the same eight parts.
| Component | What it does | What to check |
|---|---|---|
| Key store and root of trust | Holds key material, or the master key that protects it | HSM, MPC shards, cloud HSM or software; who can reach it |
| Lifecycle engine | Creates, activates, rotates, suspends, revokes and destroys keys | Explicit key states, cryptoperiods, versioning |
| Policy and access control | Decides which user, service or workload may use which key, for which operation | RBAC, attribute-based rules, dual control on destructive actions |
| Cryptographic API | Exposes encrypt, decrypt, wrap, sign and verify, or returns keys to clients | REST, PKCS#11, KMIP, latency per call |
| Integrations | Connects to clouds, SaaS, databases, hypervisors and vaults | Native connectors you can use today |
| Audit and reporting | Records every key operation and admin action | Tamper evidence, SIEM export, retention |
| Availability and recovery | Keeps keys usable through node, site or region failure | Clustering, backups, tested restore |
| Administration | Console, tenants, organisational units, automation | SSO and MFA for admins, API and infrastructure-as-code support |
A product that only covers some of these rows is not wrong, but the missing rows become work for your team.
The reference most auditors and frameworks lean on is NIST Special Publication 800-57 Part 1 Revision 5, Recommendation for Key Management: Part 1 – General (May 2020). It gives general guidance on key types, the protection each one needs and the key-management functions around them.
SP 800-57 divides the key-management lifecycle into four phases, and places each key in one of six states:
| Phase | What happens | Key states |
|---|---|---|
| Pre-operational | Key material not yet available for normal use; key generated or awaiting activation | Pre-activation |
| Operational | Key available and in normal use | Active, Suspended |
| Post-operational | No longer in normal use, but still accessible to process already-protected data (e.g. decrypt, verify); may be archived | Deactivated, Compromised |
| Destroyed | Key no longer available; metadata may be retained | Destroyed |
Two details matter for design: a suspended key can process data (for example decrypt) but not apply new protection, and after destruction the key's metadata (name, type, cryptoperiod, usage period) may be kept as evidence.
In day-to-day terms, an enterprise key management system runs these operations:
NIST defines a cryptoperiod as the time span during which a specific key is authorised for use. A suitable cryptoperiod limits how much data is exposed if a key is compromised, how much material is available for cryptanalysis, and how long an attacker has to get around the controls protecting the key. If a key is compromised, its cryptoperiod is no longer valid.
SP 800-57 lists the factors that should set the length of a cryptoperiod, including the strength of the algorithm and key length, how the mechanism is implemented (for example a hardware module versus software on a PC), the operating environment, personnel turnover, data volume, the security life of the data and the re-keying method. It also gives suggested cryptoperiods per key type; use those values from the publication itself rather than rules of thumb.
What this means for an enterprise key management system: it must model states explicitly (not just "enabled/disabled"), enforce cryptoperiods per key type, keep keys usable for decryption after they stop being used for encryption, and keep destruction evidence.
In short, KMS vs HSM is policy and lifecycle versus secure storage and execution. Most enterprises need both functions; the question is who runs each, and where trust sits.
The three options buyers compare most often answer different questions. An HSM answers "where is the key physically protected?". A cloud KMS answers "how do I encrypt inside this cloud with little effort?". Key management as a service answers "how do I run one key policy across several clouds and SaaS without operating the platform myself?".
| On-premises or cloud HSM | Cloud provider KMS | Independent KMaaS | |
|---|---|---|---|
| Main job | Hardware key storage and crypto operations | Encryption for that provider's services | Lifecycle, policy and audit across providers |
| Scope | Applications that call it (PKCS#11, JCE, CNG) | One cloud | Several clouds, SaaS, databases, on-premises |
| Key held by | You, in hardware you or the provider host | The provider, under your IAM policy | The KMaaS, outside the data provider |
| Who operates it | Your team (or provider for the hardware) | The provider | The vendor; you keep policy |
| Separation from data holder | Yes, if on premises | No | Yes |
| Typical cost drivers | Hardware, HA pairs, specialists, refresh | Per key and per request | Subscription, keys, integrations |
| Fits when | A mandate requires a validated hardware boundary, or applications need a local HSM | Data and workloads stay in one cloud and provider custody is acceptable | Keys must sit outside the clouds and SaaS that hold the data, with one audit trail |
The models combine. A KMaaS can use HSMs or MPC as its key store, and it can push keys into, or answer requests from, cloud KMS services through BYOK and HYOK interfaces. A common target architecture in 2026 is cloud-native KMS for low-sensitivity workloads, and an external KMS or KMaaS for regulated data, with HSM or MPC custody underneath.
For a vendor-by-vendor view of the market, see our KMS buyer's guide. For head-to-head comparisons, see DuoKey vs Thales CipherTrust and DuoKey vs Entrust.
How much control you keep over a cloud or SaaS key falls into three levels:
An enterprise key management system should support all three, because you will use all three: provider-managed keys for low-risk data, BYOK where the provider only offers import, HYOK for the data that must stay out of reach of the provider.
| Model | Who holds custody | Who can technically access keys | Operating cost | Availability | Compliance evidence |
|---|---|---|---|---|---|
| On-premises HSM | You | Your HSM administrators | High: hardware, data centre, specialist staff, refresh cycles | You design HA (clusters, sites) | Strong hardware evidence; lifecycle and access logs built by you |
| Cloud HSM | You, on provider hardware | Your partition users; provider runs the hardware | Medium to high: per-HSM pricing, you run clustering and key ops | Provider SLA plus your cluster design | Hardware evidence available; provider is in the trust chain |
| Cloud provider KMS | Provider, under your policies | Provider-managed service; you control IAM policy | Low: per-key and per-request pricing | Provider SLA, high | Good native logs, but per cloud; provider holds the key |
| External / independent KMS (self-run) | You | Your KMS operators | Medium to high: you run software, HA and backups | You design HA | Single lifecycle and audit trail across clouds, if integrations exist |
| KMaaS (independent) | You (policy), vendor runs the service | Depends on design: vendor operators may or may not reach key material | Low to medium: subscription | Vendor SLA | Central audit across clouds and SaaS; check what the vendor can see |
| MPC-based KMS | Shared across independent shards | No single operator or host holds a complete key | Low to medium as a service | Threshold design tolerates loss of some nodes | Central audit; custody evidence rests on share separation |
Read the table by the question regulators ask: who could decrypt your data without you knowing? With cloud provider KMS, the answer includes the provider; with MPC, an attacker or insider has to compromise several independent shards, not one.
As an example of external keys in a cloud, an AWS KMS external key store (XKS) is backed by an external key manager you own outside AWS; AWS KMS talks to it only through an external key store proxy, "cannot create, view, manage, or delete your keys", and uses double encryption so neither AWS KMS nor the external key owner can decrypt alone. AWS is also clear about the trade-off: you take on responsibility for the availability, durability and latency of key operations.
An enterprise KMS is only as useful as the systems it can plug into. Three families of interface cover most of the estate.
PKCS#11 (Cryptoki) is the C-level API that applications, databases, web servers and vault software use to talk to an HSM or HSM-like token. It is maintained by OASIS; the current version, PKCS #11 Specification Version 3.2, became an OASIS Standard on 3 June 2026. If a product says it supports "HSM integration", it usually means PKCS#11.
The Key Management Interoperability Protocol is a wire protocol between key management servers and clients (storage arrays, databases, backup systems, hypervisors). KMIP Specification Version 2.1 has been an OASIS Standard since 14 December 2020. KMIP is where key lifecycle operations (create, register, locate, activate, revoke, destroy) are standardised across vendors. VMware vCenter, for example, uses a KMIP key provider for VM and vSAN encryption; see our vSphere key provider guide.
Hyperscalers, SaaS vendors and databases expose their own external-key hooks: AWS XKS, Microsoft 365 Double Key Encryption and Customer Key, Snowflake Tri-Secret Secure, Oracle TDE, SQL Server EKM. These are proprietary, so the practical test for an enterprise KMS is the list of integrations it already ships.
FIPS 140-3, Security Requirements for Cryptographic Modules (published 22 March 2019), defines four increasing, qualitative security levels for cryptographic modules and aligns with ISO/IEC 19790:2012. Modules are validated under the Cryptographic Module Validation Program (CMVP), run jointly by NIST and the Canadian Centre for Cyber Security; accredited labs test the module and CMVP reviews and validates the result.
Three practical points for buyers:
In an HSM, the complete key exists inside one tamper-resistant boundary. That boundary is strong, but it's a single point of trust: whoever controls the device, its administrators or its partition credentials controls the key.
Multi-party computation removes that single point. Each key is split into shares held by independent nodes. Signing or decryption is computed jointly from the shares, and the full key is never reconstructed. In a threshold scheme, a defined number of shares must cooperate for any operation, which gives two properties at once:
MPC and HSMs aren't mutually exclusive: shares can themselves be protected by HSMs, and HSMs remain the right answer where a mandate requires a validated hardware boundary. For a detailed comparison of security architecture, performance and cost, see MPC vs HSM key management.
| # | Criterion | What to ask |
|---|---|---|
| 1 | Custody model | Who can technically use or export a complete key: you, the vendor, the cloud provider? |
| 2 | Separation from data holders | Is the key held outside the provider that stores the data (HYOK)? |
| 3 | Integrations | Which clouds, SaaS platforms and databases are supported today, not on the roadmap? |
| 4 | Standard interfaces | PKCS#11 library? KMIP server version? |
| 5 | Lifecycle model | Are SP 800-57 states (pre-activation, active, suspended, deactivated, compromised, destroyed) represented? Are cryptoperiods enforced? |
| 6 | Rotation without downtime | Can keys rotate while old versions still decrypt existing data? |
| 7 | Audit | Is every operation logged centrally, tamper-evidently and exportable to your SIEM? |
| 8 | Access control | RBAC only, or also attribute-based policies (ABAC)? Dual control for destructive actions? |
| 9 | Multi-tenancy | Are business units, subsidiaries or customers isolated by tenant? |
| 10 | High availability | What happens if a node, region or the vendor is unavailable? What's the documented SLA? |
| 11 | Latency | What's the added latency per operation, for the services that call it synchronously? |
| 12 | PQC readiness | Can it manage ML-KEM and ML-DSA keys and hybrid modes, and switch algorithms by policy? |
| 13 | Hardware assurance | Which backends hold keys, and which hold a current FIPS 140-3 certificate? |
| 14 | Exit and portability | Can you export, re-wrap or migrate keys if you change vendor? |
| 15 | Pricing model | Per key, per operation, per integration or flat? How does cost scale with key sprawl? |
Criterion 12 deserves attention in 2026. Post-quantum key encapsulation changes key sizes and handling; our ML-KEM key management guide covers what changes in practice. To turn these criteria into a tender, use our KMS RFP template.
Enterprise key management is rarely a big-bang project. The organisations that finish it usually go system by system.
DuoKey is built around one idea: no cloud provider, operator or compromised host should hold a complete key.
For anything not listed here, such as specific certifications or pricing, contact DuoKey directly.
Q: What is enterprise key management?
Enterprise key management is the centralised management of cryptographic keys across an organisation's applications, clouds and SaaS services. It covers generation, storage, use, rotation, revocation and destruction under one policy and one audit trail, instead of a separate console per provider.
Q: What is a key management system (KMS)?
A key management system is the software, often backed by hardware, that generates keys, stores them or delegates storage to an HSM, controls who may use them, performs cryptographic operations through an API and logs every action. Cloud KMS services are key management systems limited to one cloud; an enterprise KMS covers the whole estate.
Q: What is key management as a service (KMaaS)?
Key management as a service is a key management system delivered as a managed service: the vendor runs availability, scaling and patching, and you keep control of key policy. Cloud provider KMS is one form; an independent KMaaS runs outside the cloud or SaaS provider whose data it protects, which keeps the key separate from the data.
Q: KMS vs HSM: what is the difference?
A KMS manages the lifecycle and access policy of keys across systems and exposes them through APIs. An HSM is a tamper-resistant device that stores keys and runs cryptographic operations inside a hardware boundary. Many KMS deployments use an HSM as the storage backend, so the two are complementary.
Q: What is the difference between BYOK and HYOK?
With BYOK you create the key in your own KMS or HSM and import it into the provider's KMS, so the provider holds a copy while it is in use. With HYOK the key stays in your external KMS and the provider has to call it for each operation, so revoking access in your KMS stops decryption.
Q: What is MPC key management?
MPC key management splits each key into shares held by independent nodes and computes cryptographic operations jointly, so the full key is never assembled in one place. Compromising one node, operator or cloud account gives an attacker a share, not a usable key.
Q: What does NIST say about the key lifecycle?
NIST SP 800-57 Part 1 Rev. 5 divides the lifecycle into pre-operational, operational, post-operational and destroyed phases, with keys in the pre-activation, active, suspended, deactivated, compromised or destroyed states. It also defines cryptoperiods, the time a key is authorised for use, and the factors that should set them.
Q: Is FIPS 140-2 still valid in 2026?
CMVP states that FIPS 140-2 validations move to the Historical list after 21 September 2026, after which agencies may only keep using those modules in existing systems. New procurements should ask for FIPS 140-3 certificates.
Q: Do I still need an HSM if I use an MPC-based KMS?
Not always. MPC removes the single point of trust that an HSM represents, but some mandates require a validated hardware boundary. Many organisations combine both: MPC for distributed custody and HSM-backed vaults where hardware validation is required.
Enterprise key management means one lifecycle, one access model and one audit trail across the key stores you already have, with no single provider, operator or host able to decrypt your data alone.
Written by
DuoKey Team
Related Resources
Tell us where control is difficult today. We will help you identify a practical next step.
