Organisations should begin preparing their encryption systems for quantum threats before the technology becomes widely usable, two FTI Consulting specialists warn in an October 2026 article for Risk Management Magazine. Their concern is that information stolen now could remain valuable long enough to be decrypted later, while replacing vulnerable cryptography could take years.
The warning has implications for UK and European organisations holding sensitive records or operating infrastructure that must remain secure over long periods. It is not a report of a successful quantum attack: the timing of practical quantum decryption remains uncertain. Rather, it identifies a mismatch between the lifespan of confidential information and the time available to change the systems protecting it.
What happened
Writing in Risk Management Magazine, Mike Driscoll, who leads FTI Consulting’s national security practice, and cybersecurity senior adviser Greg Berkin argue that quantum readiness needs its own security strategy. Investment in artificial intelligence preparedness, they say, does not address the distinct cryptographic risks posed by quantum computing.
Their assessment centres on public-key cryptography, which underpins many mechanisms for protecting information and establishing digital trust. A sufficiently capable quantum computer could defeat widely used public-key methods. That does not mean all encryption is already ineffective, or that present-day quantum machines can routinely break corporate security.
The more immediate exposure is the possibility that attackers are collecting encrypted information in anticipation of future advances. According to the article, the US National Institute of Standards and Technology, or NIST, has warned that such collection may already be happening. An organisation could therefore lose control of information today without its contents becoming readable until much later.
For security leaders, this changes how data theft must be assessed. The relevant question is not simply whether an intercepted file can be opened now, but whether it will still require protection when more powerful computing becomes available. The authors recommend prioritising migration according to both the sensitivity of information and the length of time it must remain confidential.
The report also identifies potential exposure in industrial control systems supporting electricity, water treatment and transport. These environments often depend on older cryptographic arrangements. Critical military systems using cryptographic keys face a related concern, although the article gives no examples of operational disruption caused by quantum attacks.
Responsibility extends beyond technical teams because migration requires sustained funding and executive support. That governance challenge echoes the debate over making emerging technology risk a boardroom responsibility, although the technical work needed for quantum resilience is different from managing AI.
The background
There is already a standards base for organisations planning the transition. NIST published its first three post-quantum cryptography standards in August 2024, providing methods intended to withstand attacks from quantum computers. Their availability means preparation need not wait for a reliable forecast of when the threat will become practical.
The standards programme is continuing to develop. The article notes that NIST issued draft post-quantum updates for personal identity verification standards in June 2026. These are US initiatives, but they provide a technical reference for security planning beyond the United States; the article does not identify a corresponding UK or European compliance deadline.
Implementation nevertheless reaches well beyond choosing a new algorithm. Organisations first need to establish where cryptography is used across their systems and which tools depend on vulnerable methods. Without that inventory, they cannot reliably identify the scope, cost or sequence of a migration.
Supplier dependencies add another layer. Cloud services, specialist hardware, software providers and research partners can have access to sensitive information while operating different security controls. The broader exposure is illustrated by data risks in partner marketing systems, though that incident is not evidence of a quantum threat. Driscoll and Berkin recommend obtaining suppliers’ post-quantum migration plans before onboarding them and designing modernised systems so their cryptography can be changed as requirements evolve.
What people are saying
Driscoll and Berkin’s argument also addresses organisations developing quantum capabilities themselves, rather than simply defending against their use by others. In Risk Management Magazine, they warn that the complex supply chains and operational technologies supporting these projects need protection in their own right. A research or development programme can create security exposure before it delivers a useful quantum capability.
That distinction broadens the discussion beyond encryption replacement. Introducing quantum technology can involve granting access to corporate networks, proprietary algorithms and operational assets. The authors’ concern is that enthusiasm for the technology’s potential could outpace scrutiny of what those connections permit. Security assessment therefore needs to accompany experimentation, not begin only when a system is ready for wider use.
The competitive pressure is also geopolitical. The authors argue that whoever first achieves practical quantum capabilities could secure advantages extending beyond commercial performance. For organisations pursuing their own programmes, that creates a difficult balance: pressure to accelerate development does not remove the need to examine the security consequences of each deployment.
Their recommended assessment reaches into policies, employee awareness and alignment among stakeholders. These are separate questions from whether a particular algorithm is vulnerable. An organisation may understand its technical exposure yet lack agreed procedures for deciding who can accept migration risks or authorise changes affecting several business functions.
Berkin, who also serves as a fellow at Stanford University’s Center for Responsible Quantum Technology, and Driscoll recommend bringing in external post-quantum cryptography specialists. They present that expertise as a way to obtain network assessments and migration advice tailored to the organisation, reflecting the scientific complexity and continuing development of the field.
The article does not provide comparative evidence on migration products or name preferred suppliers. Its recommendation to seek specialist assistance should therefore be read as a call for informed assessment, not an endorsement of a particular commercial solution. Buyers would still need to establish whether proposed work addresses their own systems and operational constraints.
What happens next
The next practical step in the authors’ programme is to turn assessment findings into milestones and delivery dates. A roadmap needs to distinguish work that can begin immediately from changes dependent on further technical development. Without that distinction, a readiness programme risks becoming a statement of intent rather than a schedule against which progress can be measured.
They also recommend piloting mitigation approaches now. For continuity teams, the value of a pilot is the opportunity to examine implementation before committing to wider change. Testing can help establish whether a proposed approach fits the operating environment; adoption of a standard alone does not demonstrate that a particular deployment will work as intended.
Financial planning requires similar specificity. The authors call for forecasts of mitigation costs to be incorporated into future budgets. The article supplies no cost estimates, so organisations cannot derive a credible spending requirement from it alone. That will depend on the work identified through their own assessments and trials.
Before new technology is deployed, the recommended checks include data privacy concerns and any additional routes into systems. This gives security teams a concrete review point: consider not only the protection offered by a new capability, but also the information and access it requires to operate.
For UK and European programmes, evolving regulatory requirements will also need to be tracked alongside technical progress. The authors explicitly recommend aligning roadmaps with changing standards. The resulting task is to keep implementation plans under review, updating milestones when requirements change while preserving a clear record of what has been tested and what remains unresolved.
