Editorial explainer · official sourcesmedium
Harvest now, decrypt later: the dates the United States has just put in writing
On 22 June 2026 Executive Order 14412 was signed in the United States and published in the Federal Register three days later. It is not a technical document and introduces no new algorithms: it sets dates. Federal agencies must move high-impact systems to post-quantum cryptography for key establishment by 31 December 2030 and for digital signatures by 31 December 2031. Contractors are asked to meet the same standard by 2030, through an amendment to the federal acquisition rules. And one object appears for the first time that is worth knowing about in Europe too: the CBOM, a machine-readable inventory of what cryptography each component is actually using.
The risk that does not wait for the quantum computer
The order states the threat in two sentences, and they are worth reading as written. The first concerns the future: «The advent of large-scale quantum computers, particularly in the hands of adversaries, will pose a significant threat to widely used cryptographic security systems». The second concerns the present: «Ongoing cyber activity against our Nation also presents the risk of adversaries collecting United States information now, and decrypting it later once large-scale quantum computers are operational».
This is the problem known as harvest now, decrypt later, and it is why a subject that sounds like laboratory work has a practical deadline. Data intercepted today, encrypted with today's algorithms, is not safe forever: it is safe until a machine capable of breaking them exists. If that data holds value for twenty years — medical records, court files, trade secrets, identities — the risk is not in the future, it has already been taken.
Hence a consequence worth keeping in mind: migration is not retroactive. Protecting tomorrow's traffic does not make yesterday's harmless.
The dates
The order is short — four pages — and the operative part sits almost entirely in section 4. Within 90 days of signing, the budget office must issue guidance requiring each agency to review its inventory of high value assets and high-impact systems — excluding national security systems — and to:
- move to post-quantum cryptography for key establishment by 31 December 2030;
- move to post-quantum cryptography for digital signatures by 31 December 2031;
- submit a plan for getting there.
- 22 June 2026The signature
Executive Order 14412, published 25 June (91 FR 38483).
- +30 daysA name
Each agency names its own migration lead.
- +180 daysPilot and procurement
NIST starts a pilot project; the acquisition council publishes the first proposed rule.
- +270 daysThe CBOM
CISA and NIST publish minimum elements for the cryptographic inventory.
- 31 Dec 2030Key establishment
Deadline for high-impact systems, and for contractors.
- 31 Dec 2031Digital signatures
Deadline for high-impact systems.
The one-year gap between the two deadlines is not an oversight. Key establishment protects confidentiality, which is precisely what harvest now, decrypt later attacks: that traffic must be secured first. Digital signatures protect authenticity, which is verified at the moment of use: a document signed today with an algorithm that breaks in 2035 will need re-signing, not different signing now.
The part that concerns non-Americans too
Two passages of the order reach beyond the federal perimeter.
The first is section 6(c): within 180 days the council that governs the federal acquisition regulation must publish a proposed rule requiring covered contractors to comply «by December 31, 2030, with NIST's FIPS, including all applicable FIPS incorporating PQC compliant algorithms». Anyone selling software or hardware to the US administration — including from outside the United States — now has a date. And since no vendor maintains two product lines, one compliant and one not, the effect propagates to every customer.
The second is section 5(d), and it is the most practically interesting. Within 270 days CISA, in coordination with NIST, must publish guidance on the «minimum elements for a cryptographic bill of materials». The order's own wording is precise about the requirement: these elements «shall enable the automated assessment of the cryptographic assets utilized by a hardware or software element».
In other words: a CBOM is to cryptography what an SBOM is to software dependencies. A machine-readable list of which algorithms, which keys, which lengths and which protocols are in use inside a product.
- 01The problemnobody knows precisely where the cryptography sits in their own systems
- 02The CBOMthe vendor-declared inventory, in machine-readable form
- 03The usewhen an algorithm falls, you know within an hour which products to touch, not within six months
Anyone who lived through the migration away from SHA-1, or the end of TLS 1.0, knows why this matters. The slow part was never replacing the algorithm: it was finding out where it was. An automatable cryptographic inventory is the difference between responding to a cryptographic break in weeks or in years.
What is missing, and what the order does not say
There are limits stated in the text itself, and they belong in the record. The order «shall be implemented consistent with applicable law and subject to the availability of appropriations»: implementation depends on funding. And it creates «any right or benefit, substantive or procedural, enforceable at law» for nobody: it is not actionable by third parties.
On verifiable facts: the procurement rules are, at this point, proposed rules announced in the order — they do not yet appear to have been published. The budget office guidance required by section 4(b) was due within 90 days of signing, so by the end of September 2026; references to a specific memorandum number circulate, but we have not verified them against a primary source and therefore do not repeat them. National security systems remain outside the section 4(b) inventory and follow a separate track, with an annual report to the President through the relevant committee.
And in Europe?
The order is American and has no direct effect in the Union. But the 2030 and 2031 dates are, in practice, market dates: they apply to products, and products cross borders. The standards cited — FIPS 203 for key establishment, FIPS 186-5 for signatures, FIPS 140-3 for module validation — are the same NIST-standardised algorithms vendors are adopting globally.
For an Italian organisation the operational consequence is modest and concrete: no obligation, but a supply deadline to bear in mind in multi-year contracts, and a question to start asking vendors — can you tell me what cryptography your product uses, and in what format can you tell me? In a few months the expected answer will have a name.