Encryption is only as strong as the management of its keys, and most encryption purchases are really key management decisions in disguise. Buyers choose between cloud key management services, dedicated hardware security modules (HSMs), external key managers and application or database encryption layers, often with overlapping features and very different operating models. This vendor-neutral guide helps security architects, data protection leads and procurement teams define requirements, compare options on FIPS 140-3 validation, KMIP interoperability, BYOK and HYOK, and post-quantum readiness, and run a proof of concept that tests the claims. Background on algorithms and modes is in the Encryption Guide.
Key takeaways
- Decide who must control the keys before comparing products: provider-managed, customer-managed in the provider's KMS, imported (BYOK) or held outside the provider (HYOK) are different risk and availability models.
- Check validation, not marketing: ask for the CMVP certificate number and confirm the module, version and FIPS 140-3 security level on the NIST list.
- More control means more outage risk. With externally held keys, if your key manager is unreachable the provider cannot decrypt your data, and a permanent loss makes data unrecoverable.
- Interoperability limits lock-in: KMIP and PKCS#11 support, key export policy and documented migration paths matter as much as features.
- Buy for crypto-agility: NIST plans to deprecate 112-bit RSA and elliptic-curve schemes after 2030 and disallow quantum-vulnerable algorithms after 2035, so ask for a post-quantum roadmap with dates.
Define requirements
- Data and use cases: list what is being protected (storage volumes, databases, files, application fields, backups, tokens and signing) and where it lives (each cloud, SaaS, on-premises). Use the Data Classification Guide to decide which data needs customer-controlled keys.
- Threats addressed: be explicit. Storage encryption protects against lost media and some provider-side access; it does not stop an attacker using a valid application identity, which reads data in clear. Field-level or application encryption narrows that exposure.
- Compliance drivers: FIPS 140-3 for US federal and many regulated buyers, PCI DSS key management requirements, data residency and sovereignty rules that may require keys to stay in a jurisdiction or outside the cloud provider.
- Key control model: provider-managed keys, customer-managed keys in a cloud KMS, BYOK (you generate and import key material, the provider still holds it), or HYOK (key material never leaves a key manager you operate).
- Machine access: every encrypt and decrypt call is made by a workload identity. Define how services authenticate to the key service and how those permissions are reviewed. See the Cryptographic Key Management Guide.
- Operations: availability target, latency budget, regions, disaster recovery, staff skills for running HSMs, and the size of your key estate (a Cryptographic Inventory and CBOM Guide exercise gives the numbers).
Capability areas
| Option | Strengths | Limitations | Fits when |
|---|---|---|---|
| Cloud KMS (provider or customer-managed keys) | Native integration with storage and database services, IAM-based policy, automatic rotation, low operational effort | One provider per service; provider operates the HSMs; cross-cloud consistency is your problem | Most cloud workloads; small and mid-sized teams |
| Cloud dedicated or managed HSM | Single-tenant HSM partitions in the provider's data centre, PKCS#11 and similar interfaces, stronger isolation | More operational work, higher cost, fewer native integrations | Regulated workloads, CA and signing keys, custom applications |
| On-premises HSM (network or PCIe) | Full physical and administrative control, broad API support, long track record for PKI, payments and code signing | Hardware lifecycle, clustering, firmware patching, specialist skills | Root CAs, payment keys, sovereignty or air-gapped needs |
| Enterprise or external key manager | One policy and audit plane across clouds and on-premises, KMIP for storage and databases, HYOK connectors to cloud KMS | Another critical dependency; availability directly affects cloud data access | Multi-cloud estates, HYOK and sovereignty requirements |
| Application, database and file encryption layers | Field-level or tokenised protection that survives a database or storage compromise, transparent database encryption options | Application changes, search and indexing limits, performance cost | High-value fields (payment, health, identity data) |
One reference point on the HYOK trade-off: AWS documents that keys in its external key store are used through a customer-operated proxy, that a disconnected key manager stops decryption and a permanent loss makes ciphertext unrecoverable, and it recommends a round trip of 35 ms or less. It also states that for most workloads the extra operational burden will exceed the perceived benefit. Ask every provider for the equivalent documentation.
Evaluation criteria
| Criterion | What good looks like | How to verify |
|---|---|---|
| FIPS 140-3 validation | Current CMVP certificate covering the exact module and firmware version, at the security level you need (Level 3 is common for HSMs) | Search the CMVP validated modules list; check the security policy document and certificate status |
| FIPS 140-2 legacy | A FIPS 140-3 path for any product still relying on 140-2 | CMVP moved 140-2 modules to the Historical list after 21 September 2026; they are acceptable for existing systems only |
| Interoperability | KMIP (version 2.1 is the current OASIS Standard), PKCS#11, REST APIs, cloud KMS connectors | Test a KMIP client (storage array or database) and a PKCS#11 application in the PoC |
| Key control and portability | Clear BYOK import process, HYOK option where required, documented export or migration policy for non-extractable keys | Walk through migrating a key set to another provider on paper |
| Access control and separation of duties | Separate roles for key administrators and key users, quorum or dual control for sensitive operations, workload identity authentication rather than static API keys | Inspect role model; attempt a decrypt with an admin-only role |
| Lifecycle | Automatic rotation, versioning, scheduled deletion with waiting period, key states that match NIST SP 800-57 | Rotate and disable keys in the PoC and check dependent services |
| Audit and monitoring | Every key use logged with caller identity, exportable to SIEM in near real time | Generate operations and trace them in your SIEM |
| Availability | Multi-region or clustered design, documented RTO and behaviour when unreachable, caching rules for data keys | Fail a node or connection during the PoC |
| Post-quantum readiness | Roadmap for FIPS 203 ML-KEM, FIPS 204 ML-DSA and FIPS 205 SLH-DSA, firmware upgradeable algorithms, hybrid support where relevant | Ask for dates and whether PQC algorithms will be inside the validated boundary |
Questions to ask vendors
- What is the CMVP certificate number for the module we would use, at which FIPS 140-3 security level, and which firmware versions does it cover?
- Can your staff, or anyone acting for a government request, use our keys or read our key material? What technical controls enforce that?
- Do you support BYOK, HYOK or both, for which services, and what stops working (rotation, multi-region keys, asymmetric keys) under each model?
- Which KMIP version and profiles, and which PKCS#11 version, do you support, and which client products have you tested?
- How do workloads authenticate to the key service without a stored secret, and how are those permissions audited?
- What happens to applications if the key service or our external key manager is unreachable for one hour, and for one week?
- How would we move all keys and encrypted data to another provider, and what is non-exportable by design?
- When will ML-KEM and ML-DSA be available, inside the validated module boundary, and can existing hardware be upgraded by firmware?
- How are firmware updates signed, delivered and validated, and what is your vulnerability disclosure process?
Red flags
- "FIPS compliant" or "uses FIPS-validated algorithms" with no CMVP certificate number for the module itself.
- A FIPS 140-2 certificate offered with no dated FIPS 140-3 plan.
- Root or master keys that support staff can export or recover without customer approval.
- Applications authenticating to the key service with long-lived static API keys or shared credentials.
- No per-operation audit log, or logs that omit the calling identity.
- No documented exit path, or proprietary key formats that prevent migration.
- A post-quantum answer that is a marketing statement with no algorithms, standards or dates.
Proof of concept
- Pick representative workloads: one cloud storage or database service with customer-managed keys, one KMIP client (storage or database), one PKCS#11 application such as a signing service, and one application using field-level encryption.
- Configure the intended key control model (customer-managed, BYOK or HYOK) and confirm key material handling matches the vendor's documentation.
- Authenticate each workload using its platform identity and confirm least-privilege policies block an unauthorised decrypt.
- Rotate a key, disable a key and schedule a deletion; confirm dependent services behave as expected and can be restored before deletion completes.
- Simulate loss of connectivity to the key service or external key manager; measure impact, cached behaviour and recovery time.
- Trace every operation into your SIEM with the caller identity and measure latency against your budget.
- Verify the CMVP certificate, security policy and firmware version of the exact module used in the test.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support for key management and encryption programmes, including the machine identities that use the keys. Browse vendors in our NHI and AI products directory or contact us.
Related NHI Mgmt Group resources: Cryptographic Key Management Guide · Secrets Management Buyer's Guide · Post-Quantum Cryptography Migration Guide · Crypto-Agility Guide