The post-quantum deadline is 2030. Do the math on your start date.

For most of the last decade, post-quantum planning had a convenient escape hatch: nobody had set a date.

That is over.

As Valeri Milke put it in a recent post aimed at CISOs, the EU just gave every CISO a deadline, and it is not 2035. It is 2030.

Milke's point is worth taking seriously because of what follows from it. The end dates for classical public-key cryptography are now written down by the bodies that set the rules. Once you lay them next to how long a real migration takes, the conversation stops being about when quantum computers arrive and starts being about when your program has to begin.

The end dates are now official

Milke's post condenses a timeline that otherwise has to be reconstructed from a dozen documents. With the Canadian and US dates added, it looks like this:

• August 2024. NIST finalizes its first post-quantum standards, FIPS 203, 204, and 205 (ML-KEM, ML-DSA, and SLH-DSA). "We are waiting for standards" stopped being a valid reason to wait.
• End of 2026. Under the EU Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, published in June 2025, every member state is expected to have an initial national PQC transition roadmap in place, with work underway on inventories of cryptographic assets.
• January 1, 2027. According to the NSA's CNSA 2.0 FAQ, all new acquisitions for US national security systems will be required to be CNSA 2.0 compliant unless otherwise noted.
• End of 2030. The EU roadmap calls for high-risk use cases to complete the transition. In its words, quantum-vulnerable public-key mechanisms "shall not be used stand-alone after the end of 2030" for those use cases.
• End of 2031. Canada's federal PQC roadmap (ITSM.40.001) requires high-priority Government of Canada systems to be migrated.
• End of 2035. The EU roadmap targets completion for medium-risk use cases, Canada's remaining federal systems must be migrated, and NIST's draft transition guidance, NIST IR 8547, proposes disallowing RSA and elliptic curve cryptography entirely after 2035.

None of these dates is yet a direct legal mandate on most private companies. They arrive through national plans, sector regulators, and procurement.

Regulated industries also have their own pressure points. PCI DSS 4.0.1 Requirement 12.3.3 already requires an inventory of the cipher suites and protocols in use, reviewed at least every 12 months, along with a documented strategy to respond to anticipated changes in cryptographic vulnerabilities.

DORA requires documented encryption and key management policies, and NIS2 lists policies on the use of cryptography among its mandatory risk management measures.

Now do the uncomfortable math

Milke estimates that a cryptographic migration in a large, long-established enterprise landscape takes three to seven years. Inventory, supplier dependencies, HSM firmware, PKI, and certificate lifetimes do not move in quarters.

Due date: end of 2030. Duration: five years. Start date: 2025. For an organization starting in late 2026, a five-year program lands in 2031, after the EU target for high-risk systems. A seven-year program lands in 2033.

The math is actually worse than that, for two reasons.

First, harvest now, decrypt later.

Data captured before a system migrates stays captured. The 2030 date is when quantum-vulnerable mechanisms should stop being used on their own for high-risk systems. It is not when the exposure ends. Any sensitive record that crosses a quantum-vulnerable channel between now and then is a candidate for future decryption, and the longer the record must stay confidential, the bigger that problem gets.

Second, the threat timeline keeps moving closer.

A 2025 estimate from Google's Craig Gidney suggests RSA-2048 could be factored with fewer than one million noisy qubits in under a week, roughly a twentyfold reduction from the 20 million qubits estimated in 2019. In terms of Mosca's theorem, the time until a cryptographically relevant quantum computer exists is shrinking, while the time your data must stay secret is not.

Which leaves one variable an organization actually controls: how long the migration takes.

Why migrations take so long

Much of the time in a multiyear migration goes into work around the algorithms rather than the algorithms themselves. Turning on hybrid ML-KEM key exchange in a current TLS library can be close to a configuration change. The years go into finding every place cryptography lives, working out what each one protects, and then touching each of those places without breaking production.

In a typical enterprise, that means certificates and TLS endpoints, but also application code with embedded libraries, database encryption, backups, message queues, file transfers, HSMs, third-party integrations, and decades-old mainframe applications that nobody wants to recompile.

Every one of those has its own owner, its own release cycle, and its own risk of outage.

The number of places is the problem.

So the practical question is not only how to migrate faster. It is how to reduce the number of things that need migrating, and how to know which ones matter first.

Three ways to shorten the timeline

1. Start the inventory with the data. Cryptographic scanning tells you where RSA and ECC are used. It does not tell you which of those places protect records that must stay confidential for decades and which carry data that is worthless next month. DataStealth's data discovery and classification locates sensitive data across on-premise, cloud, SaaS, and mainframe environments, including unknown repositories and shadow data that never made it into an asset register. That turns a flat list of endpoints into a prioritized sequence, so the high-risk systems the 2030 target covers get migrated first.

2. Shrink the scope before you migrate it. Vaulted tokenization replaces sensitive values with random tokens that have no mathematical relationship to the original data, so no future computing power can reverse them. The originals stay in a controlled vault. When values are tokenized before they move through applications, analytics platforms, test environments, and third parties, those downstream systems stop carrying the real values worth harvesting. Their migration still matters, but it can drop in priority. Dynamic data masking limits who sees real values in the systems that keep them. Vaultless tokenization and format-preserving encryption are also options, but they rely on cryptographic keys and carry different tradeoffs, which we cover in Vaulted, Vaultless, and Format-Preserving Encryption: Choosing Deliberately.

3. Keep protection out of individual applications. Crypto agility matters because the algorithm set is still moving, and the EU roadmap explicitly calls for it. NIST selected HQC as a backup key encapsulation mechanism in 2025, and FN-DSA (FIPS 206) is still in draft. DataStealth's data security platform sits inline rather than requiring agents or changes to application code, including on mainframe systems where code changes are the most expensive and risky to make. Protection that is not embedded in each application does not become one more library inside each application that must later be found and migrated.

To be clear about the limits: none of this is an exemption from post-quantum migration.

Traffic to the tokenization layer, the vault, and key management still rely on cryptography that must move to ML-KEM and ML-DSA. The value is in concentration. Migrating a small set of controlled points is a very different project from migrating every application that touches a card number or a health record.

What the first 90 days should produce

Milke makes another point worth repeating: the first 90 days cost work, not budget. A focused team can produce the foundation for a 2030 program before it ever asks for funding:

1. Name an owner and a date. Assign an accountable executive and a working group across security, architecture, and risk, and commit to a target completion date for high-risk systems.
2. Discover and classify sensitive data. Map where regulated and long-lived data resides and flows, and record how long each class must stay confidential. Our data risk assessment is a fast way to start.
3. Build the cryptographic inventory for those systems. Cover protocols, certificates, libraries, HSMs, PKI, and suppliers, and capture it in a machine-readable cryptographic bill of materials (CBOM) such as CycloneDX.
4. Work the math backward from 2030. For each high-risk system, estimate migration duration and calculate the latest viable start date. Flag every system where that date has already passed.
5. Reduce exposure now. Identify flows where tokenization or masking can remove long-lived sensitive values from harvestable paths before migration reaches them.
6. Write the roadmap and the board view. Sequence migration waves, set crypto agility requirements in architecture standards and supplier contracts, and map the evidence to PCI DSS 12.3.3, DORA, and NIS2.

Put a date on it

Milke closes with a question every security leader should be able to answer: has your organization put a date on its own migration, or is "after the next audit" still the plan?

Governments and standards bodies have put their dates on it. The arithmetic says most enterprises should already be underway. The organizations that hit 2030 will not be the ones that migrated fastest. They will be the ones that gave themselves less to migrate.

Shorten your path to 2030

DataStealth helps you find sensitive data, protect it with tokenization and masking, and reduce how much sensitive data your post-quantum migration has to protect.

Book a demo and technical walkthrough