Most security teams can name the open source libraries inside their applications. Ask a narrower question, where RSA and elliptic-curve keys are actually running and what breaks when they have to be replaced, and the answers get vague. That gap stopped being a theoretical inconvenience on June 22, 2026, when the White House signed Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks."
For the first time a federal directive names the cryptographic bill of materials as a defined artifact. It also attaches dates. High-value assets and high-impact systems must move to NIST-approved post-quantum algorithms for key establishment by December 31, 2030, and for digital signatures by December 31, 2031. CISA and NIST have until early 2027 to publish the minimum elements of a CBOM, with a federal pilot program due by the end of that year.
Only a minority of organizations fall under the order directly. Everyone else inherits the schedule anyway. Contractors see the deadlines written into their terms. Regulators in the European Union and the G7 cyber expert group for finance have published roadmaps converging on the same 2030 to 2035 window. Procurement questionnaires will start asking about quantum readiness within the next two budget cycles. For engineering planning, the date that matters is not 2030. It is the discovery phase, which has to finish years earlier and is the part almost nobody has started.
What the published deadlines actually say
The timelines from different authorities now line up into one picture:
- End of 2026: EU roadmap milestone for national strategies, cryptographic inventories, and pilots covering high and medium risk use cases.
- January 2027: NSA CNSA 2.0 timeline begins for national security systems, which require the larger ML-KEM-1024 and ML-DSA-87 parameter sets.
- Early 2027: CISA and NIST publish minimum CBOM elements under Executive Order 14412.
- End of 2027: Federal PQC pilot program completes.
- 2030: NIST IR 8547 deprecation date for 112-bit classical algorithms, which covers RSA-2048 and ECC P-256.
- December 31, 2030: Federal key establishment transition deadline.
- December 31, 2031: Federal digital signature transition deadline.
- 2035: Disallowance date for quantum-vulnerable algorithms.
The algorithms themselves are settled. FIPS 203 standardizes ML-KEM for key encapsulation, FIPS 204 standardizes ML-DSA for digital signatures, and FIPS 205 adds SLH-DSA as a hash-based fallback. Civilian systems generally use ML-KEM-768 and ML-DSA-65. What remains unsettled is placement, because very few companies know where their cryptography currently lives.
Harvest now, decrypt later makes 2030 too late to start
The usual urgency argument is that a cryptographically relevant quantum computer could arrive between 2030 and 2035. That estimate is uncertain and should be treated as such. The part that is not uncertain is harvest now, decrypt later.
An adversary can record encrypted traffic today, store it cheaply, and decrypt it once the hardware exists. Any data with a long confidentiality requirement is already exposed if it is protected only by RSA or elliptic-curve key exchange. Health records, financial data, legal documents, trade secrets, and government material all qualify, and so does anything with a retention obligation measured in decades.
That reframes the deadline. The question is not when quantum computers arrive. It is which data will still matter in ten years and whether the key exchange protecting it today will survive that long. Under that test, TLS sessions on customer portals, encrypted database backups, site-to-site VPN links, and signed software artifacts are all in scope right now.
What belongs in a cryptographic bill of materials
A CBOM is an inventory of every cryptographic component in an environment. Where an SBOM records the software components you run, a CBOM records how that software is protected. A useful one covers:
- TLS endpoints. Every load balancer, reverse proxy, API gateway, and CDN origin that terminates TLS, with the algorithm and key size each one negotiates.
- Keys and certificates. Root and intermediate CA certificates, leaf certificates, private keys, HSM-backed keys, and the expiry and rotation state of each.
- Identity and access. SSH host and user keys, VPN and IPsec configurations, S/MIME certificates, and directory service settings.
- Application layer. OpenSSL, BoringSSL, and wolfSSL versions in use, along with homegrown crypto and hardcoded keys that never made it into a library.
- Data at rest. Database encryption, backup encryption, object storage encryption, and key management service configuration.
- Code and artifact signing. Build pipeline signing keys, package signatures, container image signatures, and firmware signing.
- Third parties. What each vendor and SaaS provider uses, and which of them will hand over a crypto inventory when asked.
CycloneDX and SPDX are the likely hosts for a machine-readable CBOM, which matters more than it sounds. Most enterprises already generate an SBOM for compliance. Extending that existing pipeline to carry cryptographic assets costs far less than standing up a separate inventory program, and it keeps the crypto data in the same review process that already has owners.
Where cryptography hides in a typical enterprise
Discovery is slow because cryptography does not sit in one place. It appears in application source, in compiled binaries, in configuration files, in hardware security modules, in cloud service defaults, and in code a contractor wrote eight years ago and nobody has touched since.
The tools available address different layers of that problem. Network probes see what negotiates on the wire. Host agents see libraries loaded in memory. Static analysis finds algorithm references in source. Cloud connectors read key management and certificate manager state. None of them is complete on its own, and the gaps between them are exactly where the unmanaged keys turn out to be. Whichever combination a team selects, the output has to be generated from the CI/CD pipeline on every build. A one-time audit goes stale the moment the next dependency update ships.
Sequence the migration so the easy win comes first
Production deployments have already settled the ordering question, mostly by shipping it.
First, hybrid key exchange
X25519MLKEM768 pairs the classical X25519 key exchange with the post-quantum ML-KEM-768 and combines both secrets, so the connection holds as long as either algorithm survives. Chrome has enabled it by default since version 131 in November 2024 and Firefox since version 132. Apple added it across iOS 26 and macOS Tahoe. Cloudflare reported that the majority of human-initiated TLS traffic on its network was negotiating a hybrid by October 2025. In September 2026 its automatic key exchange feature pushed origin-side hybrid connections from roughly 25 billion to 45 billion a day, with about a third of scanned domains receiving an X25519MLKEM768 preference.
For an enterprise, this is the lowest-risk change available. Hybrid negotiation is opportunistic, so older clients fall back to classical algorithms without breaking. It closes the harvesting window immediately for everything the endpoint serves.
Second, signature migration
Signatures are harder because the artifacts they protect outlive the systems that sign them. ML-DSA is the practical default, and code signing is the most reliable place to start since signed builds need to remain verifiable for years. ML-DSA reached general availability in Microsoft Active Directory Certificate Services on Windows Server 2025 as of the May 2026 update, but TLS, VPN, and remote desktop scenarios still trail code signing. Library versions matter: OpenSSL 3.5 and later implement FIPS 203 and FIPS 204 natively, with wolfSSL and liboqs-backed builds as alternatives.
Third, crypto agility
The deliverable that outlasts this whole exercise is crypto agility, the ability to swap an algorithm without a rewrite. A team that treats post-quantum migration as a one-time replacement of RSA with ML-KEM will repeat the entire project at the next algorithm change. A team that builds the inventory, keeps it in the build pipeline, and keeps algorithm choice out of application code will absorb future changes as configuration.
Why vendors will not solve this for you
Every cloud provider and CDN has already moved on key exchange, and that work is useful. It covers traffic that terminates at their edge and nothing behind it. Your internal services, your on-premises appliances, your build pipeline, and your database backups are outside that coverage. Vendor progress also stops at key establishment in most cases, leaving signature migration to the customer.
The same is true of security platforms that publish a crypto inventory feature. They can enumerate what they can see, which is a starting contribution rather than a finished inventory. Reconciliation across sources is the work, and it does not delegate.
What this means for e-commerce and customer-facing systems
E-commerce teams meet a specific version of this problem. Payment flows, customer login, and session handling all depend on TLS, and PCI DSS scope covers the systems handling cardholder data. Certificate lifetimes are also compressing toward 47 days, which forces automation of issuance and renewal rather than calendar reminders. A crypto inventory and a certificate automation pipeline are the same project seen from two angles, and both need to run continuously.
For customer-facing sites the migration is mostly invisible when it is done well. The server and the browser negotiate hybrid key exchange with no change to the user experience. The real work is knowing which endpoints exist, which ones a legacy client depends on, and which ones can change without interrupting a checkout.
A first 90 days
- Set the scope. Start with internet-facing endpoints and the data carrying the longest confidentiality requirement. Inventorying the entire company in the first quarter is not the goal.
- Pull what already exists. SBOM pipelines, certificate inventories, and cloud key management exports cover more ground than most teams expect.
- Fill the gaps. Use a network probe for wire visibility and static analysis for source, then reconcile both against the certificate inventory.
- Rank by risk. Combine data sensitivity, exposure, and remaining algorithm life into one ranked list. Long-lived secrets on internet-facing systems go first.
- Turn on hybrid key exchange where it is supported. It is opportunistic, reversible, and closes the harvesting exposure right away.
- Write the inventory into the build. Generate the CBOM automatically so it stays current, and record an owner for every asset so the 2030 work has a name attached to it.
The cost of starting late is measured in calendar years
Realistic end-to-end migration estimates for large organizations run five to fifteen years, and the discovery phase alone can take 12 to 24 months. Those numbers are why a 2030 finish line implies a 2026 start. An organization that begins in 2029 is not late by a few months. It is late by the duration of the discovery phase, with no room to renegotiate the deadline.
The work is boring, and that is the point
Nothing here is technically novel. This is a discovery problem, a scheduling problem, and a governance problem wearing a cryptography costume. The precedent usually raised is Y2K, which was managed well because thousands of organizations did the tedious work years ahead of time and nothing dramatic happened as a result. Post-quantum migration has the same shape with one difference. There is no single midnight. The horizon starts with an inventory and stretches across 2027, 2030, and 2035.
For an organization with no inventory, the useful first step is not a pilot of a post-quantum algorithm. It is finding out where RSA and ECC are running today, which ones protect data that will still matter in a decade, and who owns each one. That list fits on a spreadsheet, and building it is the difference between a migration that gets scheduled across several budget cycles and one that gets rushed through in the final year.
