Quantum-safe BYOK is here — and it quietly changes your key management design

Google Cloud shipped quantum-safe key import in Cloud KMS. Here’s why it matters even if you never touch GCP.

The short version

Google Cloud has put quantum-safe key import into preview for software-based keys in Cloud KMS (announced 21 August 2026), alongside PQC posture insights that are now GA. It follows their earlier PQC work on digital signatures and key encapsulation, and it’s the first item on the next phase of their published migration timeline.

Translation for the rest of us: the transport of key material — not just the key itself — is now being treated as a post-quantum problem. That’s the part most BYOK/HYOK designs still get wrong.

Why key transport is the uncomfortable bit

Classic BYOK works like this: you generate key material somewhere you trust, wrap it with an RSA public key the cloud provider hands you, and ship it over the wire. That wrapping is classical asymmetric crypto. It’s fine today.

It is not fine against Store Now, Decrypt Later (SNDL). An adversary who captures a wrapped key import today doesn’t need to break anything today. They archive it and wait for a cryptographically relevant quantum computer. When it arrives, they unwrap — and they get your root key material, not one session’s worth of traffic.

That asymmetry is the whole argument. Session traffic ages out. A KEK does not. Anything with a 10–20 year confidentiality requirement — and in Swiss FSI that’s most of it — should be treated as already exposed if it crossed a network under RSA wrapping.

What Google actually built

The mechanism is hybrid public key encryption (HPKE), slotted into the existing import-job API so the workflow barely changes:

1. Import job — client requests an import job specifying a post-quantum HPKE method.
2. Server-side keygen — KMS generates a PQ KEM keypair and publishes the public half.
3. Client-side wrap — client uses Tink or OpenSSL to run HPKE Seal(): encapsulate against the public key, derive an ephemeral AES key via HKDF-SHA256, encrypt the key material.
4. Submit — encapsulated ciphertext concatenated with the encrypted key material goes back to the KMS endpoint.
5. Unwrap — KMS runs HPKE Open() inside its boundary.

Crypto choices: KEM layer is X-Wing, ML-KEM-768 or ML-KEM-1024; KDF is HKDF-SHA-256; symmetric wrap is AES-256-GCM with 12-byte nonces.

Two things worth flagging.

X-Wing is the interesting option. It’s a hybrid — classical X25519 combined with ML-KEM-768. If ML-KEM turns out to have a structural weakness, you still have the classical half. If a CRQC shows up, you still have the lattice half. For anything you’re actually betting compliance on, hybrid is the defensible choice right now, and it’s what most regulators and BSI-style guidance are steering toward. Pure ML-KEM-1024 gives you a higher security category but no fallback.

“Software-based keys” is doing a lot of work in that sentence. This is preview, software protection level. If your key ceremony ends in an HSM-backed key, this doesn’t cover you yet. That’s the gap to watch.

The Microsoft-shop question

If you live in Azure — and most of my clients do — the honest status is that Azure Key Vault and Managed HSM still import BYOK under RSA-HSM wrapping via the KEK exchange. There’s real PQC work happening across the Microsoft stack (SymCrypt has ML-KEM and ML-DSA, TLS hybrid key exchange is rolling out), but a PQ-wrapped import path into Key Vault isn’t something you can put on an architecture diagram today.

So the practical posture:

• Don’t wait for the button. The decision that matters is not “which KEM” — it’s which of my keys must never be recoverable, and did they ever cross a network wrapped in RSA?
• Inventory the import events, not just the keys. Most crypto inventories catalogue algorithms in use. Almost none catalogue historical key transport. That’s the SNDL exposure.
• Re-key what you can’t afford to lose. For long-lived KEKs with a multi-decade confidentiality horizon, plan a rotation that lands after a PQ-safe import path exists. Generating in-place inside the HSM sidesteps the transport problem entirely — if your compliance story allows it.
• Push your provider. If PQ key import is a requirement in your next Key Vault / Managed HSM conversation, say so in writing. Roadmaps move on customer pressure.

Where this sits on the timeline

NIST’s guidance has 112-bit classical security deprecated after 2030 and disallowed after 2035. That sounds far away until you map it against a Swiss bank’s key lifecycle, a core banking migration, and the two years it takes to get a crypto inventory that anyone believes. Key transport is one of the earlier dominoes, because it’s the one where the damage is already done by the time the quantum computer exists.

Google shipping this is less about Google and more about the signal: the industry has moved from “PQC for TLS” to “PQC for the things TLS was protecting.”

Plan accordingly.