Post-quantum cryptography is not a request to buy a quantum computer or replace every cipher tomorrow. It is a long infrastructure migration away from public-key algorithms that a sufficiently capable future quantum computer could break.
NIST finalized its first three principal post-quantum standards in August 2024 and says organizations should begin applying them now. Its transition direction targets deprecation and eventual removal of quantum-vulnerable algorithms from NIST standards by 2035, with high-risk systems moving earlier.[1]
The immediate work is inventory, ownership, vendor coordination, testing, and crypto agility.
What quantum computing threatens
Modern systems use different kinds of cryptography:
- symmetric encryption protects bulk data;
- hash functions support integrity and password storage;
- public-key cryptography establishes keys and creates digital signatures.
A cryptographically relevant quantum computer would especially threaten widely deployed public-key systems based on factoring and discrete logarithms, including RSA and elliptic-curve cryptography. Those algorithms underpin TLS, VPNs, certificates, code signing, secure email, device identity, and software updates.
Post-quantum algorithms are designed to run on ordinary computers while resisting known classical and quantum attacks.
The first NIST standards
NIST’s foundation consists of:
- FIPS 203 / ML-KEM: a key-encapsulation mechanism for establishing shared key material;
- FIPS 204 / ML-DSA: the primary module-lattice digital-signature standard;
- FIPS 205 / SLH-DSA: a stateless hash-based signature standard using a different mathematical foundation.[1:1][2]
Key establishment and signatures solve different problems. You do not replace “RSA” with one universal algorithm everywhere. A TLS connection, firmware-signing process, certificate hierarchy, hardware device, and document-signing workflow may require different transition designs.
Why begin before a large quantum computer exists
Harvest now, decrypt later
An adversary can collect encrypted traffic or data today and retain it until future capability makes decryption possible. Information that must remain confidential for many years—state secrets, health data, intellectual property, long-lived credentials—creates an earlier deadline.
Infrastructure moves slowly
Cryptography is embedded in hardware, protocols, libraries, vendor products, certificate systems, and operational procedures. Some industrial or embedded devices remain deployed for decades. A migration that looks like a library upgrade on a diagram can become a procurement and compatibility program.
Signatures protect long-lived trust
Signed firmware, software packages, documents, and certificates may need verification long after creation. Teams need to understand both when signatures are produced and how long verifiers rely on them.
Step 1: Build a cryptographic inventory
You cannot migrate what you cannot find. Inventory:
- algorithms, modes, parameters, and key sizes;
- protocols and library versions;
- certificates, certificate authorities, and expiration;
- key-management and hardware security modules;
- code-signing and artifact-verification systems;
- VPN, SSH, TLS, email, database, and backup encryption;
- embedded devices and third-party services;
- data confidentiality lifetime;
- owner, vendor, and replacement constraints.
A useful record looks like:
| System | Use | Current crypto | Data lifetime | Dependency owner | PQC support | Priority |
|---|---|---|---|---|---|---|
| Public API | TLS key establishment | ECDHE | 7 years | platform | pilot | high |
| Firmware pipeline | release signing | ECDSA | 15 years | product | roadmap unknown | critical |
| Internal dashboard | TLS | RSA certificate | 30 days | IT | vendor planned | lower |
Automated discovery helps, but architecture interviews and procurement records reveal offline signing systems, hardware roots, and vendor-managed components scanners cannot see.
Step 2: Prioritize by risk and lead time
Priority should combine:
- required confidentiality or signature lifetime;
- exposure to collection;
- system criticality;
- replacement lead time;
- hardware constraints;
- vendor readiness;
- dependency depth;
- consequences of interoperability failure.
A low-sensitivity internal service on replaceable software may wait. A product with a 20-year service life and immutable trust anchor may require design changes now.
Step 3: Ask vendors precise questions
“Are you quantum safe?” is too vague. Ask:
- Which NIST-standard algorithms and parameter sets are supported?
- In which released versions?
- Is support experimental, optional, default, or validated?
- Does it cover key establishment, signatures, certificates, and management APIs?
- Are hybrid modes supported, and how are they negotiated?
- What are the key, signature, packet, memory, and performance effects?
- How can administrators inventory and rotate the configuration?
- What is the fallback behavior when a peer lacks support?
Record answers as product-roadmap evidence, not permanent guarantees.
Step 4: Pilot where failure is recoverable
Post-quantum algorithms have different sizes and performance characteristics. Test:
- handshake size and network fragmentation;
- latency and server load;
- constrained-device memory and storage;
- certificate and message-size assumptions;
- load balancers, proxies, inspection devices, and logging;
- backup, restore, rotation, and rollback;
- interoperability across client generations.
Begin with a representative non-critical path. A successful algorithm benchmark does not prove the surrounding protocol and operations are ready.
Step 5: Build crypto agility
Crypto agility means an organization can locate and replace cryptography without redesigning every application under emergency pressure.
Useful practices include:
- remove hard-coded algorithm choices;
- centralize policy and supported suites;
- expose configuration and telemetry;
- separate application logic from crypto implementation;
- automate certificate and key rotation;
- test algorithm changes and downgrade behavior;
- maintain rollback without silently returning to insecure defaults.
Agility is not unlimited runtime choice. Too many legacy options can expand attack surface. It is controlled replaceability.
Hybrid deployment is a transition tool
A hybrid key-establishment design combines classical and post-quantum components so the result remains protected if at least one component remains secure, assuming sound composition. It can reduce transition uncertainty, but increases complexity, message size, and implementation risk.
Follow protocol and vendor standards rather than inventing a combination. NIST’s PQC FAQ discusses approved composite key-establishment approaches and evolving guidance.[3]
Common mistakes
Waiting for the final possible date
2035 is not a universal project start. High-risk systems and long-lived data need earlier milestones.
Rebranding ordinary encryption
“AES-256 is quantum safe” does not solve RSA certificates or ECDH key establishment. Inventory each cryptographic function.
Deploying unreviewed algorithms independently
Use standardized algorithms through maintained implementations and supported protocols. Cryptographic engineering is unusually unforgiving.
Ignoring rollback and downgrade
A new mode that automatically falls back to an old vulnerable mode may provide less protection than expected. Test and monitor negotiation.
Treating this as a security-team-only project
Asset owners, enterprise architecture, platform teams, PKI, procurement, legal, product engineering, and vendors all control parts of the migration.
A 90-day readiness plan
Days 1–30
- Assign an accountable owner and cross-functional working group.
- Define inventory fields and priority criteria.
- Identify the most sensitive long-lived data and products.
- Add PQC questions to vendor reviews.
Days 31–60
- Run discovery and architecture interviews.
- Map certificate, signing, VPN, TLS, SSH, and device dependencies.
- Identify systems with long replacement cycles.
- Select one recoverable pilot.
Days 61–90
- Test a supported standards-based implementation.
- Document performance and interoperability gaps.
- Build a phased roadmap with owners and dates.
- Add cryptographic visibility and agility requirements to new designs.
This will not complete migration. It turns an abstract future risk into an owned engineering program.
Sources
National Institute of Standards and Technology, Post-Quantum Cryptography project and migration timeline. ↩︎ ↩︎
NIST, NIST Releases First 3 Finalized Post-Quantum Encryption Standards. ↩︎
NIST, Post-Quantum Cryptography FAQs. ↩︎