The Imported Key Travels in a Quantum-Resistant Envelope
Quentir Defense Monitor
Evidence-based insights for quantum defense and security. Published by Quentir Systems LLC · August 23, 2026.
An organization that generates its own encryption keys and imports them into a cloud provider has decided to originate its key material outside the provider rather than rely entirely on provider-generated keys. That posture is called bring your own key, and it is used in some environments subject to data sovereignty rules, defense contracting clauses or classified-adjacent regulations because it lets the customer create key material outside the cloud before importing it. Once imported, however, the material becomes a Cloud KMS key version that Google's service holds and uses. The import process also has one structural weakness that rarely gets discussed: the key has to travel. At some point the customer's key material is wrapped in encryption and sent across a network into the provider's key management service, and everything the key will ever protect may depend on the strength of that single crossing.
Google Cloud has now put a post-quantum floor under that crossing. According to the company's Cloud KMS documentation, a preview of quantum-resistant key import is available for software-backed keys: the customer wraps key material locally in a hybrid public key encryption envelope built on post-quantum key encapsulation, sends the sealed envelope to Cloud KMS, and the service opens it only inside its own boundary. The stated purpose is to defeat the attack pattern known as harvest now, decrypt later, in which an adversary records encrypted traffic today and waits for a future quantum computer to break the classical wrapping. A recorded wrapped key is the densest imaginable version of that target. Whoever breaks one envelope in some future year does not recover one message. They recover the imported key, and potentially the database backups, application secrets and regulated workloads protected under that key, retroactively and silently.
What Google Actually Shipped
The mechanics reward a close look, because they show how mature the post-quantum cryptography toolchain has quietly become. A customer starts by creating an import job through the Cloud KMS API and requesting one of three quantum-resistant import methods. Cloud KMS generates a post-quantum key encapsulation keypair for that job and hands the public half to the customer. Using a supported library such as Tink or OpenSSL, the customer performs an HPKE Seal operation as specified in RFC 9180, the IETF standard that composes a key encapsulation mechanism, a key derivation function and an authenticated cipher into a single sealed envelope. The derivation step uses HKDF-SHA256, the symmetric layer uses AES-256-GCM, and the sealed result goes over the wire. On arrival, Cloud KMS performs the matching HPKE Open operation with the job's private key, and the customer's key material becomes usable without ever having crossed the network under classical protection alone.
The customer chooses the quantum-resistant core of the envelope. Two of the options, ML-KEM-768 and ML-KEM-1024, come straight from FIPS 203, the module-lattice key encapsulation standard NIST finalized in August 2024, at its two higher security levels. The third option, X-Wing, is a hybrid design specified in an active Internet-Draft by Deirdre Connolly, Peter Schwabe and Bas Westerbaan that combines ML-KEM-768 with the classical elliptic-curve scheme X25519 and is designed to remain secure if at least one component remains secure, subject to the combiner and hash assumptions underlying the construction. The preview carries real constraints, and Google documents them plainly: only software-protection-level keys are supported, import jobs expire after three days, the customer must pre-wrap key material itself during the preview, and a key originally imported under the older RSA-based wrapping cannot simply be re-imported through the quantum-resistant path.
On July 7, roughly five weeks before the import documentation was updated on August 12, the company moved its Cloud KMS post-quantum insights reporting to general availability. That tool inventories a customer's asymmetric keys by algorithm and flags where quantum-vulnerable cryptography still sits, which is the unglamorous bookkeeping half of crypto-agility: before an organization can migrate its cryptography, it has to know what it is running. Google's own post-quantum roadmap, published August 11, frames the quantum-resistant import release as a step in a program that treats harvest-now exposure as the priority to close by the end of 2027, targets full readiness by 2029, and cites the window NIST IR 8547 and the NSA's CNSA 2.0 requirements set for retiring quantum-vulnerable algorithms between 2030 and 2035.
Quantum pillar: post-quantum cryptography (migration and crypto-agility). Use posture: defensive. Technology readiness: TRL 7 of 9. The quantum-resistant import path runs today inside the production Cloud KMS service that customers already depend on, as a near-final capability in its operational setting, while its preview label, its restriction to software-backed keys and its manual pre-wrapping requirement mark it as not yet qualified for general availability.
What a Wrapped Key Is Worth to a Patient Adversary
Read as defense capability, this release is about denying an intelligence collector its cheapest long-term investment. Defense ministries, their contractors and the agencies that regulate them have spent a decade moving regulated workloads into commercial cloud regions, and the contractual terms of that move often include customer-originated key material. Sovereign cloud arrangements, ITAR-adjacent hosting and national security frameworks use BYOK, HSM and external-key models with different custody properties. In BYOK arrangements covered by this feature, key material crosses a network in a wrapped envelope and becomes a Cloud KMS key version; under Cloud EKM, by contrast, the key remains external and never enters Cloud KMS. A recording of a vulnerable BYOK crossing that sits in an adversary's archive today is a claim check on the future. The intercept costs the collector almost nothing now. If a cryptographically relevant quantum computer arrives within the retention life of the data, breaking one envelope could expose years of stored material when the imported key is broadly used, although the impact depends on key rotation, versioning, retention and the data-key hierarchy.
What the new import path lets a security organization stop is exactly that accumulation. A key wrapped under ML-KEM or X-Wing today uses an envelope designed and believed to resist known classical and quantum attacks, reducing what a future quantum adversary could recover from a recorded transfer. The posture is defensive in the plain sense of the capability map: the value lies entirely in protecting one's own keys, forces and data, and no offensive application falls out of it. The beneficiaries are equally plain. Any organization that imports keys into a commercial cloud gains, and the gain is largest for holders of data whose sensitivity outlives a decade, which describes weapons program documentation, personnel and clearance records, intelligence holdings and the engineering baselines of platforms that will still be in service in 2050. The attacker's side of the ledger loses a collection target that used to be nearly free.
There is also a quieter capability lesson in the algorithm menu. The choice between a pure lattice mechanism and a hybrid that retains a classical curve is a live policy divide: hybrid constructions appeal to buyers who want insurance against a flaw in the young lattice mathematics, while some national security frameworks prefer single standardized algorithms. By shipping X-Wing, ML-KEM-768 and ML-KEM-1024 side by side, Google effectively lets each compliance regime express its own doctrine through configuration, which is what crypto-agility looks like when it works.
From Preview to Program Office
What still stands between this feature and a defense program relying on it is a shorter list than usual for this field, and that is itself notable. The preview label matters: a program office that writes quantum-resistant key import into a security plan today is depending on an interface Google may still change, with no service-level commitment attached. The software-only restriction matters more for high-assurance customers that anchor their imported keys in hardware security modules, because the documentation is explicit that hardware-backed import is not yet covered. The manual wrapping requirement pushes integration work onto the customer's key ceremony tooling, where mistakes in library selection, configuration or version handling would undo the protection. X-Wing's standing deserves attention too. The draft that defines it states that it carries no formal IETF endorsement yet, so an accreditor can reasonably ask why a production key crossed a network under a mechanism that is still a draft; the standardized alternative inside the same feature is ML-KEM-1024, which presents different tradeoffs rather than a strictly more conservative choice.
None of these gaps involve new physics, although ML-KEM and X-Wing rely on computational hardness assumptions and X-Wing's security arguments remain conditional. The lattice standard is finalized, the envelope construction is a published RFC, the libraries ship today, and the remaining distance is qualification, hardware coverage and accreditation paperwork of a kind cloud providers close routinely. For a reader planning a migration, the practical takeaway is concrete: the transit leg of key custody, which harvest-now collection made the most time-sensitive leg, can now be evaluated and piloted on one major cloud with standardized algorithms, while programs retain their existing approved import controls; the inventory tooling to find the rest of the vulnerable estate became generally available roughly five weeks before the import documentation was updated. Organizations with the longest-lived secrets have reason to begin that evaluation now, but the preview limitations do not support relying on the feature yet for production defense programs.
Sources
Primary source: Google Cloud, 'Quantum-resistant key import for Cloud KMS,' Cloud Key Management Service documentation (preview), accessed August 23, 2026. Other material: Google Cloud's post-quantum cryptography roadmap (August 11, 2026); NIST FIPS 203; the X-Wing Internet-Draft by Deirdre Connolly, Peter Schwabe and Bas Westerbaan; RFC 9180 (Barnes, Bhargavan, Lipp, Wood).