Post-Quantum Cryptography: What Businesses Should Do Now (and What Can Wait)

The risk in plain language

Much of the internet's security rests on public-key cryptography, such as RSA and elliptic curves, which protects website connections, software updates and digital signatures. A sufficiently powerful quantum computer could break these methods. No such machine exists today, but governments and standards bodies are planning for the day one might, because replacing encryption across the world takes many years.

The nearer-term worry is harvest now, decrypt later: an attacker copies encrypted traffic or files today and waits until they can decrypt them. For data that must stay confidential for ten or twenty years, that future risk is already relevant.

What has been standardised

In August 2024, the US standards body NIST finalised its first post-quantum standards, including ML-KEM for key exchange and ML-DSA and SLH-DSA for digital signatures. Government guidance and vendor commentary discuss milestones around 2030 for moving away from older public-key methods and 2035 for disallowing them. Dates vary between sources and countries, so check the latest official guidance, for example in this October 2026 overview of NIST's plan and what it means for companies and suppliers.

Major browsers, content delivery networks and cloud providers have already started supporting hybrid key exchange, which combines classical and post-quantum methods. In many cases you benefit simply by keeping your hosting, browsers and libraries up to date.

What most businesses should do now

1. Take a cryptographic inventory. List where you use encryption and signatures: websites and APIs, VPNs, email, stored backups, code signing, payment providers and devices. A short spreadsheet is a good start.
2. Classify data by lifespan. Which data would still harm you or your customers if it were read in ten years? Prioritise it.
3. Ask your suppliers. Cloud, hosting, SaaS and payment vendors should have a post-quantum plan. Add the question to your next review.
4. Keep software current. Updated operating systems, TLS libraries and browsers will bring support automatically.
5. Design for crypto-agility. Avoid hard-coding algorithms or key sizes, so that you can change them without rewriting systems.
6. Never invent your own cryptography. Use maintained libraries and standard protocols.

What can wait

• Replacing every system immediately. Migration will be gradual and vendor-led for most organisations.
• Buying expensive 'quantum-proof' products that make vague claims. Ask which standard they implement and how it is tested.
• Panic. Your most pressing security risks today are still unpatched servers, weak authentication and phishing, as incidents like PHP2Shell and the Binance hack show.

Special cases

Pay closer attention if you handle long-lived confidential data, build products with a long service life, such as devices or embedded systems, or serve government and regulated customers who may require post-quantum readiness in contracts. In those cases, start the inventory sooner and involve your security team or advisers. Also see our guide on private AI versus cloud APIs, which covers where sensitive data goes.

If you are planning a new product and want security decisions made sensibly from day one, our web app development team can help you design for change. This article is general information, not security or compliance advice.