CONTEXTUAL TRUST RESEARCH
Customer Key Management and Quantum Readiness Across AWS Google Cloud and Azure
Published 3 November 2026. Written as at 3 November 2026.
A customer-managed key, an HSM-backed key and a quantum-resistant system are different things. An HSM protects key material and cryptographic operations within a defined boundary. Customer key management allocates authority over a key's lifecycle. Quantum readiness concerns the algorithms and protocols throughout the system, including communications, signatures, imports, backups and recovery.
An enterprise buying an HSM without mapping these dependencies can acquire stronger custody while retaining vulnerable public-key exchanges or an untested recovery path. Contextual Trust's proposed approach begins with the data and business service being protected, then evaluates the key service against the actual control requirement.
Define customer control before choosing a product
Customer-managed generally means the customer configures a key resource and its lifecycle and access policies. It does not necessarily mean that the customer exclusively possesses the key material or operates the hardware. Imported key material changes generation and import responsibilities. External key custody retains key material in a separate system and makes that system part of the availability dependency. These arrangements need separate threat and operating models.
Ask who may generate, import, use, rotate, disable, recover and destroy a key. Separate cryptographic users from administrators and recovery custodians. Identify emergency authority, quorum requirements and independent logs. A principal permitted to decrypt business data remains dangerous even when it cannot export the underlying key.
AWS starts with several distinct choices
AWS KMS key stores distinguish standard KMS from CloudHSM-backed and external custom stores. Customer-managed encryption does not necessarily require a dedicated cluster.
| AWS option | Control objective | Operational consequence |
|---|---|---|
| Standard KMS customer-managed key | Managed key lifecycle and service integration | Customer still owns policies, application permissions and recovery planning |
| Imported material in supported KMS configurations | Customer-controlled generation/import | Plan material expiry, reimport and durable recovery dependencies |
| CloudHSM used directly by an application | Dedicated HSM boundary and supported cryptographic interfaces | Application integration, cluster operations and availability need explicit ownership |
| KMS custom store backed by CloudHSM | KMS interface with customer-managed HSM custody | Different feature, quota, recovery and availability constraints from standard KMS |
| KMS external key store | Required custody outside AWS | External manager, proxy and network become dependencies for cryptographic operations |
KMS custom stores currently support symmetric encryption keys only. Do not infer that a post-quantum algorithm supported directly by CloudHSM is therefore available through the KMS custom-store interface. Custom-store restrictions include asymmetric keys, automatic rotation and multi-Region keys. External custody adds operating dependencies.
Compare responsibilities across clouds
These are candidate service families, not interchangeable products or a vendor ranking. Validate the workload integration, region, release stage, key origin and protection level before procurement.
| Decision | AWS | Google Cloud | Microsoft Azure |
|---|---|---|---|
| Managed key service | KMS | Cloud KMS | Key Vault and service-specific customer-managed-key integration |
| HSM-backed path | Standard KMS protection; CloudHSM and custom stores for distinct requirements | Cloud HSM protection levels within the Cloud KMS model | Key Vault Premium HSM keys or separate Managed HSM |
| Dedicated custody requirement | Evaluate CloudHSM and the exact interface | Evaluate documented single-tenant HSM protection and regional availability | Managed HSM documents a single-tenant security domain |
| External custody | KMS external key store with proxy | Cloud EKM with supported external manager | Assess the target Azure service and supported architecture; do not assume a generic XKS-equivalent |
| Acceptance evidence | Policy/use logs, recovery and service integration tests | IAM, protection level, supported purpose and EKM dependencies | Data/control-plane roles, security-domain recovery and service support |
Google's Cloud EKM documentation describes keys managed outside Google Cloud and the supported connection arrangements. Microsoft's Key Vault overview of keys distinguishes software and HSM protection; Managed HSM is a separate single-tenant service. These distinctions matter more than placing three vendor logos under one generic HSM box.
What quantum resistance actually requires
NIST's approved post-quantum standards separate key establishment from signatures: ML-KEM establishes shared secrets, while ML-DSA and SLH-DSA provide signatures. A signature does not encrypt a lakehouse. A KEM does not by itself define a complete application encryption protocol.
The status below is based on documentation checked on 3 November 2026, not an executed tenant test or regional availability attestation.
| Service evidence | Verified scope | What it does not establish |
|---|---|---|
| AWS KMS key-spec documentation lists ML-DSA and ML-KEM | Named asymmetric signing and key-establishment capabilities | Every AWS storage integration, client and connection automatically uses PQC |
| AWS CloudHSM CLI documents ML-DSA; FIPS mode on hsm2m.medium is documented from 1 September 2026 | A specified algorithm and cluster mode | Equivalent support in every SDK/interface or in KMS custom stores |
| Google Cloud KMS algorithm catalogue lists PQ signing and KEM algorithms under software protection | Explicit algorithm/purpose/protection combinations | That these PQ operations execute inside Cloud HSM |
| Azure Key Vault key documentation describes 256-bit AES as quantum-resistant | Symmetric encryption capability in the specified services; Key Vault Premium AES is marked preview | RSA/EC become resistant or Managed HSM provides an undocumented ML-KEM/ML-DSA endpoint |
HSM validation concerns the specified cryptographic module boundary and configuration; it is not a blanket post-quantum certificate for an application. The Azure pages checked do not establish native ML-KEM or ML-DSA availability in Managed HSM. That is a verification gap for a proposed deployment, not proof of permanent absence across all Azure services. Do not substitute an SDK demonstration or roadmap for an operational service guarantee.
Trace the entire envelope
In envelope encryption, data is encrypted with a data-encryption key; a key-encryption key protects that key. An authorised application typically obtains plaintext data or a plaintext data key at some point in processing. Protect its memory, identity and egress as well as the HSM. A key service cannot make plaintext safe after an authorised but compromised workload receives it.
Build a cryptographic dependency inventory covering data classification and confidentiality lifetime; data and wrapping algorithms; key versions and origin; TLS/key exchange on each hop; certificate and software-signing chains; import/export wrapping; replicas, caches and backups; and recovery credentials. Long-lived sensitive data makes capture-now/decrypt-later exposure relevant to vulnerable transport and key-establishment paths. Upgrading storage encryption alone does not repair previously captured vulnerable traffic.
Evaluate an approved protocol implementation rather than assembling cryptographic primitives in application code. Record whether a hybrid mechanism is used, which participants support it and how downgrade is detected. A single successful handshake proves only that particular connection, not every proxy, backup or administrative route.
A fictional migration decision
Illustrative scenario: fictional, with no measured result or customer deployment.
A research organisation needs long-term confidentiality for archived designs and verifiable approval records. Its AWS application already uses standard KMS envelope encryption. The initial requirement says only “move keys into CloudHSM to become quantum-safe”.
Discovery separates three requirements: dedicated key custody, long-lived confidentiality and durable signature verification. The security owner decides whether dedicated custody is actually required. The engineering team separately evaluates supported PQ transport/key-establishment paths and signing services. A CloudHSM pilot cannot close the transport requirement, and an ML-DSA signature cannot close the encryption requirement.
A recovery exercise then reveals that a dependent verifier cannot consume the proposed signature format. Migration is held for that path while the verifier and evidence-retention design are updated. Any temporary exception is time-bounded, owned and recorded; it is not labelled complete quantum resistance. Baseline coverage, latency, cost and recovery time remain unknown until measured.
Rotation recovery and exit are part of key management
Key rotation does not necessarily re-encrypt existing ciphertext or remove dependencies on old versions. Prove the required behaviour in the exact service and application. Retain old decryption capability for the approved retention period, test restoration and avoid destroying a key before every relevant dependent copy has been assessed.
Disabling an external key can prevent subsequent key operations, but it is not an instantaneous global data kill switch: plaintext, cached data keys or decrypted exports may already exist. Test the effective revocation boundary and cache lifetime. A key-manager outage must not trigger a fallback to an unapproved plaintext or weaker-key path.
Cost comparisons should include service requests, provisioned HSM capacity, availability/recovery infrastructure, external-manager licensing, networking, engineering, on-call support, evidence retention and migration/exit work. No cross-cloud price ranking is defensible without a stated region, workload and operating model.
A practical review package
Start with a bounded service and synthetic data. Produce a custody/responsibility matrix, dependency inventory, algorithm/protection-level evidence, permission tests, a restore/revocation exercise and an exit plan. Agree which claims the evidence can support. Measure inventory coverage, approved-algorithm coverage, restoration success and unresolved dependency count with a named owner and review date; do not present an unmeasured readiness score as certification.
Contextual Trust can use this as a proposed assessment scope. This article does not establish a deployed key-management service, vendor partnership, completed customer migration or guaranteed quantum resilience. The scope workflow supports an enquiry; never submit private keys or credentials.
Technical references
- AWS KMS key specifications.
- AWS CloudHSM ML-DSA CLI and cluster-mode conditions.
- AWS external-key-store key restrictions.
- Google Cloud KMS algorithm and protection-level matrix.
Educational architecture guidance. Selection and migration require organisation-specific cryptographic, security, legal, operational and governance review and appropriate approval.