The Long Shelf Life of Secrets: Britain's Encrypted Data and the Quantum Cupboard
Somewhere in a data centre, a storage array is quietly filling with old emails. Not because anyone loves your meeting notes, but because they might be readable in 2035. The idea is called 'harvest now, decrypt later': copy encrypted data today, keep it in the quantum cupboard, and wait for a future machine to turn the lock. It sounds like science fiction with a filing problem. Unfortunately, it is also a procurement problem.
The cupboard under the stairs
Most of the encryption holding up the internet relies on maths that is hard for ordinary computers and, in theory, easy for a sufficiently powerful quantum computer. The usual suspects are RSA and elliptic-curve cryptography, which guard everything from bank transfers to NHS logins to the padlock on a council planning portal. A large, fault-tolerant quantum computer running Shor's algorithm could, in principle, break them. We do not have one yet. The timelines are debated, the engineering is ferocious, and anyone who claims to know the exact date is probably selling something.
But 'harvest now, decrypt later' does not require a working quantum computer today. It requires cheap storage and patience. An attacker copies encrypted traffic or swipes a backup, then waits. If the secret is still valuable when the lock finally opens, the delay was worth it. Your old takeaway order has a short shelf life. Your medical record, legal correspondence, pension data or intellectual property may still be sensitive in a decade.
What is actually in the cupboard?
The first useful question is not 'Is quantum computing real?' It is 'Which secrets would still matter in 2040?' A lot of data is boring by design. If someone reads last week's rota or a forgotten restaurant booking, the damage is minimal. The problem starts with information that has a long confidentiality life: health records, financial histories, identity documents, legal advice, research data, source protection, diplomatic cables, and the sort of commercial plans that make lawyers reach for the good stationery.
Public services have a particular version of this. A council may hold social care records, planning objections, benefits data and old case files. The NHS holds information that people expect to remain private for life. HMRC and the wider public sector hold data with legal and personal consequences that do not expire when the server is replaced. The uncomfortable truth is that a backup from 2019 may outlive the system that made it, the vendor that supplied it and the officer who knew the password. That is not a quantum problem. It is an archive problem with a quantum deadline.
The hype aisle
This is where the scepticism comes in. 'Quantum-proof' is doing an awful lot of work in a lot of marketing decks. No sensible migration starts with a purchase order for a magic box. It starts with knowing what you have. Vendors will sell you quantum random number generators, quantum key distribution, post-quantum cryptography, crypto-agility platforms and probably a laminated maturity model. Some of these are useful. None of them is a substitute for a cryptographic inventory.
Post-quantum cryptography is also not a single product. It is a set of new algorithms, standardised after years of public scrutiny, designed to run on ordinary computers. In 2024, NIST published the first tranche of these standards, and organisations are now being told to plan migration. The NCSC's public steer is broadly: understand the risk now, migrate high-risk systems by 2035, and do not wait for a quantum computer to appear on the horizon. That is less exciting than a headline about doomsday, but more useful than a branded fridge magnet.
What migration actually involves
Migration is IT hygiene with a calendar. First, build a cryptographic inventory: where is encryption used, which algorithms are in play, which systems depend on them, and who owns them? This is sometimes dressed up as a 'cryptographic bill of materials'. The phrase is ugly, but the idea is sound. You cannot prioritise what you cannot see.
Second, classify the data. A ten-year-old marketing email is not the same as a lifetime health record. Third, map the dependencies. Your payroll system may be fine; the ancient interface between payroll and the pension provider may not be. Fourth, talk to suppliers. If your software vendor has no migration plan, that is a risk with a logo. Fifth, test hybrid approaches, where old and new cryptography run together during the transition. Sixth, put dates and owners in a governance document that survives the next reorganisation.
None of this requires ripping out every lock on Monday. It requires a plan that treats cryptography as infrastructure rather than a one-off purchase. The UK's public sector will find this harder than the private sector in some ways: procurement cycles are long, legacy systems are plentiful, and budgets are contested. But the same is true of banks, law firms, universities and any organisation that has ever said 'we'll fix that in the next upgrade'.
A sensible panic schedule
So what should a UK organisation do in 2026? Start the inventory. Put post-quantum migration in the risk register, not the science fiction shelf. Ask suppliers awkward questions. Prioritise the systems where a leak in 2035 would cause real harm, not the ones that make the prettiest pilot project. Train the people who buy and build systems, because the next encryption mistake will probably be made by someone who thought 'quantum' was someone else's department.
The quantum cupboard is not a monster. It is a filing cabinet with a future. Tidy it now, while the tea is still hot, and the eventual quantum computer becomes a manageable deadline rather than a surprise audit with better maths.