Enterprise Key Management: KMS, HSM, KMaaS and MPC Compared (2026 Guide)

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 (KMS, HSM, key management as a service, MPC), walks through the key lifecycle as NIST describes it, compares six deployment models, lists the standards that matter (PKCS#11, KMIP, FIPS 140-3) and ends with a 15-criterion evaluation checklist.

---

Table of Contents

1. Why Enterprise Key Management Matters Now
2. The Key Lifecycle According to NIST SP 800-57
3. KMS, HSM, KMaaS and MPC: Definitions
4. Deployment Models Compared
5. Standards and Interfaces: PKCS#11, KMIP and Cloud KMS APIs
6. FIPS 140-3 and What Validation Means
7. How MPC Changes Key Custody
8. Evaluation Checklist: 15 Criteria
9. How DuoKey Approaches Enterprise Key Management
10. FAQ

---

Why Enterprise Key Management Matters Now

Key sprawl

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:

• No single answer to "who can decrypt this?" Access is spread across cloud IAM policies, HSM partition users and SaaS admin roles.
• Inconsistent lifecycle. One team rotates keys yearly, another never does, a third can't rotate without downtime.
• Weak exit options. If the provider holds both the data and the key, revoking the provider's access to your data isn't really possible.
• Slow audits. Evidence has to be gathered from several consoles and stitched together by hand.

Separation of duties

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.

Regulators expect evidence, not intent

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.

---

The Key Lifecycle According to NIST SP 800-57

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.

Four phases, six states

SP 800-57 divides the key-management lifecycle into four phases, and places each key in one of six states:

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.

Cryptoperiods

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.

---

KMS, HSM, KMaaS and MPC: Definitions

• Key management system (KMS): software that manages the lifecycle and access policy of keys and exposes cryptographic operations through APIs. A KMS may store keys itself or delegate storage to an HSM.
• Hardware security module (HSM): a tamper-resistant hardware device that generates and stores keys and performs cryptographic operations inside its boundary. An HSM is a key store and crypto engine; it isn't, by itself, a lifecycle and policy layer across your estate.
• Cloud HSM: an HSM operated by a cloud provider and dedicated to (or partitioned for) one customer.
• Key management as a service (KMaaS): a KMS delivered as a managed service, so the vendor runs availability, patching and scaling, while the customer keeps policy control. Cloud provider KMS is one form of KMaaS; independent KMaaS runs outside the cloud provider whose data it protects.
• MPC-based KMS: a KMS where each key is split into shares held by independent parties or nodes, and cryptographic operations are computed jointly with multi-party computation, so the complete key is never assembled in one place.

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.

---

Deployment Models Compared

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.

---

Standards and Interfaces: PKCS#11, KMIP and Cloud KMS APIs

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

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.

KMIP

The Key Management Interoperability Protocol is a wire protocol between key management servers and clients (storage arrays, databases, backup systems). 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.

Cloud and SaaS KMS APIs

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 and What Validation Means

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:

• Validation applies to a specific module and version, not to a vendor or a service as a whole. Ask for the certificate number and check it on the CMVP site.
• FIPS 140-2 is being retired. CMVP states that FIPS 140-2 validations move to the Historical list after 21 September 2026; after that, agencies may continue using such modules only for existing systems. In a new procurement, ask for FIPS 140-3.
• Validation covers the module, not your key governance. A validated HSM with uncontrolled administrators or no lifecycle policy doesn't meet the intent of SP 800-57.

---

How MPC Changes Key Custody

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:

• No single point of compromise. Breaching one node, one operator or one cloud account yields a share, not a key.
• Resilience by design. Losing a node doesn't mean losing the key, as long as the threshold is still reachable.

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.

---

Evaluation Checklist: 15 Criteria

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.

---

How DuoKey Approaches Enterprise Key Management

DuoKey is built around one idea: no cloud provider, operator or compromised host should hold a complete key.

• MPC key custody. DuoKey KMS splits every key across independent shards with multi-party computation, so no cloud provider, operator or compromised host holds a complete key.
• One console for every backend. DuoKey Cockpit manages vaults backed by software, MPC, HSM or cloud KMS from one console and API. Securosys HSM-backed vaults are available where you need FIPS-validated hardware custody.
• Governance. A cryptographically chained audit log, RBAC plus ABAC policies, and tenant isolation.
• Standard interfaces. A KMIP 2.1 server endpoint and a PKCS#11 library for applications and vault software.
• Integrations. Microsoft 365 Double Key Encryption and Customer Key, AWS XKS, Salesforce, ServiceNow, Snowflake Tri-Secret Secure, Oracle TDE, SQL Server EKM, OpenBao and HashiCorp Vault, Varonis and Genesys. The full list is on the DuoKey integrations page.

For anything not listed here, such as deployment regions, certifications or pricing, contact DuoKey directly.

---

FAQ

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 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 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: What are PKCS#11 and KMIP?

PKCS#11 is the OASIS-maintained API applications use to talk to HSMs and HSM-like tokens; version 3.2 became an OASIS Standard in June 2026. KMIP is the OASIS protocol between key servers and clients such as storage and databases; version 2.1 is an OASIS Standard from December 2020.

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.

---

Conclusion: From Key Sprawl to One Key Policy

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.

• Inventory every place keys live today: cloud KMS, HSMs, SaaS, databases, vaults
• Decide which data must have keys held outside its provider (HYOK)
• Map key states and cryptoperiods to NIST SP 800-57 Part 1 Rev. 5
• Require PKCS#11 and KMIP support, plus the cloud and SaaS integrations you actually use
• Ask for FIPS 140-3 certificates for any hardware backend
• Choose a custody model: HSM, cloud KMS, external KMS, KMaaS or MPC
• Score vendors against the 15 criteria above, including PQC readiness

---

References

• NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1 – General
• NIST SP 800-57 Part 1 Rev. 5 (PDF)
• NIST FIPS 140-3, Security Requirements for Cryptographic Modules
• NIST Cryptographic Module Validation Program (CMVP)
• OASIS PKCS #11 Specification Version 3.2
• OASIS Key Management Interoperability Protocol Specification Version 2.1
• AWS KMS Developer Guide: External key stores