Start Your Post Quantum Migration: A Practical Checklist for Ordinary Users

The threat has a name: harvest now, decrypt later. An adversary copies your encrypted traffic or your encrypted backups today, stores them cheaply, and waits for a cryptographically relevant quantum computer to break the key exchange that protected them. You cannot stop the recording. You can make the recording worthless by ensuring the data either expires before that day arrives or is protected by algorithms that survive it. The work below is a migration checklist, not a prediction about timelines.

Steps

1. Inventory what cryptography protects and how long it must stay secret. List every channel and store: email, chat, backups, full disk encryption, code repositories, cloud tokens, password vaults. Next to each, write the number of years the contents must remain confidential. The threat here is misdirected effort. A session key that dies in minutes is not the problem. A decade of archived messages is.
2. Rank by confidentiality lifetime and start at the top. Anything that must stay secret for ten years or more is your priority, because that is the window in which a future decryption capability becomes useful to whoever copied it. Rotate or delete long lived archives you no longer need, since data you do not hold cannot be harvested from you. The threat is that forgotten backups quietly become the most valuable thing an adversary has on you.
3. Turn on hybrid key exchange wherever it already exists. Recent browsers and TLS libraries support hybrid key agreement that combines a classical curve such as X25519 with a post quantum component, so a session stays safe unless both are broken. In Tor Browser and mainstream browsers this is enabled by default in current versions; confirm it in the connection or security panel rather than assuming. For SSH, prefer hybrid key exchange algorithms when both ends support them. The threat defended here is the recorded session: a hybrid handshake cannot be unwound later by quantum attack alone.
4. Keep your symmetric encryption strong and stop worrying about it. Use AES 256 in GCM mode or ChaCha20 Poly1305 with full length keys, and never reuse a nonce. Grover's algorithm offers only a square root speedup against symmetric ciphers, so doubling the key length restores the margin. The threat that actually bites in practice is implementation error, not a mathematical break, which is why nonce discipline and correct key handling matter more than algorithm shopping.
5. Move secrets out of chat and into a tool that encrypts values in place. SOPS encrypts only the values inside YAML, JSON, environment and similar files, leaving the keys readable so diffs stay reviewable, and it works with age keys, cloud key management services or Vault. The threat is that a secret pasted into a chat window lives on in logs, backups and notification history, and it is painful to rotate once it has spread. Encrypting values inside version control gives you an audit trail and a single place to rotate.
6. Shorten the life of tokens and credentials, then plan your algorithm swaps. Follow current NIST and CISA token guidance: bind tokens to the sender, prefer short lived credentials, and detect replay so a stolen token has a narrow window. Then write down every place an algorithm is pinned, from PGP keys used for stored messages to TLS settings in your own services, and confirm you can change each one without rebuilding everything. The threat is a migration that fails on hardcoded algorithms and forgotten clients, leaving you stuck on the old scheme long after a replacement exists.

None of this requires you to predict when quantum computing matures. It requires knowing what you hold, how long it must stay secret, and how quickly you can change the locks. Do the inventory first, fix the long lived data, and keep the rest of the list as a standing maintenance task rather than a one time project.