Quantum risk starts with the data your business needs to keep secret
Encrypted information captured today could become readable later. UK businesses should identify long-lived secrets, establish supplier responsibilities and plan supported upgrades before committing to a costly migration.
Yes. Encrypted company data captured today could become readable if a future quantum computer can break the cryptography protecting its keys, the threat described in Cloudflare’s technical guidance. Our position is that UK small and mid-sized businesses should start by identifying long-lived confidential information and requiring clear upgrade commitments from suppliers. FIPS 203 already standardises ML-KEM for key establishment, while the NCSC sets migration targets of 2028, 2031 and 2035. The strongest objection is that suppliers may handle routine upgrades; that makes visibility and supplier coordination the first priority, not an immediate wholesale replacement.
The business question is how long a secret must last
Our editorial position is that confidentiality lifetime should drive the first assessment.
Consider a hypothetical British engineering supplier. A delivery notification may lose its commercial sensitivity quickly. A confidential manufacturing design could remain valuable through several product generations. The business should assess those information flows separately, even if both pass through the same cloud platform.
“Harvest now, decrypt later” means collecting encrypted information for a future attempt to recover its contents. The attack depends on obtaining useful encrypted material and eventually defeating the relevant protection. It does not establish that a particular company has already been targeted or that every encrypted archive will become readable. Cloudflare’s documentation explains the threat specifically for captured communications and vulnerable key agreement.
For a business owner, the useful questions are therefore concrete. Which information would still cause damage if disclosed years from now? Where does it travel? Who controls the technology protecting it?
An implication follows from that threat model. Upgrading a connection later cannot retrieve a copy already held by an attacker. That makes long-lived confidentiality a reason to investigate current exposure, even without a reliable date for a capable quantum computer.
Find the vulnerable dependency before buying a replacement
The phrase “quantum computers will break encryption” obscures the work buyers actually need to commission.
TLS separates the algorithm protecting the data from the mechanism establishing its shared key and the signatures used for authentication. Cloudflare identifies elliptic-curve key agreement as vulnerable to sufficiently powerful quantum computers and describes deploying hybrid key agreement that combines traditional and post-quantum mechanisms. Its technical explanation supports investigating those components separately.
The ML-KEM standard addresses establishing a shared secret over a public channel. That secret can then be used with symmetric cryptography for encryption and authentication. It is not a complete replacement specification for an application, backup service or network. FIPS 203 defines that boundary.
Ask an IT provider to identify the affected protocol, implementation and supported upgrade. A proposal that simply promises to “replace your encryption” has not yet described a reviewable job.
Put an owner against every part of the journey
For an illustrative customer portal, information might pass from a browser to an edge provider, then to an application server and onwards to storage or another service. Cloudflare documents the separate browser and origin connections; any additional connections must be identified from the business’s actual design.
The following is a proposed responsibility split, not a description of a particular supplier’s contract.
| Part of the service | Proposed accountable party | Evidence to request |
| --- | --- | --- |
| Business information | Business owner | Sensitivity, required confidentiality lifetime and consequences of disclosure |
| Browsers and devices | Internal IT or managed IT provider | Supported versions, update coverage and any compatibility exceptions |
| Public website connection | Hosting or edge provider | Exact connection and cryptographic functions covered by its implementation |
| Connection to the application | Application operator and hosting provider | Negotiated protection, configuration requirements and fallback behaviour |
| Stored records and backups | Application and backup owners | Encryption design, key protection, recovery dependencies and upgrade route |
| Custom integrations | Developer or integration provider | Library dependencies, supported changes, test results and rollback procedure |
The buyer should retain ownership of the inventory. Outsourcing the technical investigation should still leave the business with a usable record when it changes providers.
Use the UK roadmap to organise investment
The NCSC’s roadmap gives organisations milestones around which to plan. Its annual review specifies 2028 for an initial plan covering the estate, 2031 for migrating the highest-priority services and refining that plan, and 2035 for completing migration across systems, services and products. These are the NCSC’s stated targets.
Those dates should not become a sales claim that every UK business must buy a particular product. The NCSC’s announcement describes guidance and says many smaller organisations will receive migration through routine supplier upgrades. It also recognises that some larger organisations face significant planning and investment.
Our recommendation is to use renewal and replacement decisions to establish an upgrade route. Before extending a contract, ask what the supplier will deliver, what remains your responsibility and which unsupported dependencies could prevent adoption.
A smaller business using standard hosted applications may need supplier coordination and update management. A mid-sized manufacturer with custom applications and long-lived equipment should budget for a more detailed dependency assessment.
Compare suppliers on scope and evidence
A fair comparison between Cloudflare, Google, AWS and a UK managed provider requires documentation for the particular service being bought. Evidence about one provider cannot establish another’s readiness.
Cloudflare provides a concrete example of why scope matters. Its documentation describes deployed hybrid key agreement and post-quantum signature support for authentication between Cloudflare and an origin server. Its separate announcement explains the configuration context for that origin authentication. Neither statement establishes protection across an entire customer estate. The documentation and origin announcement describe specific boundaries.
For Google, AWS and prospective UK providers, equivalent service-level evidence is needed before making a capability ranking. Compare the same items across quotations: protected connections, supported client versions, key agreement, authentication, customer configuration, exclusions and acceptance tests.
Self-hosting belongs in that comparison where it is already a credible operating choice. Our assessment is that it warrants particular attention to who maintains the cryptographic libraries and tests compatibility. Control over deployment is useful only when someone has the skills and time to exercise it.
Budget for the work surrounding the upgrade
No comparable supplier prices are established here, so a defensible budget must remain conditional.
Request separate costs for discovery, software or hardware changes, deployment, compatibility testing, staff training and ongoing support. Ask whether those activities are included in existing subscriptions or require additional professional services.
The quotation should also price recovery testing and rollback preparation where relevant. A supported cryptographic feature is only one input into a successful service change.
For a smaller business, our preferred first purchase would be a bounded assessment with tangible outputs: a dependency inventory, supplier questions and a prioritised action list. Commit to a broader migration once its scope and acceptance criteria are clear.
Editorial analysis
The strongest reason to prepare is the mismatch between how long information can remain sensitive and how slowly a business may replace the systems protecting it.
The counterargument deserves attention. A small company should not divert its entire security budget into a specialist migration that its suppliers may deliver through ordinary upgrades. The NCSC explicitly anticipates routine supplier-led migration for many smaller organisations.
Our judgement is to fund visibility first, then action in proportion to the findings. A useful initial result is a list of important information flows, named owners and documented supplier commitments. That gives the next renewal or technical change a basis in evidence.
FAQ
Could someone decrypt our company’s encrypted data in the future?
Potentially, if they obtain encrypted material whose protection can later be defeated. Cloudflare describes this risk for communications using quantum-vulnerable key agreement. Whether it applies to a particular archive or service requires examining its encryption and key protection.
Should we replace our cloud provider now?
We would not recommend switching solely because a provider lacks a broad “quantum-safe” marketing claim. Request evidence for your actual services, their upgrade routes and your responsibilities. The NCSC expects many smaller businesses to receive changes through normal supplier upgrades.
Does post-quantum key agreement also protect authentication?
Not automatically. Cloudflare’s TLS documentation treats key agreement and digital signatures as separate migration tasks. Ask suppliers to describe both, including which connections their statements cover.
What should a UK business do first?
Identify information that must remain confidential for a long time and assign an owner to each service handling it. Then request a documented upgrade position from the relevant suppliers. This follows the discovery and planning direction of the NCSC’s migration roadmap.
Sources
- NIST — FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, published 13 August 2024.
- NCSC — Cyber chiefs unveil new roadmap for post-quantum cryptography migration, published 20 March 2025.
- NCSC — Annual Review 2025, Migrating to post-quantum cryptography, published 14 October 2025.
- Cloudflare — Post-quantum cryptography documentation, dated 3 July 2026.
- Cloudflare — Post-quantum authentication to origins is now supported, dated 3 August 2026.
