Sign inGet started

The Defence

Changing the Locks

8 min

The new locks exist. What is left is the fitting, and that is the part that takes years.

Wear both belts

Do not rip out the old scheme and drop in the new one. Run both, and mix the two secrets together into one key.

Hybrid key exchange
X25519classicalML-KEM-768post-quantumKDFconcatsession keysecure if either exchange holds
Run the classical and post-quantum exchanges side by side and mix both secrets into the session key. An attacker has to break both. This is what shipped in TLS across the major browsers, and it is the safe way to migrate.

Now an attacker has to break the old scheme and the new one. That covers you against two quite different worries at once: a quantum computer arriving, and somebody finding a flaw in an algorithm that is only a few years old.

This is not theory. Chrome and Firefox switched this on for a large share of web traffic, so there is a fair chance you are using it to read this page.

Find out what you have

Most organisations cannot answer "where do we use RSA?" That inventory is the real first job, and it is always longer than expected:

  • Website certificates and everything that issues them
  • Server login keys
  • Code signing, including firmware and app stores
  • VPNs
  • Security hardware and smartcards
  • Devices in the field with keys burned in at the factory
  • Every supplier and partner you connect to

Those last two are where the multi-year timelines come from. You do not control them.

Build so the next change is cheap

The lasting lesson is not "move to ML-KEM". It is that this will happen again.

Which algorithm you use should be a setting, not a design decision. No key sizes hardcoded. No assumptions about how long a signature is baked into a file format. A tested path for swapping one out without a rewrite.

Find it allthe long bitSort by risksecrecy yearsRun bothold + newStay flexiblenext time is easy

Do the risky things first

Start where the sum from lesson two bites hardest: long-lived secrets travelling over a network. Medical, legal, genetic, government, industrial designs.

Short-lived session data genuinely is lower priority. Somebody decrypting yesterday's expired login token in 2035 has achieved nothing at all.

Worth remembering

  • Run old and new together first — it protects against both a quantum attacker and a flawed new algorithm.
  • That combination already carries a large share of real web traffic.
  • Finding everything is the hard part, especially devices and suppliers.
  • Prioritise by how long the data must stay secret, not by what is easy to change.
  • Build so that the next swap is a setting, not a rewrite.