Quantum-Safe Key Import Lands in Google Cloud KMS

Quantum-safe key import in Cloud KMS lets you wrap customer-supplied keys in transit with post-quantum cryptography, so a Store-Now-Decrypt-Later attacker cannot harvest them today and decrypt them with tomorrow's quantum computer. In August 2026, Google Cloud announced the preview of quantum-safe key import in Cloud KMS for software keys. It's a small change to your import flow with an outsized payoff. At Van Data Team, we help teams adopt this kind of control without disrupting the pipelines that depend on it.

Key Takeaways

• In August 2026, Google Cloud previewed quantum-safe key import in Cloud KMS for software keys, wrapping customer-supplied keys in transit with post-quantum cryptography.
• The wrapping uses NIST-standardized ML-KEM (FIPS 203) in three hybrid options, X-Wing, ML-KEM-768, and ML-KEM-1024, layered with classical AES-256-GCM.
• It directly targets Store-Now-Decrypt-Later attacks, where an adversary records key material today to break it with a future quantum computer.
• The big win is scope: you keep your existing Bring-Your-Own-Key pipelines and downstream KMS integrations, and only swap the wrapping mechanism.
• Van Data Team's recommendation: inventory your long-lived secrets and data first, then protect those import paths in the preview, since the feature is not yet GA.

What Did Google Cloud Actually Ship?

Google shipped a quantum-safe way to get your own key into Cloud KMS, not a change to how the key works once it's there.

Reported fact: In August 2026, Google Cloud announced the preview of quantum-safe key import in Cloud KMS for software-based keys. When you import a customer-supplied key, Cloud KMS wraps it in transit. Historically that wrapping used RSA, a classical algorithm a large quantum computer could eventually break. The preview replaces that wrap with a post-quantum one.

Google also made a related tool, Cloud KMS PQC insights, GA. It categorizes your asymmetric keys by algorithm so you can see, at a glance, what still relies on classical cryptography and needs a migration plan.

Van Data Team analysis: Notice how narrow and how deep this is at the same time. It changes exactly one step, the transit wrapping during import, and leaves everything downstream untouched. That's what makes it adoptable. The depth is that this one step is where a harvested key would leak, so protecting it closes a real gap without asking you to rebuild anything.

What Problem Does Quantum-Safe Key Import Solve?

It solves a problem that hasn't fully arrived yet, which is exactly why it matters now: Store Now, Decrypt Later.

In an SNDL attack, an adversary doesn't try to break your encryption today. They capture the encrypted traffic, key material above all, and store it. The bet is simple: within a few years, a powerful quantum computer will exist, and they'll decrypt the whole archive at once. Anything with a long secret lifetime is a target, because the attacker only needs it to still be secret when that machine arrives.

Import traffic is a particularly rich target. A single wrapped root or operational key can unlock large amounts of downstream data. If that wrap is classical RSA, a future quantum computer breaks it, and every record that key protects is exposed retroactively.

Van Data Team analysis: This is why "quantum computers don't exist yet" is the wrong reason to wait. The attack happens in two parts, and the first, harvesting, is happening today with cheap network capture. Post-quantum wrapping is how you make sure the second part, decryption, never pays off. You're defending a recording made now against a machine built later.

How Does the Quantum-Safe Wrapping Work?

The wrapping is hybrid by design, which means it uses both a classical and a post-quantum layer, and an attacker has to break both.

At import time, Cloud KMS uses NIST-standardized ML-KEM, the Module-Lattice Key-Encapsulation Mechanism defined in FIPS 203, to encapsulate the key. You can choose among three options: X-Wing, ML-KEM-768, and ML-KEM-1024. X-Wing pairs the classical X25519 algorithm with ML-KEM-768, giving you one primitive that is strong against both classical and quantum attacks.

Under the hood, the construction follows Hybrid Public Key Encryption from RFC 9180. It derives keys with HKDF-SHA-256 and wraps the payload with AES-256-GCM, a proven classical symmetric cipher. The post-quantum KEM protects the key exchange; the AES layer protects the data.

Van Data Team analysis: The word doing the work here is hybrid. A purely post-quantum scheme would be a bet that the new algorithm has no undiscovered weakness. A hybrid scheme means that even if ML-KEM were later found flawed, the classical X25519 or AES layer still stands, and vice versa. For something as consequential as a root key, that belt-and-suspenders design is the responsible default, and it's the one Google chose.

How Does Quantum-Safe Key Import Fit Google's PQC Roadmap?

Quantum-safe key import isn't a one-off. It's the newest piece of a multi-year push to make Cloud KMS post-quantum across every operation.

Reported fact: Google has already shipped quantum-safe digital signatures in Cloud KMS, using NIST's ML-DSA (FIPS 204) and SLH-DSA (FIPS 205), and quantum-safe Key Encapsulation Mechanisms based on ML-KEM. Key import is the piece that protects a key on the way in, complementing signatures that protect data integrity and KEMs that protect data exchange. Each covers a different operation, and together they close the loop.

The three primitives map to three distinct jobs:

• Signatures (ML-DSA and SLH-DSA): a signature can't be forged by a quantum attacker, protecting data integrity.
• Encapsulation (ML-KEM): a key exchange can't be broken later, protecting data in transit between parties.
• Quantum-safe key import: a customer-supplied key is wrapped on the way in, so a harvested import can't be unwrapped.

All three are NIST-standardized, which matters for anyone whose compliance framework will eventually require named algorithms, not a vendor's promise. FIPS 203 covers ML-KEM, FIPS 204 covers ML-DSA, and FIPS 205 covers SLH-DSA, so the names on your audit checklist and the names in Cloud KMS already line up.

Van Data Team analysis: The pattern here is worth internalizing, because it's how post-quantum migration actually happens: operation by operation, not in one flag day. Signatures first, then encapsulation, now import. If you treat each one as it ships, you spread the work across releases and never face a single overwhelming cutover. The teams that struggle are the ones that ignore every announcement until an auditor forces all of it at once.

Who Should Care About Quantum-Safe Key Import?

Any team that imports its own keys into Cloud KMS and holds secrets with a long shelf life should care, and that's more teams than it sounds.

• DevSecOps teams running BYOK pipelines. If you automate key import as part of provisioning, this is a wrapping-mechanism swap you can bake into the pipeline.
• Cloud security architects with compliance mandates. Post-quantum requirements are moving from roadmap slides to audit checklists, and this is a concrete control you can point to.
• Regulated industries with long data-retention rules. Finance, healthcare, and government hold data that must stay secret for a decade or more, exactly the SNDL sweet spot.
• Anyone with long-lived root keys. A root key protects everything beneath it, so its transit is worth over-protecting.

Van Data Team analysis: If your secrets are short-lived and your data isn't sensitive past next quarter, you can reasonably wait for general availability. The urgency scales with confidentiality lifetime. The longer a secret must stay secret, the more a recording of it made today is worth to a patient attacker, and the more a quantum-safe wrap is worth to you.

Does Adopting It Mean Re-Architecting Your Pipelines?

No, and that's the point that matters most in practice. The feature was designed so the wrapping is the only thing that changes.

Your Bring-Your-Own-Key import flow stays the same shape. Your downstream Cloud KMS API integrations, the calls that encrypt, decrypt, and sign once the key is imported, don't change at all. What changes is the algorithm used to protect the key while it's in transit into KMS. That's a deliberately small blast radius.

For automated pipelines, this means you can migrate to quantum-resistant wrapping as a configuration change, not a redesign. You point the import step at a post-quantum wrapping method and validate that the imported key lands correctly. The rest of your system is none the wiser, which is exactly what you want from a security upgrade.

Van Data Team analysis: The best security controls are the ones nobody downstream has to think about. Because this one sits entirely at the import boundary, you can roll it out as an infrastructure change owned by the platform team, without asking every application that uses a key to change a line. That's the difference between a control that ships and one that stalls in review for a quarter.

Classical Versus Quantum-Safe Key Import

The contrast is easiest to see side by side. The table shows what actually changes, and what doesn't.

| Dimension | Classical key import | Quantum-safe key import | | --- | --- | --- | | Transit wrapping | RSA, a classical algorithm | ML-KEM hybrid (X-Wing, ML-KEM-768, or -1024) | | SNDL exposure | Harvested wrap breaks under a future quantum computer | Wrap stays secure against classical and quantum attacks | | Standard | RSA-based wrapping | NIST FIPS 203, HPKE (RFC 9180), AES-256-GCM | | Your BYOK pipeline | Unchanged | Unchanged | | Downstream KMS calls | Unchanged | Unchanged | | Availability | Generally available | Preview, software keys |

Van Data Team analysis: Read the last three rows together. Your pipeline and your downstream calls don't change, and the only real trade-off is that the quantum-safe path is still a preview. So the decision isn't "is this worth a big migration," because there is no big migration. The decision is "which of my long-lived keys do I want to protect first while this matures."

How Should a Team Get Started?

Start by finding out which of your secrets and data actually need this, because not all of them do. Then protect those first.

• Inventory your keys, and use Cloud KMS PQC insights to see which still rely on classical algorithms.
• Rank data and keys by confidentiality lifetime, the longer something must stay secret, the higher its SNDL risk.
• Pick a hybrid method, X-Wing is a sensible general-purpose default, and test quantum-safe import in a non-production project.
• Validate that the imported key works end to end with your existing downstream calls, since the whole promise is that they're untouched.
• Roll the wrapping change into your BYOK automation for the high-priority keys, and leave the rest for general availability.
• Re-run PQC insights on a schedule, so any newly created classical key shows up before it becomes a long-lived liability.
• Document which hybrid method you chose and why, so the next auditor or engineer inherits a decision, not a mystery.

This is a bounded first pass, not a platform overhaul. The inventory alone is worth doing, because it tells you where your classical cryptography actually lives. From there, protecting the highest-lifetime keys is a small, high-leverage move you can make while the preview matures, much like the incremental hardening we describe in our work on zero data retention and governing agentic AI at scale.

How Van Data Team Helps

Van Data Team treats post-quantum readiness as an inventory-and-priority problem before it's a cryptography problem. We start by mapping which of your secrets and data have a long confidentiality horizon, because that's what decides where quantum-safe wrapping earns its place.

From there, we help you test quantum-safe key import in a non-production project, validate that your existing pipelines and downstream calls are genuinely untouched, and roll the change into your BYOK automation for the keys that need it most. If you want help, our data pipeline development and AI agent development work covers the automation this sits inside. The goal is simple: the recordings an attacker makes of your key traffic today should be worthless, no matter what computer they point at them tomorrow.