MODULE 6 · LESSON 1
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolThe One Urgent Thing
If your organisation does one thing in response to quantum computing, it is this, and it is a software project rather than anything involving quantum hardware.
The deadline does not depend on the hardware
Module 3 introduced harvest now, decrypt later. Here it is as a planning tool.
An adversary records your encrypted traffic today and stores it. Storage is cheap and patience is free. When a capable quantum computer eventually exists, they decrypt the archive.
The consequence is that for long lived secrets, the exposure begins the moment the data is transmitted, not the moment the computer is built.
This is unusual and worth sitting with. Ordinarily a security control needs to hold until the threat arrives. Here the interception happens now and the decryption merely waits, so debates about whether capable machines appear in 2032 or 2045 do not change what you should do about data that must stay secret for twenty years.
Mosca's inequality
Michele Mosca formulated the test, and it needs three numbers.
- X, how long your data must remain confidential.
- Y, how long your migration to post-quantum cryptography will take.
- Z, how long until a cryptographically relevant quantum computer exists.
If X plus Y is greater than Z, you have a problem, and you have it now.
Work an example. Suppose your organisation holds records that must stay confidential for 15 years, and a realistic migration across your systems takes 5 years, which is not pessimistic for a large estate with embedded systems and third party dependencies. X plus Y is 20. If a capable machine plausibly exists within 20 years, and few informed people would rule that out, then data you transmit today is already exposed.
Notice the structure of the argument. It does not require you to predict Z accurately. It requires you to decide whether Z is plausibly less than X plus Y, which is a far easier judgement and usually resolves the same way.
Notice too that Y is the number you control. Migration duration is the lever available to you, and it is why organisations that start early face an easier problem than those that wait for certainty.
The replacements exist
Encouragingly, this is not a problem awaiting a solution. In August 2024, after an eight year international competition, NIST published the first post-quantum standards.
| Standard | Algorithm | Replaces |
|---|---|---|
| FIPS 203 | ML-KEM, from CRYSTALS-Kyber | Key exchange, so RSA and Diffie-Hellman for establishing connections |
| FIPS 204 | ML-DSA, from CRYSTALS-Dilithium | Digital signatures, the general purpose choice |
| FIPS 205 | SLH-DSA, from SPHINCS+ | Digital signatures, hash based, as a backup with different security assumptions |
The presence of two signature standards is deliberate. ML-DSA and ML-KEM rest on lattice problems, while SLH-DSA rests only on hash function properties. If an unexpected weakness were found in lattice mathematics, the hash based alternative would remain, which is prudent design rather than indecision.
Deployment is already underway. Major browsers and cloud providers support post-quantum key exchange for connections, frequently in hybrid mode where a classical and a post-quantum algorithm are combined so that security holds if either survives. You are very likely already using it without having noticed.
Guidance points to deprecating RSA and elliptic curve cryptography around 2030 and disallowing them around 2035, with US federal deadlines for high value systems clustered around 2030 and 2031. Treat specific dates as directional, since they are periodically revised, and treat the direction as settled.
The first practical steps
Migration is mostly an inventory problem, and the first phase requires no cryptographic expertise.
1. Find out where cryptography is used. This is the hard part and it takes longer than anyone expects. It is not only your web servers. It is VPNs, code signing, database encryption, backups, hardware security modules, embedded devices, vendor products, APIs and anything with a certificate. Most organisations discover they have no reliable inventory.
2. Identify long lived secrets. Apply Mosca's inequality per data class rather than to the organisation as a whole. Data that becomes worthless in eighteen months is not urgent, whatever the headlines suggest. Personal data with long retention obligations, health records, intellectual property and anything under a long confidentiality agreement are urgent.
3. Ask your vendors. Any supplier providing cryptographic functionality should have a post-quantum roadmap. Their answer, or their inability to give one, is useful information about your real timeline, since you cannot migrate faster than your dependencies.
4. Prioritise crypto agility. Perhaps the most valuable structural outcome. Systems where the algorithm is a configuration choice rather than hard coded can be updated when standards evolve. Given that further post-quantum standards are expected and that any of them could later need replacing, the ability to change algorithms without rewriting applications has value beyond this particular migration.
5. Enable hybrid modes where offered. Low risk and available now in many products.
Note that none of these five steps require you to predict when quantum computers arrive.
Replacing one algorithm with another sounds like a library upgrade. Several factors make this among the largest cryptographic transitions ever attempted.
Scale and invisibility. Public key cryptography is embedded everywhere, usually invisibly. Organisations routinely discover cryptographic dependencies in systems nobody thought of as cryptographic, and in products whose vendors no longer exist.
Key and signature sizes. Post-quantum algorithms generally use larger keys and signatures than the algorithms they replace. Usually this is unimportant, and occasionally it is not: protocols with fixed size fields, embedded devices with tight memory, and systems where a certificate must fit in a single network packet can all be genuinely disrupted. Some constrained devices cannot accommodate the new algorithms at all and will need hardware replacement.
Hardware lifetimes. Devices deployed today with cryptography burned into firmware may still be operating in fifteen years. Industrial control systems, medical devices, vehicles and smart meters have long lives and limited update paths. Anything shipped now without crypto agility is a future problem being manufactured today.
The long tail. Migrating the main website is straightforward. Migrating the forgotten internal service maintained by nobody, or the vendor appliance whose supplier was acquired twice, is where the years go.
Standards will keep moving. NIST has additional algorithms in progress, and any current standard could later be weakened by cryptanalysis, as has happened before to candidates in this very competition. Planning for one migration is planning wrongly; the goal is the ability to migrate repeatedly.
This is why serious guidance emphasises starting the inventory now rather than waiting for a deadline. The inventory is the long pole, it requires no cryptographic expertise to begin, and it delivers value regardless of what the timeline turns out to be.
An organisation holds records requiring 15 years of confidentiality, and estimates a 5 year migration. Applying Mosca's inequality, when should it act?
Mosca's inequality
Click to flipIf X, the confidentiality lifetime, plus Y, the migration duration, exceeds Z, the time until capable machines, you have a problem now.
Click to flip backThe cryptography migration is the one urgent response, and it is a software project. Its deadline does not depend on when quantum computers arrive, because harvest now, decrypt later means interception happens today and decryption merely waits. Mosca's inequality makes this concrete: if confidentiality lifetime plus migration duration exceeds the time to capable machines, you have a problem now, and migration duration is the number you control. The replacements already exist as NIST standards. Start with the inventory, which is the long pole, needs no cryptographic expertise, and pays off regardless of the timeline.