Blog
Security13 Oct 2026

Twenty-four agencies, one complete inventory.

A new GAO report finds that none of 24 major US federal agencies had fully prepared to move to post-quantum cryptography. The first gap is knowing where vulnerable key exchange is used at all.

On 6 October 2026 the US Government Accountability Office published Quantum Computing: Federal Actions Needed to Prepare for Emerging Cyber Threat (GAO-27-108740). GAO reviewed the 24 Chief Financial Officer Act agencies against three preparatory practices drawn from Office of Management and Budget guidance: build a prioritized inventory of systems that use quantum-vulnerable cryptography, identify the funding needed to migrate them, and test post-quantum cryptography in agency environments. Its headline finding is that "none of the 24 selected agencies fully addressed these practices."

The public report is a version of a sensitive report GAO issued in September 2025, so the findings describe agency status at that point rather than today. Cybersecurity Dive reported on the release on 8 October.

What GAO found

On inventories, one of the 24 agencies fully addressed the activities for building a prioritized list of systems with vulnerable cryptography. Twenty-two had partial inventories and one had not developed one. Gaps included missing high-value assets and missing systems holding data expected to remain sensitive in 2035, which is the horizon OMB memo M-23-02 asks agencies to plan against. Only five agencies used automated tools to find and verify vulnerable cryptography; officials at 15 of the other 19 said it was too early for such tools or that they were waiting for CISA to recommend some.

On funding, no agency fully identified what its migration would cost. Twenty-one produced partial assessments and acknowledged their data were not fully accurate. The report notes an estimate from the Office of the National Cyber Director, passed to Congress by OMB, of roughly $7.1 billion to migrate priority systems or replace legacy systems that cannot support post-quantum algorithms, with a significant share attributed to those legacy systems.

On testing, one agency had done market research on candidate vendor implementations but had not tested them, and the other 23 had done neither. Sixteen agencies told GAO it was too early because vendors were still adding the algorithms to their products. The sensitive report carried 89 recommendations to 23 agencies; 12 agreed, two partially agreed, seven neither agreed nor disagreed, and one disagreed with three of its four.

Why the timeline matters now

GAO writes that most industry experts expect a cryptographically relevant quantum computer to be built, possibly in the 2030s, while noting that estimates vary widely. The report describes two consequences: forged authentication, and decryption of data an attacker collected before such a machine existed. That second point is the "harvest now, decrypt later" problem. Traffic captured today under classical key exchange can be stored and opened later, and GAO notes that deriving a private key from a public key with a quantum computer is not something the victim's security tools would detect.

The same report makes a useful distinction in a footnote: data at rest is generally protected by symmetric cryptography, which is not currently projected to be vulnerable to such a machine. The exposed layer is public-key cryptography, the key exchange and signatures that protect data in transit and decide who can unwrap a file key.

The same problem outside government

The hardest finding is the first one. An agency that does not know where RSA or elliptic-curve key exchange sits in its systems cannot price or schedule the replacement. The same is true for any organisation that moves sensitive files through email attachments, cloud shares, file-transfer portals and vendor tools. Each of those carries its own key exchange, chosen by someone else and upgraded on someone else's schedule.

For files that need to stay confidential into the 2030s (legal, medical, financial, source code, personal documents), the useful questions are concrete. Where is the content key generated? What public-key scheme wraps it? Who can change that scheme, and when? If the honest answer is "the provider, eventually", the file inherits the provider's migration plan.

A file sent today with classical key exchange is only as private as that exchange will be in ten years.

How SpaceBox handles the key exchange

SpaceBox Lite encrypts files on the sender's device. File contents are sealed with AES-256-GCM, and the file key is exchanged using ML-KEM-768, the module-lattice key-encapsulation mechanism NIST published as FIPS 203 on 13 August 2024. Keys stay on the device, and our servers hold ciphertext only. That matches the split GAO describes: symmetric encryption for the content, and a post-quantum scheme for the public-key step that a future quantum computer would target.

Post-quantum key exchange is not unique to us; browsers, messaging apps and cloud providers are adding ML-KEM as well. What the design changes is where the inventory question lands. With client-side encryption and device-held keys, there is one known scheme protecting each file, chosen before upload, instead of a chain of transport and storage layers that each need their own audit. Senders need no account and give no personal data. The free tier covers 1 MB, one sender and three files, and a free voucher at beta.i46.space adds 100 MB and 100 files (email required). SpaceBox Lite is not available to EU/EEA residents during the beta.

What to take from the report

GAO's numbers describe large institutions that had OMB guidance from November 2022 and still had not finished counting their exposure. Smaller teams will not do better by default. Start with the files that must stay private longest, find out which key exchange protects them in transit and at rest, and move those first to a path that uses a finalised post-quantum standard.

Post-quantum key exchange for file dropsML-KEM-768 plus AES-256-GCM, encrypted on the sender's device, ciphertext only on our servers.

Keep reading

All articles →