Frequently asked questions

Nobody knows, and anyone who gives you a confident single date is guessing. A cryptographically-relevant quantum computer — one large and stable enough to run Shor's algorithm against real RSA and elliptic-curve keys — does not exist yet, and estimates range widely.

The important point is that the exact date does not change what you should do. Because migration takes years and because data recorded today can be decrypted later, you have to act before Q-Day is known. Government roadmaps set deadlines precisely so organizations plan against the conservative end of the range instead of waiting for certainty.

Two reasons. First, harvest-now-decrypt-later: adversaries can record your encrypted traffic today and store it cheaply until a quantum computer can decrypt it. Any secret that must stay confidential for years is therefore exposed now, even though the break is in the future.

Second, migration is slow. Finding every place you use vulnerable cryptography, planning the change, and rolling it out without breaking production takes years for a real organization. If you wait until quantum computers are real, you have already started too late.

For long-lived secrets, yes — in the sense that they can already be recorded now for decryption later. The way to reason about it is Mosca's inequality: if the number of years your data must stay confidential, plus the years it takes you to migrate, is greater than the years until a quantum computer arrives, that data is at risk.

That means health records, biometric data, state or trade secrets, and long-term contracts are the concern. Data that stops mattering in hours — a session cookie, an expiring one-time code — is not, because it is worthless by the time it could be decrypted.

No. The threat is specific. Shor's algorithm breaks the asymmetric (public-key) algorithms — RSA, Diffie-Hellman, and elliptic-curve — that establish keys and create digital signatures. Those are the urgent problem.

Symmetric encryption like AES-256 and modern hash functions are far less affected. Grover's algorithm weakens symmetric keys only modestly, and using strong key sizes (AES-256) keeps them safe. The migration is overwhelmingly about replacing vulnerable key exchange and signatures, not about abandoning AES.

Passwords still matter today — most accounts still use them, and a weak or reused password is one of the most common ways attackers get in. Modern guidance (NIST SP 800-63B) says to favor long passphrases, stop forcing arbitrary complexity and periodic rotation, and use a password manager so every account has a unique credential.

Passkeys are where things are heading. A passkey replaces the password with a device-held cryptographic credential that cannot be phished or reused, so it removes the biggest weaknesses of passwords entirely. Adopt passkeys wherever they are offered, and keep good password hygiene everywhere they are not yet.

A passkey is a login credential based on FIDO2/WebAuthn public-key cryptography. When you create one, your device generates a key pair: the private key stays protected on your device (unlocked by your fingerprint, face, or PIN) and only the public key is shared with the website.

Because there is no shared secret stored on the server and nothing to type, there is nothing for an attacker to steal in a breach or trick you into handing over. That is what makes passkeys phishing-resistant — the property ordinary passwords and even SMS codes lack.

There is a cost, but for most systems it is manageable. The post-quantum algorithms generally have larger keys and signatures than RSA or elliptic-curve, and some operations use more CPU or add a little to each connection's data. For typical web and API traffic the impact is usually modest.

The honest answer is: measure it. That is exactly why the migration playbook includes a testing-and-validation phase — you check interoperability and performance in your own environment before committing, rather than assuming either a catastrophe or a free lunch.

The NIST-standardized ones, finalized in 2024. For key exchange, ML-KEM (FIPS 203) — this is the priority, because key exchange is what harvest-now-decrypt-later targets. For signatures, ML-DSA (FIPS 204) as the primary choice, with SLH-DSA (FIPS 205) as a conservative hash-based alternative.

Be wary of anything marketed as 'quantum-safe' that is not one of these standards. Several earlier candidates were broken during standardization — the multi-year public scrutiny is exactly why the finalized standards are the ones to trust.

A hybrid deployment runs a classical algorithm and a post-quantum one together, so a connection is secure as long as at least one of them holds. For example, hybrid TLS key exchange wraps a post-quantum KEM around the classical exchange.

Hybrids are the pragmatic bridge during the transition: you get protection against harvest-now-decrypt-later immediately, while keeping the safety net of the well-understood classical algorithm in case an implementation issue turns up in the newer one. Most first migrations of external-facing TLS use a hybrid mode.

With discovery. You cannot protect, prioritize, or budget what you have not found, so the first step is a cryptographic inventory: find every place you use RSA, ECDH, and ECDSA across TLS, PKI, code signing, data-at-rest, and identity.

From there, prioritize by exposure using the harvest-now-decrypt-later lens (long-lived and externally-facing data first), build for crypto-agility so future swaps are configuration rather than rewrites, and migrate domain by domain — externally-facing key exchange first. See the guide on standing up a program for the full sequence.

Partly — a lot of your cryptography does live in software you buy rather than write, and those vendors have to migrate their own products. But you can only manage that risk if you know which vendors and products are exposed, which requires your own inventory and a vendor-risk process.

So the practical stance is: track each critical vendor's PQC roadmap, put readiness requirements into contracts and renewals, and prioritize the vendors that handle your long-lived or externally-facing data. 'The vendor will handle it' is an assumption, not a control.

Not wholesale, and not all at once. Much of the migration is software and configuration — updating libraries, protocol settings, and certificate types — rather than ripping out hardware. Certificates and keys are re-issued over time as part of normal lifecycle management, now targeting post-quantum or hybrid algorithms.

Some specialized hardware (for example certain HSMs or embedded devices) may need updates or replacement to support the new algorithms, which is one more reason the inventory matters: it tells you where the genuinely hard, hardware-bound cases are so you can plan them early.