Post-Quantum Cryptography: What Enterprises Should Be Doing Now
Quantum computers cannot break RSA today, but data stolen today can be decrypted later. Crypto inventory and agility are this year's work.
Post-quantum cryptography suffers from a credibility problem: the threat is real, the timeline is uncertain, and that combination makes it easy to defer indefinitely. The argument that ends the deferral is not about quantum hardware at all — it is about data retention.
Harvest now, decrypt later
An adversary does not need a quantum computer today to benefit from one tomorrow. Capturing encrypted traffic now and storing it until decryption becomes feasible is inexpensive and already assumed to be happening at nation-state scale.
The practical test is simple: how long does your data need to stay confidential? Health records, legal files, government communications, intellectual property, and long-lived credentials often need 15 to 30 years of protection. If the confidentiality lifetime exceeds the expected arrival of capable quantum hardware plus your migration duration, the exposure exists now, not later.
What changes and what does not
| Cryptography | Quantum impact | Action |
|---|---|---|
| RSA, ECDSA, Diffie-Hellman | Broken by Shor's algorithm | Replace with standardised PQC algorithms |
| AES-128 | Weakened by Grover's algorithm | Move to AES-256 |
| SHA-256 | Marginally weakened | Acceptable; prefer SHA-384 for long-lived signatures |
Symmetric cryptography survives with larger keys. Public key cryptography — which underpins TLS, code signing, VPNs, and most authentication — does not, and that is the migration.
Step one: cryptographic inventory
You cannot migrate what you cannot find, and cryptography hides in more places than an architecture diagram suggests. Catalogue TLS configurations across all external and internal endpoints; certificate inventory with issuers and lifetimes; code signing and firmware signing keys; VPN and tunnel configurations; database and storage encryption; message and payload signing in APIs; hardcoded algorithms inside application code; and cryptography embedded in vendor products and appliances.
For each entry record the algorithm, key size, data confidentiality lifetime, owner, and whether the algorithm is configurable or compiled in. That last field separates a configuration change from a vendor dependency.
Step two: prioritise by exposure window
- Highest priority: long-lived confidential data in transit or at rest, and any system whose data retention exceeds a decade.
- High: root and intermediate signing keys, because certificate hierarchies take years to rotate.
- Medium: external TLS endpoints, which benefit from hybrid key exchange available today in mainstream browsers and libraries.
- Lower: short-lived session data with confidentiality value measured in days.
Step three: adopt hybrid key exchange now
Hybrid schemes combine a classical algorithm with a post-quantum one so the connection is secure if either holds. Support is already shipping in major browsers, TLS libraries, and CDNs, which makes this the lowest-friction meaningful step available. Enable it at the edge for external traffic, verify handshake compatibility with older clients, and monitor for the modest payload and latency increase that larger keys introduce.
Step four: build crypto agility
The specific algorithms will change again; the ability to change them is the durable asset. Practically, that means: no hardcoded algorithm identifiers in application code; cryptographic choices expressed as configuration or policy in one place; short certificate lifetimes with automated issuance and rotation; and a contractual requirement that vendors publish a PQC roadmap with configurable algorithm support.
Teams that already rotate certificates automatically will find PQC migration a matter of months. Teams with manual, decade-old certificate processes will find it a matter of years — the gap is operational maturity, not cryptographic knowledge.
A realistic timeline
This year: complete the inventory, enable hybrid TLS at the edge, and add PQC requirements to procurement. Next: migrate the highest-exposure data paths, shorten certificate lifetimes, and remove hardcoded cryptography from internally owned applications. Following: signing infrastructure and code signing, then embedded and appliance estates, which depend on vendor timelines you do not control and therefore need the longest runway.
Frequently asked questions
What is post-quantum cryptography?
Encryption and signature algorithms designed to resist attack by large-scale quantum computers, including lattice-based schemes such as ML-KEM for key establishment and ML-DSA for signatures.
Why migrate before quantum computers arrive?
Because captured traffic can be decrypted later. Any data whose confidentiality lifetime exceeds the migration window plus the hardware timeline is already exposed.
What should we do first?
Build the cryptographic inventory, including hardcoded and vendor-embedded cryptography. Everything else depends on it.
Does this affect symmetric encryption?
Only mildly. Moving from AES-128 to AES-256 addresses the practical concern; the urgent work is public key cryptography.