> But what I don't see is what I can practically do now, as either someone who is a CTO/Big Cheese™ or a lowly engineer?

Migrate! The major TLS and OpenSSH applications already support PQC, for example.

1. Make sure you have the required dependencies (e.g., openssl 3.5+ is when a lot of PQC algorithms got support).

2. Make sure the client/server software is up to date (this might be all that's needed, e.g., OpenSSH 10.0+ enables PQC in-transit encryption by default, and so does Chrome 131+).

3. Enable PQC support in the configuration (e.g., "ssl_ecdh_curve X25519MLKEM768;" in Nginx).

If you are the developer of anything that's explicitly using RSA or ECC (or god forbid Diffie-Hellman), you can also migrate your own software, or at least make the algorithm selectable at initialization time instead of hardcoded. If you have vendors, ask them for their PQC migration roadmaps.

Note that with encrypted data you want to protect yourself against attackers that are capturing data today and waiting to break it in the future (Harvest-Now, Decrypt-Later). So migrating encryption is more urgent than migrating authentication.

The most important thing to realize about cryptography is that, for most methods short of a Vernam cipher or quantum key distribution, coded messages need to be treated as published with delay. Cipher text can be archived today and attacked years from now with currently undeveloped, unknown, or unpredicted resources/algorithms. Sure, perhaps nobody archived the cipher text and you're fine. You don't know that for sure. Your methods may be very strong but, if they're not provably immune to attack, you also don't know what the delay before publication truly is. It might be a very long time. It might not.

If you're transmitting credit card info that changes every few years and can be changed on demand, that's no big deal. If you're transmitting information that will remain sensitive for decades, the time to look for methods that would stand up to quantum computing was years ago. However, today is still better than years in the future. At the very least, you can choose what to send in encrypted form over public networks and what not to send.

There are people who will scoff at the notion of quantum computing ever developing to the point where it can make an impact. There are people who scoff at the effort and expense of QKD or good ol' spooks carrying briefcases full of one-time PADs. You might be right to listen to them. You might not be. It's a risk. Whether you, or your organization, can tolerate that risk is entirely dependent on you and yours.

This is what Cloudflare[1] is doing.

[1] https://blog.cloudflare.com/post-quantum-roadmap/

If you're a CTO, have a post quantum strategy: know what crypto you use and where it is, plan to migrate to post quantum secure ciphers over the next decade or so, or sooner if possible. If you're a lowly engineer, not very much unless you're specifically selecting technologies with crypto. In which case crypto agility (being able to switch out existing crypto when needed) is a good property to look for.

Where available, you can migrate. Even if PQ is not yet available it helps to:

1. Make sure your dependencies are up to date. Move to a recent version of your crypto libraries. 2. Make sure your server can install multiple certificates: you'll need that unless you control all your clients. 3. Automate certificate issuance as far as possible.

Also, what you can do now is to run the following wargame: assume the CRQC arrived. What's the business impact?

For the migration itself I see three parallel streams.

1. Main push of straight-forward cases (TLS, etc.) Might need to wait a bit for software support.

2. Hard cases: crypto baked into hardware; custom protocols; keys in tight spaces (JWT in URLs); etc. You need to bubble those up soon to make decisions on how to fix them.

3. External dependencies. Barely any vendor has a PQ roadmap, so asking now is probably early, but you can figure out what to do if they don't get their stuff ready in time.

I think lobby for saner defaults (tip of the hat to Steve Gibson's term "the tyranny of the default"), configuring one's GPG config to mark certain cyphers as insecure (to prevent downgrade attacks)... and have one's (chief) information security officer write those things down as policy and maybe have a yearly onboarding workshop teaching people why it's important.

TLS can already be setup to avoid store-now-decrypt-later PQC issues. That's available today, and should be implemented. Use https://sslboard.com to inventory all your external TLS infrastructure and check for PQC readiness (creator here).