Post-Quantum Cryptography: Preparing for the Standards

Much of today’s internet security rests on mathematical problems that are hard for ordinary computers. Public-key systems such as RSA and elliptic curve cryptography protect secure web connections, digital signatures, software updates and many identity systems. A sufficiently powerful quantum computer could solve those problems quickly and break them.

Nobody can say precisely when such machines will arrive, and that uncertainty is the reason to prepare. Attackers can record encrypted traffic today and decrypt it years later, a pattern called harvest now, decrypt later. Standards for quantum-resistant cryptography now exist, and migration will take years for most organisations. This guide explains the standards, the risks and a practical roadmap, for a mid-sized company and for a bank or government agency.

What is at risk

Cryptography has two main families:

• Symmetric cryptography and hashing, such as AES and SHA-2 or SHA-3, used for encrypting data and checking integrity. Quantum algorithms weaken these by reducing effective strength, and larger key sizes and hash outputs restore a good margin.
• Public-key cryptography, such as RSA, Diffie-Hellman and elliptic curves, used to establish keys, sign documents and prove identity. These are the ones a large quantum computer would break outright.

Affected uses include:

• Secure web browsing and other encrypted connections, where public-key methods set up the session keys.
• Virtual private networks and secure email.
• Digital signatures on software, documents and certificates.
• Identity systems, smart cards and hardware security modules.
• Blockchain and digital asset signatures.
• Long-lived data protected by keys exchanged with vulnerable methods.

Why act before the machines exist

• Harvest now, decrypt later: adversaries may store encrypted data now, to decrypt it when they can. Health records, trade secrets, state secrets and financial agreements often need confidentiality for decades.
• Long migration times: cryptography is embedded everywhere: applications, devices, protocols, certificates and supply chains. Migration takes years.
• Long-lived devices: equipment in the field, such as industrial controllers and vehicles, may last fifteen years or more.
• Signature risks: keys that sign firmware or legal documents must remain trustworthy for the life of the product or record.
• Regulatory and customer expectations: governments and sector bodies are issuing timelines and requirements.

The standards

The US National Institute of Standards and Technology has run a long public process to select post-quantum algorithms. As described on its post-quantum cryptography project page, the first standards, published in August 2024, are:

• FIPS 203: the Module-Lattice-Based Key-Encapsulation Mechanism Standard, known as ML-KEM, for establishing shared keys.
• FIPS 204: the Module-Lattice-Based Digital Signature Standard, ML-DSA, for digital signatures.
• FIPS 205: the Stateless Hash-Based Digital Signature Standard, SLH-DSA, a signature scheme based on different mathematics, as a backup.

NIST has also selected the Falcon signature algorithm and the HQC key-encapsulation mechanism for further standardisation, and continues to solicit additional signature schemes. NIST says the three main standards can and should be put into use now.

On transition, NIST guidance under its report IR 8547 plans to deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning much earlier. Other governments and standards bodies publish their own timelines and approved algorithm lists, which may differ, so check requirements for the countries and sectors where you operate.

Hybrid approaches

During the transition, many deployments combine a classical algorithm with a post-quantum one, so that security holds if either remains unbroken. Internet protocol groups and vendors are defining hybrid key exchange for secure connections. Hybrid designs add some overhead, and they hedge against flaws in new algorithms.

Practical differences

Post-quantum algorithms often have larger keys, signatures or messages than classical ones. This affects:

• Network handshakes and packet sizes.
• Certificate chains and storage.
• Constrained devices with limited memory or processing power.
• Hardware security modules and smart cards, which may need firmware or hardware upgrades.
• Performance testing. Our guide to performance testing explains how to check the impact.

A migration roadmap

1. Governance and awareness

• Name an executive sponsor and a programme lead.
• Brief leadership on the risk and timelines.
• Include security, architecture, procurement, legal and business owners.

2. Build a cryptographic inventory

Find where cryptography is used:

• Applications and libraries, including hard-coded algorithms.
• Protocols: TLS, SSH, IPsec, S/MIME and others.
• Certificates and public key infrastructure.
• Hardware security modules, key management systems and smart cards.
• Databases, storage and backup encryption.
• Code signing, firmware signing and document signing.
• Third-party products, cloud services and embedded devices.
• Data flows to partners and suppliers.

Tools can scan code, binaries, network traffic and configurations to help. Record algorithm, key size, purpose, owner and lifetime. An inventory is also valuable for ordinary security management.

3. Assess and prioritise

Rank systems by:

• Data sensitivity and required confidentiality lifetime. Data that must stay secret for twenty years, shipped over links protected only by vulnerable key exchange, is a priority.
• System lifetime and ease of change. Long-lived, hard-to-update devices need early planning.
• Exposure: internet-facing and widely shared systems.
• Dependency on suppliers and standards.
• Regulatory deadlines.

4. Build crypto-agility

Design systems so algorithms can be replaced without rewriting everything:

• Use well-maintained cryptographic libraries and standard interfaces, and avoid custom cryptography.
• Keep algorithm choices in configuration so nothing is hard-coded.
• Centralise key management and certificate handling.
• Ensure systems can negotiate algorithms, and handle larger sizes.
• Test and monitor.
• Automate certificate renewal and rotation, which supports short lifetimes and faster change.

5. Engage suppliers

Ask vendors of software, hardware, cloud and managed services about their post-quantum plans, standards support and timelines. Include cryptographic agility and quantum-readiness criteria in procurement. Our guide to vendor management offers a framework.

6. Pilot and test

• Try hybrid key exchange on non-critical connections.
• Test post-quantum signatures in internal certificate authorities or code signing.
• Measure performance, compatibility and operational effects.
• Check monitoring and inspection tools that may not handle new algorithms.
• Learn from the pilots, and update the plan.

7. Migrate in stages

• Start with highest-risk confidentiality use cases, such as key exchange protecting long-lived data, and long-lived signatures.
• Move on to other systems according to priority.
• Maintain fallback and rollback.
• Update documentation, runbooks and training.
• Track progress against milestones.

8. Maintain

Standards and guidance will evolve. Follow updates, retire vulnerable algorithms on schedule and keep the inventory current.

Complementary measures

• Reduce data exposure: collect and keep less sensitive data, and delete data you no longer need.
• Strengthen symmetric keys and hash sizes where advised.
• Protect keys with good management and hardware protection.
• Layer security: zero trust, segmentation and monitoring reduce reliance on one control. See our guide to zero trust security.
• Quantum key distribution is a separate technology with limited practical deployment and different trade-offs, and it is not a general replacement for post-quantum algorithms.

Common mistakes

• Waiting until quantum machines are announced.
• No inventory, so nobody knows the exposure.
• Assuming the cloud provider or vendor will handle everything.
• Hard-coded algorithms and key sizes.
• Ignoring long-lived devices and long-retention data.
• Rolling out new algorithms without testing performance.
• Using unvetted or experimental algorithms.
• Treating it as a one-off project.

A first-year plan

1. Months 1 to 3: appoint owners, brief leaders and start the inventory.
2. Months 4 to 6: complete the inventory for critical systems, rank risks and send questions to suppliers.
3. Months 7 to 9: run pilots with hybrid key exchange and test signature options.
4. Months 10 to 12: publish a roadmap with milestones, update procurement requirements and begin the first migrations.

How SoftSapien supports cryptographic readiness

SoftSapien helps organisations inventory cryptography, assess risk, design crypto-agile architectures, run pilots and plan migrations, working with your security and legal teams. See our cybersecurity consulting and enterprise software engineering services.

To plan your roadmap, use the contact page to chat with our team, send a message or schedule a free consultation call.