PQC Cloud Key Management

Post-quantum readiness in cloud key management services

Most cloud data at rest is protected by AES-256 and is not quantum-vulnerable. The exposure in cloud key management lies elsewhere: in asymmetric keys held for signing, in key import and export, and in the transport protecting the path between your systems and the service.

Where the exposure actually sits

Cloud key management uses envelope encryption. Data is encrypted with a symmetric data key, and the data key is encrypted under a master key held in the service. The bulk encryption is AES, which Grover's algorithm weakens rather than breaks, so AES-256 remains sound.

That leaves four areas of genuine exposure, and they are frequently missed because the headline encryption is fine.

The second row deserves emphasis. Bring-your-own-key workflows wrap the customer's key material under a service-provided public key for transport. Where that wrapping is RSA, an adversary capturing the exchange can recover the key material once the wrapping key becomes derivable, and with it everything that key protects. It is a short exchange that carries very high value, which makes it an attractive harvest now, decrypt later target.

What the providers have shipped

Cloud key management is one of the more advanced areas of post-quantum availability, and in most estates the platform is ahead of the applications using it.

Google Cloud KMS has shipped quantum-safe digital signatures, quantum-safe key encapsulation mechanisms and quantum-safe key import, the last specifically addressing the wrapping exposure described above. AWS supports hybrid post-quantum TLS across service endpoints and has added ML-DSA key specifications to KMS, so post-quantum signing keys can be created and used through the standard sign and verify interface. Microsoft has made post-quantum APIs generally available across its platforms and accelerated its programme target to 2029.

The constraint is therefore rarely platform capability. It is whether the organisation has enabled the capability, and whether its applications and SDK versions can use it. Availability and default behaviour are not the same thing, which is the recurring theme in where PQC support has already shipped.

What to do now

Inventory keys by type, not by count

Separate symmetric data and master keys, which are largely unaffected, from asymmetric keys held for signing or key wrapping, which are not. Most organisations find the asymmetric population is small and high-value, which makes it tractable.

Switch new signing keys to post-quantum specifications

Where the service offers ML-DSA key specifications, use them for new signing keys. Existing keys generally cannot be converted, so this is a rotation exercise rather than an upgrade, and starting with new keys avoids a backlog.

Adopt quantum-safe key import

Where key material is imported into the service, use the quantum-safe import mechanism if the provider offers one. This closes the highest-value exposure in the key management path and is usually a change to the import workflow rather than to anything downstream.

Confirm post-quantum transport is actually negotiated

Availability of hybrid key exchange on service endpoints does not mean your clients use it. Verify the SDK and TLS library versions in use, since the negotiated group depends on the client. OpenSSL 3.5 and Go 1.24 negotiate hybrid groups by default; older runtimes do not.

Decide where keys should live

For material with long confidentiality requirements, holding key material in your own hardware security module, with external or customer-managed key arrangements, keeps the migration decision under your control rather than the provider's. That is a design decision with cost and operational implications, and it is the right one only where the data justifies it.

Secrets managers deserve separate attention

Secrets management services are frequently treated as part of the key management estate and behave differently.

Secrets are typically retrieved far more often than keys are used, over TLS, by applications whose library versions vary widely across an estate. The exposure is therefore concentrated in transport rather than storage, and it depends on the client rather than the service.

Long-lived secrets compound this. A database credential or API key retrieved thousands of times over several years under classical transport has been exposed repeatedly. Rotation limits the value of any single capture, which makes secret rotation cadence a post-quantum control as well as an operational hygiene one.

Multi-cloud and provider timelines

Where an organisation operates across providers, migration proceeds at the pace of the slowest, and the position differs materially between them on specific capabilities such as quantum-safe key import.

Two implications follow. Post-quantum capability should be part of workload placement decisions where the data has a long confidentiality lifetime. And the provider's roadmap should be treated as a supplier dependency on the migration plan, with the same tracking as any other, as covered in how supplier quantum exposure becomes your own.

How Unsung helps

Unsung is a UK-based, vendor-neutral consultancy specialising exclusively in public key infrastructure and cryptographic systems, working across central government, defence, healthcare, financial services, nuclear and transport.

We inventory cloud key material by type and exposure through our PKI health check and cryptographic bill of materials services, covering key import paths and client library versions as well as the keys themselves. Where key custody needs to move under the organisation's control, we design and deliver hardware security module backed arrangements and the key management architecture around them, selected on requirement rather than partner preference.