Post Quantum Cryptography is Not an Algorithm Upgrade

As organizations prepare for post quantum cryptography, I am seeing confusion in two areas.

The first is around the algorithms themselves. ML KEM, ML DSA, SLH DSA, FIPS 203, 204 and 205 are often discussed as if they are interchangeable.

The second is more important. Teams are starting to talk about migration before they understand what data, systems and business services depend on the cryptography they are trying to replace.

PQC is not simply an RSA replacement program, it’s a data security and technology dependency problem.

 

Start with the basics

FIPS 203 defines ML KEM, a post quantum key encapsulation mechanism. Its role is to establish shared secret material that can then be used with symmetric encryption such as AES.

It addresses a function currently performed in different architectures using mechanisms such as Diffie Hellman, elliptic curve Diffie Hellman and some RSA based key establishment, but it is not a direct replacement for every use of RSA or ECDH.

FIPS 204 defines ML DSA, a post quantum digital signature algorithm. This addresses authenticity and integrity, where RSA signatures and ECDSA are commonly used today.

FIPS 205 defines SLH DSA, a hash based digital signature algorithm. Its different mathematical foundation also provides useful cryptographic diversity alongside lattice-based algorithms.

FIPS 202 is SHA 3 and is not another PQC migration algorithm.

A simple way to think about it:

• ML KEM establishes secret material.
• ML DSA and SLH DSA provide digital signatures.
• AES continues to protect bulk data.
• SHA 3 provides hashing functions.

Quantum computing does not affect every type of cryptography in the same way.

Shor’s algorithm threatens the mathematical foundations behind RSA, Diffie Hellman and elliptic curve cryptography, however symmetric cryptography such as AES is affected differently.

Grover’s algorithm reduces its security margin, but does not create the same type of break, which is why the immediate migration problem is concentrated around public key cryptography, key establishment and digital signatures.

 

Start with the data, not the algorithm

Finding RSA 2048 somewhere in the environment tells me very little about migration priority, instead we need to know what that cryptography protects.

A dataset that loses its confidentiality value in six months does not create the same risk as intellectual property, government information, financial records, or personal data that may need protection for another fifteen years.

This is where harvest now, decrypt later (HNDL) matters.

In InfoSec it is common knowledge that an attacker does not need a cryptographically relevant quantum computer today, as they can collect encrypted information today and retain it.

If that information still has value when the cryptography protecting it becomes vulnerable, the compromise has already begun from a risk perspective, and the uncertainty around when a sufficiently capable quantum computer will exist does not remove that problem.

If information must remain confidential for a long time, and migration itself will take years, waiting for certainty is not a useful strategy.

 

Confidentiality and trust are different risks

These should not be treated as the same threat, as harvest now, decrypt later is a present collection risk.

Signature forgery is different, as it becomes an operational attack once a sufficiently capable quantum computer exists, and affects software signing, firmware, device identity, certificates, machine identity, secure boot, PKI and hardware roots of trust.

In essence, the timing is different, but the engineering work cannot wait until the threat becomes active.

A certificate on a web service may be relatively easy to replace, but a root of trust embedded into hardware expected to operate for twenty years may not be and this is why system lifetime matters alongside data lifetime.

 

Discovery has to mean more than inventory

Most enterprises do not have a complete view of where cryptography is used.

It exists in applications, APIs, TLS libraries, certificates, HSMs, KMS platforms, databases, operating systems, network devices, cloud services, firmware, embedded systems, identity platforms and third-party software.

But simply finding the algorithm is not enough.

For each important cryptographic dependency, we need to understand:

• What business service depends on it?
• What data does that service process?
• What cryptographic function is being performed?
• Where are the keys?
• Which protocol and implementation are involved?
• Can we change it ourselves?
• Does a supplier need to change it first?
• Does the hardware need to change?
• What is the expected lifetime of the system?

This is not a clean linear chain, as the relationships are many to many.

One dataset may depend on dozens of applications and services, one cryptographic library may support hundreds of applications, and one HSM may support several business-critical systems.

Our goal should not be to create a perfect enterprise map before doing anything, instead we need to establish enough dependency context to make defensible migration decisions.

 

Prioritize where the risk is concentrated

Most organizations will not have the budget or staffing to investigate every cryptographic dependency at the same depth.

So where do we start? We should start where the exposure is highest, such as high value data with long confidentiality requirements, externally exposed cryptography such as:

• Long lived hardware and infrastructure.
• PKI and roots of trust.
• Business critical systems.
• Systems that are difficult to update.
• Cryptography controlled by third parties.
• Products approaching end of life.

These areas create either long exposure windows or long migration lead times.

 

Crypto agility is the real capability

Crypto agility is often reduced to supporting several algorithms, but is that enough?

A crypto agile environment should let us discover where cryptography is used, change it without rebuilding the entire system, and verify that the intended cryptography is actually operating.

Configured does not equal operating.

A product may support ML KEM without production traffic using it, an HSM may support ML DSA without the applications connected to it having migrated and a cloud service may support PQC TLS while sensitive application flows continue negotiating classical cryptography.

PQC readiness cannot rely only on declared capability, rather we need evidence of the cryptographic state in production.

• Which algorithms are actually negotiated?
• Which certificates are actually presented?
• Which signature algorithms are being used?
• Which cryptographic policy is being enforced?
• Where has the production environment drifted from the intended design?

Without that visibility, an organization can believe it has migrated when it has only enabled support.

 

Keep the migration process practical

The migration path does not need another complicated framework, but it does needs discipline.

Discover. Understand the risk. Prioritize. Engineer. Test. Migrate. Operate.

Discovery identifies cryptographic use and dependencies, and risk connects those dependencies to data sensitivity, system lifetime, exposure and business criticality.

Prioritization determines what moves first, engineering determines the target architecture and testing validates interoperability, performance, certificate and key sizes, HSM integration, protocol behavior and failure conditions.

• Migration introduces the change in controlled stages.
• Operations verifies what is actually running and detects drift.
• Crypto agility needs to support all of this.

 

Hybrid cryptography will be part of the transition

Classical and post quantum cryptography will coexist for some time.

That is already reflected in current standards work, including hybrid TLS 1.3 mechanisms combining ML KEM with classical elliptic curve key agreement.

Hybrid approaches can reduce transition risk, but they also introduce more implementation and operational complexity.

They should be treated as migration architectures, not as a substitute for crypto agility.

 

The supply chain matters

Enterprises do not control all of their cryptography.

Cloud providers, operating systems, network equipment, HSMs, databases, browsers, TLS libraries, SaaS providers, firmware and third-party software all introduce dependencies.

That means every migration program needs to ask:

Who controls this cryptographic dependency?

• Some changes can be made internally.
• Others depend entirely on supplier roadmaps.
• Some require hardware replacement.
• Some systems may reach end of life before a migration path is available.

PQC therefore needs to become part of procurement, supplier management and product lifecycle planning, not just security architecture.

 

What quantum readiness should mean

Algorithm support is not the same as quantum readiness.

If a library supports ML KEM, that does not mean the enterprise has migrated, if an HSM supports ML DSA, that does not mean the applications depending on it are ready and if a vendor says a product is PQC ready, that does not tell us what is actually being used in production.

As such, I would expect a quantum ready organization to be able to answer four questions:

• What information must remain protected?
• What cryptography protects it today?
• Can we change that cryptography before the risk becomes material?
• Can we prove what cryptography is actually operating?

If we cannot answer those questions, we do not yet have quantum readiness.

We have algorithm availability.

 

---

Primary references

• NIST FIPS 202, SHA 3 Standard
• NIST FIPS 203, ML KEM
• NIST FIPS 204, ML DSA
• NIST FIPS 205, SLH DSA
• NIST NCCoE, Migration to Post Quantum Cryptography
• NIST, Considerations for Achieving Crypto Agility
• NSA, Commercial National Security Algorithm Suite 2.0
• UK NCSC, Timelines for Migration to Post Quantum Cryptography
• European Commission, Coordinated Implementation Roadmap for the Transition to Post Quantum Cryptography
• Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks
• IETF RFC 10024, Hybrid Post Quantum Key Agreement for TLS 1.3