"Later" already started: why post-quantum migration is a deadline
Most teams still file post-quantum cryptography under "someday." The reasoning sounds sensible: a quantum computer able to break RSA or elliptic-curve cryptography doesn't exist yet, so migration can wait.
That reasoning ignores how the attack actually works. Harvest-now-decrypt-later isn't a forecast. It's a collection posture that is already running. An adversary who records your encrypted traffic today doesn't need to break it today. They only need to store it until they can.
The question that matters
Ask how long your data needs to stay secret. If it's medical records, legal files, private keys, M&A traffic or identity data, the answer is often ten years or more. If that's longer than the time until a cryptographically relevant quantum computer exists, the data is already exposed. The exposure was locked in the day it crossed the wire.
Where to start
Inventory first. Most organizations can't list where they use key exchange and signatures: TLS terminators, VPNs, SSH, code signing, wallet software, internal service meshes. You can't migrate what you haven't found.
Prioritize by secrecy lifetime, not system importance. A low-profile archive link carrying long-lived data matters more than a high-traffic API serving data that's stale in a week.
Go hybrid. Pair a classical algorithm with a NIST-standardized post-quantum one, such as ML-KEM for key exchange. That keeps you safe if either one turns out to be flawed. It's what major browsers and messaging apps have already shipped.
Plan for crypto-agility. The algorithms will change again. Systems that hard-code one primitive will pay for this migration twice.
The real risk
Bad math is rarely what fails. Implementation fails: side channels, key handling, and libraries pulled in without review. The post-quantum migration is a new chance to make those mistakes, so audit the implementation as hard as you vet the algorithm.