Checklist: Is Your Business Ready for Post-Quantum Cryptography Migration?

Most of the encryption protecting your business was designed to be broken only by brute force, and it does that job well. Quantum computers running Shor's algorithm change the math. The public-key systems behind TLS, VPNs, code signing and secure email stop being hard problems. Nobody can tell you the exact date a cryptographically relevant machine arrives, and that uncertainty is the reason the work starts now rather than later.

Attackers do not need that machine yet. Traffic captured today can sit in storage for years. The real question is not whether your organization migrates to post-quantum cryptography, but whether it happens as a managed program or a late scramble.

Start With an Honest Cryptographic Inventory

You cannot migrate encryption you cannot find. Most organizations discover that they know their public-facing TLS certificates and very little else. The inventory needs to be a map of algorithms, key lengths, protocols, certificate lifetimes, libraries and who owns each one — not just a list of servers.

Where cryptography tends to hide

• External TLS endpoints, load balancers and CDN configurations
• Internal service-to-service mTLS and API gateways
• VPN concentrators, remote access and site-to-site tunnels
• SSH keys, including the ones baked into automation and CI runners
• Code signing, package signing and artifact repositories
• Email signing and encryption, plus S/MIME certificates
• HSMs, key management systems and database transparent encryption
• Firmware and embedded devices that will outlive several laptops

Automated discovery tools help, and certificate transparency logs will give you a surprising amount for free. But a scan only finds what it can reach. The most useful hour you will spend is sitting with the platform, network and application teams and asking one question: where does your system depend on a key or a certificate?

Rank Data by How Long It Must Stay Secret

Not everything needs to be protected forever, and treating it that way wastes budget. Think in three clocks: how long a given class of data must remain confidential, how long the migration will realistically take, and how long until a machine capable of breaking current public-key cryptography exists. Where the first clock runs longer than the other two combined, you are already exposed.

If the data must stay confidential longer than the migration will take, it is already in scope — the recording may simply have happened yesterday.

Long-lived confidentiality is where harvest-now-decrypt-later bites hardest: merger and acquisition documents, unpublished research, source code, personal data, health and legal records, and anything under a long regulatory retention requirement. Session tokens and last week's application logs can wait. Your board memo can probably not. Sort data into tiers and attach a name to each tier.

Map the Hard Spots Before You Commit to a Date

The migration is rarely difficult because of a web server. It is difficult because of the fifteen-year-old industrial controller, the third-party SaaS platform you cannot inspect, and the cryptographic module inside a hardware appliance that has no firmware update path.

Questions worth putting in writing to vendors

• Which algorithms and key sizes do you use today, and where?
• Can you switch algorithms without a full product reinstall?
• What is your roadmap for post-quantum and hybrid key exchange?
• Will you support larger keys and certificates without performance regressions?
• How will you notify customers of cryptographic changes, and with what notice period?

Vendors who cannot answer these questions are a risk item. Put the answers in your contract renewal conversations while you still have leverage.

Build a Phased Timeline, Not a Big Bang

Standards are no longer the blocker. The main post-quantum algorithms have been standardized, covering key encapsulation and digital signatures, and libraries are shipping them. What takes time is everything around them: procurement, testing, PKI changes, and the long tail of systems nobody wants to touch.

1. Assign ownership and write a policy. Name an accountable owner, approve a list of allowed algorithms, and forbid new deployments of weak or legacy primitives.
2. Build crypto-agility first. Make algorithms configurable rather than hard-coded. If swapping a library requires a release cycle, fix that before the swap itself.
3. Protect the highest-risk channels with hybrid key exchange. Combining a classical and a post-quantum exchange keeps you safe if either one falls. Prioritize VPNs, remote access and long-lived confidential data flows.
4. Move internal systems, then customer-facing ones. Internal services give you space to learn, break things quietly and write the runbooks.
5. Retire, don't just replace. Every legacy protocol you switch off is one you never have to migrate again.

Make Crypto-Agility a Permanent Requirement

A migration is a project; crypto-agility is a habit. Test new algorithm suites in staging with realistic traffic, because larger keys and handshake messages affect packet sizes, latency and connection success in ways that surprise people. Rotate keys and certificates on a schedule so rotation is boring. Keep an inventory that updates itself. Track your data tiering decisions somewhere a new engineer can find them.

Watch for the compliance angle too. Several governments have published migration targets measured in years rather than decades, and sector regulators are following. If you operate in regulated markets, confirm what applies to you with your own legal or compliance advisors before you commit to a public timeline.

A Readiness Checklist You Can Score This Week

• We know every system that uses public-key cryptography, and someone owns each entry.
• Data is tiered by required confidentiality lifetime, not just by sensitivity label.
• We have at least one named executive sponsor and a budget line, however small.
• Algorithm choices are configurable, not compiled into applications.
• We can deploy hybrid key exchange in at least one production path.
• Vendors have been asked about their post-quantum roadmap in writing.
• We know which systems physically cannot be upgraded and have a plan for them.
• We have a documented, dated migration phase plan with review points.

Six or more yes answers puts you ahead of most organizations. Fewer than four means the first task is not migration — it is visibility.

What to Do in the Next 90 Days

Pick two systems: one external, one internal, ideally including something awkward. Inventory their cryptography end to end. Tier the data they handle. Draft a one-page policy that names approved algorithms and forbids new legacy deployments. Bring the vendor questions to your next three renewal discussions. Then set a review date and put it in the calendar with a name next to it.

Quantum computing timelines are uncertain, and that is the point. You are not trying to predict the date. You are trying to make sure that whenever it arrives, the answer to "are we ready?" is yes, and that a small team already knows where everything is.

Photo: succo / Pixabay