The purpose of post-quantum cryptography is to keep encrypted data and digital signatures secure against quantum computers that do not yet exist but are expected to, and its urgency comes from a simple mismatch: much data must stay secret for longer than the time until such a machine may arrive, and encrypted traffic can be recorded today and decrypted then. The solutions are already deployed as software, chiefly hybrid post-quantum key exchange in browsers, messengers, SSH and cloud services, built on standardised algorithms such as ML-KEM. Being quantum ready means having those algorithms in place for key exchange now and a path to post-quantum signatures before a machine exists.
The previous guides on this site explain the threat, the terminology and the algorithms. This one addresses the why and the what-now: who actually needs post-quantum cryptography and on what timeline, the solutions and software that exist, what a quantum readiness plan looks like for an organisation and for an individual, and how to read post-quantum news without being misled in either direction.
The purpose in one paragraph
Cryptography protects two things: confidentiality, through encryption, and trust, through signatures. A cryptographically relevant quantum computer would break the public-key algorithms that currently deliver both, as the quantum computers guide on this site explains. Post-quantum cryptography's purpose is to replace those algorithms before the break matters. For confidentiality, that moment is now, because an adversary who records encrypted traffic today can decrypt it when the machine exists, so any data that must remain secret beyond that date is already exposed if it travels under classical key exchange. For trust, the moment is when the machine exists, because a forged signature only matters at the time it is checked, so certificates, software updates and authentication have longer but must be migrated before that point.
Who needs it and when
Governments and critical infrastructure hold secrets with decades-long sensitivity and operate systems with long replacement cycles. They are under mandated migration timelines, typically aiming to complete key exchange migration in the early 2030s and signatures shortly after.
Companies hold customer data, intellectual property, financial records and legal material whose exposure years from now would still cause harm, and they face regulatory expectations to protect it. Any company whose data has a shelf life of more than a few years has an interest in post-quantum key exchange today.
Journalists, lawyers, medical providers, activists and researchers handle communications whose disclosure could endanger people long after the fact. Their protection depends on the tools they use having migrated, which is why the deployments in Signal and iMessage matter.
Individuals benefit mainly through the infrastructure. Your browser's connections, your messages and your SSH sessions are being protected on your behalf. The personal action items are small and listed below.
Device and software makers must migrate signing infrastructure so that firmware and updates remain trustworthy after a quantum computer exists, a task with a long lead time because devices in the field must be able to verify new signature schemes.
Solutions available today
Post-quantum cryptography is not a future product; it is running now.
- Web. Major browsers negotiate hybrid X25519 plus ML-KEM key exchange by default, and large content delivery networks, cloud providers and many popular sites support it. Site operators enable it by updating their TLS termination software or using a provider that has.
- Messaging. Signal's protocol includes post-quantum key agreement in its initial handshake and ongoing ratchet, and iMessage's protocol includes post-quantum key establishment with periodic rekeying. Other messengers are following; the messaging guides on this site describe the field.
- Remote access. OpenSSH ships a hybrid post-quantum key exchange and uses it by default in recent versions.
- VPNs. Several commercial and open-source VPNs offer post-quantum key exchange, and WireGuard deployments can add a post-quantum pre-shared key layer.
- Cloud and key management. Major cloud providers support post-quantum TLS to their endpoints and offer ML-KEM and ML-DSA in their key management and certificate services.
- Hardware. Some hardware security modules and smart cards have added post-quantum algorithms; FIDO and hardware key post-quantum extensions are under development, as the passkeys guide on this site notes.
Software and libraries for developers
Developers rarely need to implement post-quantum algorithms, and should not. The right approach is to use a library or platform that has, and to design so algorithms can be swapped.
- liboqs from the Open Quantum Safe project provides implementations of the standardised algorithms with bindings for C, Python, Go, Java, Rust and others, plus providers for OpenSSL.
- OpenSSL includes ML-KEM, ML-DSA and SLH-DSA natively from version 3.5, and enables hybrid TLS key exchange.
- BoringSSL and Go's crypto library include ML-KEM and hybrid TLS groups.
- Bouncy Castle for Java and C# includes the standardised algorithms.
- Platform frameworks from Apple, Microsoft and Google expose post-quantum primitives and use them in system TLS.
- Rust and other ecosystems have audited crates and packages implementing ML-KEM and ML-DSA.
The design principle is cryptographic agility: isolate algorithm choices behind interfaces, avoid hard-coding key and signature sizes, and test with larger keys now so that switching is a configuration change. Protocols with fixed small fields, legacy hardware and embedded devices are where agility is hardest and where planning should start earliest.
A quantum readiness plan for organisations
- Inventory. Find every use of public-key cryptography: TLS endpoints, VPNs, SSH, code signing, certificates, PKI, encrypted storage, tokens, hardware. Automated discovery tools exist; the inventory is the foundation of everything else.
- Classify by data lifetime. Identify which encrypted data must remain secret beyond the next decade. That data's key exchange is the first priority.
- Enable hybrid key exchange wherever software already supports it: update TLS libraries and terminators, SSH, VPN configurations. Much of this is version upgrades.
- Engage vendors. Ask every supplier of cryptographic products for their post-quantum roadmap and require standardised algorithms, not proprietary ones.
- Plan the signature migration. Certificates, code signing and authentication infrastructure move on a longer timeline; begin testing post-quantum certificates and larger signatures in non-production environments.
- Build agility. Refactor systems so that algorithm changes are configuration, and test the change path.
- Re-encrypt long-lived data that was protected by classical public-key encryption, under symmetric keys or post-quantum mechanisms.
- Track standards and deadlines from the relevant national bodies for your sector.
A quantum readiness plan for individuals
- Keep browsers, operating systems, messengers and SSH clients updated; post-quantum key exchange arrives that way.
- Use AES-256 for files and disks that must stay confidential for decades, as the file encryption guides on this site describe.
- Prefer messengers and services that have deployed post-quantum key agreement.
- Re-encrypt old archives protected with PGP public keys under a symmetric passphrase if their contents are long-lived.
- Ask your VPN provider about post-quantum support when choosing.
- Ignore consumer products that sell quantum protection without naming a standardised algorithm.
Reading post-quantum cryptography news
Post-quantum news arrives in three flavours, and each needs a different reading.
Hardware milestones, such as a new qubit count or an error-correction result, are progress toward a machine but are routinely far from the millions of error-corrected qubits needed to break RSA. Headlines saying a quantum computer broke encryption have so far referred to factoring tiny numbers or to hybrid experiments with classical assistance, not to practical attacks.
Algorithm results, such as a candidate scheme being broken, are important and normal: several candidates fell during the standardisation competition, which is why the process was public and why hybrid deployment is recommended. A break of a standardised algorithm would be major news; a break of an unselected candidate is the system working.
Deployment announcements from browsers, messengers, cloud providers and standards bodies are the most useful signal for practical purposes, because they tell you what protection you have and what to expect from vendors.
Primary sources, the standards bodies, the IETF, vendor engineering blogs and cryptographers' own publications, are more reliable than secondary coverage, which tends to oscillate between alarm and dismissal.
A five-point summary
- PQC exists to protect long-lived secrets now and trustworthy authentication later.
- Governments, companies and anyone with data that must stay secret for years need it today; individuals get it through updates.
- Solutions are deployed in browsers, messengers, SSH, VPNs and cloud services.
- Developers should use libraries and platforms and design for agility, not implement algorithms.
- Read news from primary sources; hardware milestones are not breaks, and candidate breaks are not standard breaks.
What standards bodies, agencies and vendors say
The account above follows published guidance and announcements.
National standards and security agencies describe the purpose of post-quantum cryptography as protecting against the future decryption of recorded data and the future forgery of signatures, recommend beginning migration immediately with key exchange, and publish timelines targeting the early to mid 2030s for completion.
Browser vendors, Signal, Apple, the OpenSSH project and major cloud providers have documented production deployment of hybrid post-quantum key exchange, and cryptographic library maintainers have documented inclusion of the standardised algorithms.
Cryptographers and migration practitioners emphasise cryptographic inventory and agility as the foundation of readiness, recommend hybrid deployment while the new algorithms accumulate scrutiny, and advise that signatures and public key infrastructure represent the longer and harder half of the transition.
The point is the gap, and the gap is closing from both sides
Post-quantum cryptography matters because secrets outlive the machines that protect them, and because the machine that breaks today's protection is being built in the open, one milestone at a time. The answer is not exotic; it is a set of standardised algorithms that are already in your browser and your messenger, a checklist for organisations to work through, and the discipline to keep software current. The rest of the encryption guides on this site cover the layers that never needed to change.
Frequently asked questions
What is the purpose of post-quantum cryptography?
To keep encrypted data and digital signatures secure against future quantum computers. Its immediate purpose is to protect data encrypted today from being decrypted later, since traffic can be recorded and stored. Its longer-term purpose is to preserve trustworthy authentication, software updates and certificates once a quantum computer capable of forging classical signatures exists.
What post-quantum cryptography solutions exist today?
Hybrid post-quantum key exchange in TLS, deployed by major browsers, content networks and cloud providers; post-quantum key agreement in Signal and iMessage; hybrid key exchange in OpenSSH; post-quantum options in several VPNs; and ML-KEM and ML-DSA implementations in major cryptographic libraries, operating system frameworks and cloud key management services.
What post-quantum cryptography software can developers use?
Open-source libraries including liboqs and its language bindings, the post-quantum modules in OpenSSL 3.5 and later, BoringSSL, Go's standard library, Bouncy Castle, and platform frameworks from Apple, Microsoft and Google. Most developers should rely on their TLS library and platform rather than implementing algorithms directly.
What does quantum ready encryption mean?
That a system has inventoried where it uses public-key cryptography, can swap algorithms without redesign, and has deployed or can deploy post-quantum key exchange and signatures. For a product, it should mean standardised algorithms such as ML-KEM are in use or available, ideally in hybrid mode, not merely that the vendor plans to address quantum someday.
Where can I follow post-quantum cryptography news?
Standards bodies publish algorithm standards and migration guidance; browser vendors, Signal, Apple and the OpenSSH project publish deployment announcements; the IETF documents protocol integration; and cryptographers publish analyses and occasional breaks of candidate schemes. Prefer these primary sources over headlines announcing that encryption has been broken, which have so far referred to laboratory results far from practical attacks.
Last reviewed and updated on . Plain text version: /encryption/why-post-quantum-cryptography-matters.txt.
