Cryptography that protects today’s web traffic and software updates is expected to need replacing before large quantum computers arrive. This article explains which standards now exist, what the UK’s National Cyber Security Centre (NCSC) asks organizations to do and by when, and how a small or mid-sized business can begin without panic.
Why would quantum computers threaten today’s encryption?
Most secure connections rely on two kinds of cryptography working together. Symmetric encryption scrambles the bulk of the data using a shared secret. Asymmetric, or public-key, cryptography is used to agree on that secret safely and to prove who is who through digital signatures. Public-key methods depend on math problems that are very hard for ordinary computers.
According to the NCSC, the threat from future large-scale, fault-tolerant quantum computers “is now well understood”: such machines could efficiently solve the hard mathematical problems that public-key cryptography relies on. The NCSC calls the affected systems “quantum-vulnerable traditional” public-key cryptography, and its guidance centers on that category rather than on symmetric encryption.
Nobody in the sources reviewed here claims such a machine exists today. The planning problem is timing: replacing cryptography across an organization takes years, and some data must stay confidential for longer than that.
What are the new post-quantum standards?
Post-quantum cryptography (PQC) means algorithms designed to resist attacks from both classical and quantum computers. They run on ordinary hardware; they are not “quantum” products.
On August 13, 2024, the US National Institute of Standards and Technology (NIST) released its first three finalized PQC standards:
| Standard | Algorithm | Purpose |
|---|---|---|
| FIPS 203 | ML-KEM (formerly CRYSTALS-Kyber) | General encryption: establishing shared secrets over public networks |
| FIPS 204 | ML-DSA (formerly CRYSTALS-Dilithium) | Digital signatures |
| FIPS 205 | SLH-DSA (formerly Sphincs+) | Digital signatures, using a different mathematical approach as a backup |
NIST says ML-KEM uses comparatively small keys that two parties can exchange easily and that it runs quickly. SLH-DSA serves as a fallback if ML-DSA turns out to be vulnerable. NIST’s page states that the standards “can be implemented now” and are “mandatory for federal systems.” NIST mathematician Dustin Moody said at release: “We encourage system administrators to start integrating them into their systems immediately,” adding that there is “no need to wait for future standards.”
On March 11, 2025, NIST selected a fifth algorithm, HQC, as a backup for general encryption. It is built on error-correcting codes rather than the structured lattices behind ML-KEM, so a flaw in one family would not automatically affect the other. NIST says ML-KEM remains the recommended choice, that HQC needs more computing resources, and that a final HQC standard is planned for 2027 after a public comment period.
What does the NCSC timeline ask of organizations?
The NCSC has published three milestones for moving to PQC:
- By 2028: define migration goals, carry out a full discovery exercise to find what depends on cryptography, and build an initial migration plan.
- By 2031: carry out the earliest, highest-priority migration activities and refine the plan into a full roadmap.
- By 2035: “complete migration to PQC of all your systems, services and products.”
The 2028 milestone is mostly paperwork and investigation, which is good news for smaller organizations. It asks for knowledge before it asks for engineering. The NCSC also tells organizations to assess how long their data must stay confidential and how valuable it would be to an adversary, which is the logic for prioritizing some systems first.
The NCSC names ML-KEM, ML-DSA and SLH-DSA as the most widely used PQC standards. It describes two other schemes, LMS and XMSS (covered in NIST SP 800-208), as having more limited uses, and says it will publish specific configuration guidance later.
Which of your data is most exposed?
Not every system carries equal risk. A useful test is the shelf life of what you protect. A session cookie that expires in an hour has little long-term value. A merger agreement, a patient record, source code or a customer identity file may need confidentiality for a decade or more.
If an adversary can copy encrypted traffic today and wait for stronger tools later, long-lived secrets are the ones at risk. That is why the NCSC’s advice to weigh confidentiality lifetime against adversary value matters. Systems that sign things, such as software updates or device firmware, are a separate concern, because devices in the field may be impossible to update after their signing method is broken.
How do you find where cryptography lives?
Discovery is the first real task, and it is harder than it sounds because cryptography is rarely listed in one place. A starting inventory usually covers:
- Network connections: websites, APIs, VPNs and internal services that use TLS (transport layer security, the protocol behind the padlock in a browser).
- Identity and signing: certificates, single sign-on, code signing and document signing.
- Stored data: encrypted databases, backups and disk encryption, including how keys are protected.
- Third parties: payment providers, cloud platforms and software vendors who handle cryptography on your behalf.
- Hardware: devices, badges, hardware security modules and anything with a long service life.
For each entry, record what algorithm is used, who owns it, how long the protected data matters, and whether the vendor has a published PQC plan. A spreadsheet is a legitimate first tool. If you already keep a software and services list for security reviews, as suggested in the cybersecurity basics for small teams, extend it rather than starting over.
Is this mainly a vendor problem for small businesses?
Largely, yes. Most small organizations do not implement cryptographic algorithms themselves; they inherit them from browsers, operating systems, cloud services and SaaS tools. The NCSC notes that some browsers already combine traditional key exchange with ML-KEM, but that the exact mechanism has not been standardized across the industry and may change.
That means your job is mostly to ask good questions and keep software current. Under the shared responsibility model for SaaS security, the provider secures the platform, but you still need to know what they are doing. Reasonable questions for suppliers include:
- Do you have a published plan and timeline for post-quantum cryptography?
- Which of the NIST standards do you intend to support, and when?
- Can you tell us which of our data is protected by which algorithms?
- How will certificate and key changes be communicated to us?
Where a vendor has no answer, note that in your inventory. It is a signal for procurement decisions, not necessarily an emergency.
What does cryptographic agility mean in practice?
The NCSC advises building “cryptographic agility,” meaning the ability to swap one algorithm for another without redesigning a whole system. The existence of backup algorithms like SLH-DSA and HQC shows why: NIST itself says it must be “prepared in case of an attack that defeats the algorithms in these three standards.”
Agility is largely ordinary good engineering:
- Avoid hard-coding algorithm names and key sizes in application code.
- Keep certificates and keys in managed systems with clear rotation processes.
- Prefer protocols and libraries that negotiate algorithms rather than fixing one.
- Test updates regularly, so that a cryptographic change is routine, not a crisis.
Teams that already apply patches on a disciplined schedule, as described in the CISA patch prioritization explainer, will find this easier, since much of migration arrives as software updates.
A simple planning sequence for the next three years
The following sequence is illustrative and fits the NCSC’s framing. It is not an official checklist.
| Period | Focus | Output |
|---|---|---|
| Now to 12 months | Inventory and ownership | List of systems, algorithms and vendors |
| Months 12 to 24 | Risk ranking | Ordered list based on data shelf life and exposure |
| Months 24 to 36 | Plan and supplier pressure | Initial migration plan, written vendor requirements |
| Following years | Early migration of top priorities | Pilot upgrades on the most critical systems |
Notice that the first three rows involve no new technology purchases. A plan with named owners and dates will place an organization well ahead of the NCSC’s 2028 milestone.
Combine this with the basics from zero trust security for small teams: limiting what any single credential or connection can reach reduces the damage if any one protection fails, whether the cause is quantum or ordinary.
Conclusion: start with an inventory, not a panic
The post-quantum transition is a long migration with published standards, a public timeline from the NCSC, and no known need for emergency action by a small business. The sensible response is steady: find where public-key cryptography is used, rank by how long the protected data matters, ask suppliers for their plans, and design new systems so algorithms can be changed. Standards may still evolve, as the HQC addition shows, so treat any plan as a living document and recheck official guidance from NIST and the NCSC each year.
This article provides general information only and is not security, legal or compliance advice. Check requirements that apply to your organization and jurisdiction.
Sources: National Institute of Standards and Technology; National Cyber Security Centre
