Post-quantum cryptography migration: how to start a crypto inventory before the 2030/2031 deadlines

A signal worth planning for

In June 2026, Executive Order 14409 set concrete deadlines for U.S. federal high-value and high-impact systems: post-quantum key establishment by December 31, 2030, and post-quantum digital signatures by December 31, 2031. That does not mean every engineering team must replace every certificate tomorrow. It does mean the market has received a clear signal: post-quantum migration is moving from “later” into planning.

In plain terms, post-quantum cryptography is not “quantum encryption.” It means newer encryption and digital-signature methods prepared for a future where quantum computers may break some older algorithms much faster than ordinary computers can.

The most useful first step for a normal engineering team is not buying a “quantum-safe” product. It is building a crypto inventory. You need to know where your system depends on TLS, VPN, SSH, code signing, certificates, libraries, hardware keys, and long-lived data. Without that map, any migration becomes guesswork.

Not every cryptographic risk has the same urgency

Post-quantum migration has two large categories that are easy to mix together.

The first is key establishment and encryption. This is how a browser, API client, VPN, or service agrees on a key for an encrypted connection. The risk has a long tail: traffic can be recorded now and attacked later. If the data remains valuable for years, harvest-now-decrypt-later already matters.

The second is digital signatures. These protect packages, containers, releases, documents, certificates, firmware, and other artifacts by proving authenticity and integrity. Signatures also need migration, but their priority depends on artifact lifetime, trust chains, and how long the signature must remain verifiable.

So the question is not only “do we need PQC?”. It is “where do we use encryption, where do we use signatures, where do long-lived data paths exist, and what should move first?”.

A first crypto inventory in one focused work slot

Start with the system surface, not with algorithm names. A first pass can be a simple document that contains no secrets.

1. Web and API paths

Write down where TLS terminates: CDN, load balancer, ingress, origin, service mesh, and API gateway. Separate client-to-edge, edge-to-origin, and internal service-to-service traffic. If PQC is enabled only at the edge, the whole path is not automatically ready.

Check whether TLS 1.3 is used, which clients actually connect, and whether old mobile apps, embedded devices, or corporate proxies may break when new settings appear.

2. VPN, SSH, and admin access

VPN and SSH setups often live longer than web configuration. Map what is used by engineers, contractors, CI jobs, a bastion host, and emergency access paths. Do not put private keys in the inventory. You only need the system name, owner, key type, rotation schedule, and whether the vendor has a PQC roadmap.

3. Code signing, package signing, and CI

Code signing is invisible until it breaks. Find where releases, packages, container images, mobile builds, firmware, SBOM files, and attestations are signed. Then ask who verifies those signatures and how long they must remain valid.

4. Certificates, PKI, and hardware dependencies

If you run internal PKI, an HSM, smart cards, a TPM, or special hardware modules, list them separately. These areas often become migration bottlenecks because they cannot be updated as easily as a software package.

5. Data with long confidentiality value

Mark data that must remain confidential for 5-10 years: personal data, medical records, financial documents, legal archives, trade secrets, and backups. If that data travels over the network or sits in backup archives, it belongs in the harvest-now-decrypt-later risk area.

Read standards, not marketing claims

NIST has standardized the main post-quantum algorithms: ML-KEM for key establishment, ML-DSA and SLH-DSA for digital signatures. That does not mean you should manually wire algorithm names into every service. It means vendor conversations should be specific:

• which NIST-standardized algorithms are supported;
• whether hybrid key agreement is used;
• where PQC applies: client-to-edge, edge-to-origin, or internal traffic;
• which clients or libraries are not supported yet;
• what rollback looks like if part of the traffic breaks;
• how long old signatures and certificates remain verifiable.

Cloudflare’s materials frame this well: readiness is not a single switch. It depends on connection boundaries, clients, origin support, and internal systems. That way of thinking is useful even if your stack is not built around Cloudflare.

A 30/90/180-day backlog

Avoid a big-bang migration. Build a small backlog instead.

First 30 days

Create the crypto inventory without secrets. Assign an owner to every row. Separate encryption/key establishment from digital signatures. Mark long-lived data. Add vendor-roadmap questions for CDN, VPN, cloud, PKI, HSM, and core libraries.

By 90 days

Pick one low-risk pilot. For example, test PQC readiness at the edge for a slice of test traffic, or verify which build and signing tools already have a roadmap for ML-DSA or SLH-DSA. Add monitoring for latency, TLS errors, and unsupported clients.

By 180 days

Turn the inventory into a migration plan. Each system should have a status: ready, blocked by vendor, blocked by legacy clients, needs test, or needs architecture change. Plan crypto agility explicitly: how will you change algorithms, keys, and certificates without rewriting the whole system under pressure?

Common mistakes

The first mistake is assuming PQC matters only for U.S. government systems. Regulatory signals reach contractors, SaaS providers, critical infrastructure, and teams with long-lived data faster than most teams expect.

The second mistake is putting encryption and signatures into one vague “crypto” bucket. That can send work to the wrong place while data that can be recorded today remains exposed.

The third mistake is trusting generic vendor claims. “Quantum-safe” is not enough. Ask which standards, which connection boundary, which clients, and which rollback path.

The fourth mistake is storing secrets in the inventory. The document should contain systems, owners, cryptography type, risks, and next actions. It should not contain private keys, certificates, tokens, or confidential payloads.

Conclusion

Post-quantum migration does not start with a heroic replacement of every algorithm. It starts with visibility. Where do you use TLS? Where are VPN and SSH access paths? Where are releases signed? Which data stays valuable for years? Who owns each area?

Once a team can answer those questions, it is no longer working in the dark. Then it can evaluate NIST-standardized algorithms, vendor roadmaps, pilot zones, and crypto agility calmly. The 2030/2031 deadlines look far away, but the inventory is better done now while it is still planned work, not an emergency migration.

Sources

• White House: Securing the Nation Against Advanced Cryptographic Attacks
• Cloudflare Blog: The post-quantum EO is an important milestone. Now it's time to get to work
• NIST CSRC: Post-Quantum Cryptography
• Cloudflare Docs: Post-quantum cryptography (PQC)
• NIST NCCoE: Crypto Agility Considerations for Migrating to Post-Quantum Cryptographic Algorithms