The Best Thing About the PQC Panic is Crypto-Agility

Reflections after a Post-Quantum Security Summit, from someone who spent years in quantum research, then considerably more years watching ordinary software fail in considerably more ordinary ways.

From roughly 2003 to 2013, I worked in quantum computing and quantum cryptography, including at Singapore's Centre for Quantum Technologies. Then I wandered away from research and into the less elegant world of software engineering, infrastructure, cybersecurity and eventually product management.

Somewhere along the way, my hacker team Qb1t also won a Capture-the-Flag competition at Hack in the Box.

Those three backgrounds have left me with three rather different instincts.

The quantum researcher asks:

Can this cryptographic primitive be broken?

The hacker asks:

If I wanted the data, is this really how I would get it?

And the product manager asks:

Of all the things I could spend money fixing, is this the one with the highest marginal return?

I was reminded of the tension between those questions at today's Post-Quantum Security Summit in Singapore.

I should probably be one of the easiest people in the room to scare with quantum computers. I understand Shor's algorithm. I do not need a cartoon of a padlock dissolving into qubits to convince me that RSA and elliptic-curve cryptography have a problem if sufficiently capable fault-tolerant quantum computers arrive.

The mathematics is real.

What surprised me was how quickly a mathematically correct statement could mutate into a commercial conclusion.

The summit's own website calls 2025–2030 a "Closing 5-Year Window" and describes an "urgent transition to quantum-era security," although, to its credit, it also says organisations should determine what must be done now and what can be deferred.

That latter distinction is the important one.

Because:

"Quantum computers can break RSA" is a statement about cryptography. "Your company should spend serious money on PQC now****" is a statement about risk allocation.

The first does not mathematically imply the second.

Most people in that room were not being cynical about it. They had read the same headlines I had, and the headlines really do compress "cryptography has a problem" into "you have a problem" without showing their work. But some parts of the industry have every incentive not to correct that compression, and every reason to let a real mathematical result do the selling for a much less certain business case.

I am increasingly worried that we are letting them.

Unfortunately for my argument, Shor's algorithm is real

Let us get the easy part out of the way.

An RSA modulus is constructed as

for large primes (p) and (q).

The security of RSA depends on the practical difficulty of recovering the factorisation of (N). The best known general-purpose classical factoring algorithm is the General Number Field Sieve, with heuristic asymptotic complexity approximately

or, expanded,

That is sub-exponential, but still unpleasant enough that RSA-2048 is not something you casually factor with the spare GPU under your gaming desk.

Shor changes the nature of the problem.

On a sufficiently capable quantum computer, integer factorisation can be performed in time polynomial in the bit length of (N):

The same broad problem exists for elliptic-curve cryptography: Shor also efficiently solves the discrete logarithm problems underlying ECC.

That is not hype.

It is one of the most important results in quantum computation.

The inconvenient detail is contained in the phrase:

on a sufficiently capable quantum computer

We have the algorithm.

We do not yet have the cryptographically relevant machine.

That distinction is sometimes treated as a mere engineering footnote. It is not. Fault tolerance, logical error rates, qubit counts, circuit depth, physical error correction and actual runtime all stand between a polynomial-time algorithm on paper and someone's ability to point a machine at RSA-2048.

None of that means we should wait until the machine arrives before preparing.

It does mean that the probability distribution matters.

Cryptographers and hackers optimise different functions

This is where leaving quantum research for ordinary software engineering changed how I think.

A cryptographer might define the security of a primitive roughly in terms of the computational cost of the best known attack:

But an attacker does not attack a primitive.

An attacker attacks a system.

And for a system, the interesting quantity is closer to:

The attacker is looking for the minimum.

That is an entirely different optimisation problem.

A useful toy model would be:

where (V) is the value of obtaining the target and (C(a)) is the cost of attack (a).

Hackers do not get style points.

Nobody awards a bonus flag because you used lattice reduction when somebody left an API token in GitHub.

Imagine attacking a medium-sized company and finding:

1. an AWS credential committed into source control;
2. an old VPN appliance three years behind on patches;
3. reusable passwords and incomplete MFA;
4. a service account with ridiculous privileges;
5. RSA-2048 protecting TLS traffic.

If you start with number 5, congratulations on your mathematics degree.

You have failed the CTF.

You can build the most beautiful cryptographic channel imaginable between two completely compromised endpoints:

Compromised laptop
       │
       │ ML-KEM + AES-256
       │ cryptographically magnificent
       ▼
Compromised server

Compromised laptop
       │
       │ ML-KEM + AES-256
       │ cryptographically magnificent
       ▼
Compromised server

The packets are safe.

Everything else is on fire.

This is why I become uncomfortable when discussions of cryptographic strength quietly slide into discussions of cybersecurity strength.

They are related. They are not synonyms.

Q-Day is not a threat model

The phrase "Q-Day" is useful shorthand, but it encourages another conceptual mistake: treating quantum capability as if it arrives everywhere simultaneously.

From the standpoint of an RSA primitive, there can indeed be something close to a threshold.

Before an adversary possesses enough quantum resources, the Shor attack is infeasible.

Afterward, it is feasible.

But organisations are not attacked by abstract complexity classes. They are attacked by actual adversaries with budgets.

So the relevant variable is not merely

the probability that a cryptographically relevant quantum computer exists somewhere at time (t).

It is

the probability that an adversary who cares about me has access to one.

Those are not remotely the same quantity.

If the first machines capable of useful quantum cryptanalysis are extremely expensive to build and operate — which seems considerably more plausible than script kiddies getting them as a free tier on AWS Quantum — access will initially be concentrated.

Perhaps: state intelligence → strategic institutions → specialist commercial access → broader enterprise → criminal commodity.

That diffusion could take years.

So the NSA's Q-Day and a ransomware gang's Q-Day may be very different dates.

And the first cryptanalytically useful quantum computer is probably not going to spend Tuesday afternoon decrypting the TLS traffic of a 60-person air-conditioning contractor in Jurong.

Compute has opportunity cost too.

A state actor with scarce quantum capacity would presumably have a queue.

Nuclear command systems probably appear somewhere above restaurant reservations.

This sounds obvious when stated that way.

It is surprisingly easy to forget once the phrase "your encryption will be broken" appears on a conference slide.

Harvest now, decrypt later — now with an actual equation

The strongest argument for migrating before quantum computers exist is harvest-now-decrypt-later, or HNDL.

The idea is legitimate.

An adversary records encrypted traffic today:

They cannot decrypt it today.

They preserve it until (t₁), when the required cryptanalytic capability exists:

This is precisely why long-lived secrets deserve early attention.

One useful way of thinking about migration is Mosca's inequality. Let

• (x) = how long the information must remain secret;
• (y) = how long migration will take;
• (z) = how long until the relevant quantum capability arrives.

If

you already have a problem.

I like this model.

My objection is not to the inequality. My objection is to acting as though we know all three numbers.

We can often estimate (y), at least badly. We can sometimes estimate (x).

But (z) is a technology forecast wearing mathematical clothing. And (x) is not one number for an organisation.

It is a function:

where (d) is the data class.

A military order saying

bomb site A tomorrow

may be extraordinarily sensitive tonight and nearly worthless fifteen years from now.

A genomic record may remain sensitive for the lifetime of the person. A merger negotiation has another half-life.

So does a tender bid. So does a session cookie. So does semiconductor process IP.

One simple model is to give the information a value that decays with time:

For short-lived operational intelligence, (𝜆ₙ) is large.

For something such as genomic information, (𝜆ₙ) may be close to zero over decades.

This gives us a more meaningful version of quantum risk:

where (Hₙ) means the relevant ciphertext was harvested and (Bₙ) means the adversary can successfully break it.

I am not proposing that CISOs start numerically integrating this equation in Excel.

The point of the equation is to expose the assumptions hidden inside the sentence:

"Your encrypted data is at risk today."

Which data? Harvested by whom? Valuable until when? Broken by which adversary? At what cost?

Those questions are not pedantry.

They are the threat model.

One detail sharpens all five of them at once, and simplified HNDL narratives tend to lose it. Modern TLS generally uses ephemeral key exchange, which is excellent against ordinary retrospective key compromise: stealing one long-term server private key does not simply unlock every historical session. A sufficiently capable quantum attacker could still attack recorded elliptic-curve ephemeral key exchanges using Shor — but now there may be per-session cryptanalytic work involved. That changes the economics. "Record the Internet now, decrypt the Internet later" is a much more dramatic sentence than "record enormous volumes of traffic now, then later decide which historical sessions justify scarce quantum computation." HNDL remains real. But economics has entered the chat, and it entered through the same door as (Hₙ) and (Vₙ(t)) above.

HNDL cuts both ways

And now we arrive at something I think deserves much more discussion.

Suppose I encrypt traffic with RSA/ECDH today. An attacker records it. Fifteen years later, Shor becomes practical. My historical traffic may be lost. That is the HNDL argument.

Fine.

Now suppose I migrate today to ML-KEM. An attacker records that ciphertext too. Ten years later, someone discovers an unexpectedly powerful classical attack against the underlying problem.

What happens?

Exactly the same unpleasant thing.

And unlike software inside my organisation, I cannot upgrade ciphertext already sitting inside somebody else's archive.

Crypto-agility gives me:

It does not give me:

Or more compactly,

You cannot patch the adversary's hard disk.

This is one reason hybrid key establishment makes sense during a transition.

A properly constructed combiner can derive something like

so that failure of one assumption alone does not necessarily destroy confidentiality.

That is not merely transition bureaucracy.

It is assumption diversification.

But even hybrid cryptography is not metaphysical immortality.

If assumption (A) is broken at (t₁), and assumption (B) is broken at (t₂), a sufficiently informative historical transcript may eventually become vulnerable.

The deeper lesson of HNDL is therefore not:

PQC will protect historical secrets forever.

It is:

When confidentiality must survive for decades, you are making a bet about what mathematics humanity will know decades from now.

That should induce humility, not certificates with green ticks saying QUANTUM SAFE.

Which is a good moment to admit that this humility cuts in a direction I have not yet defended: it applies to ML-KEM itself, not only to the RSA it replaces.

PQC does not abolish cryptographic assumptions

This is where the phrase "quantum-safe" makes me nervous.

ML-KEM, formerly known as Kyber, is based on Module Learning With Errors.

It is a serious construction, heavily scrutinised, standardised after a substantial public process, and there is currently no known practical attack that invalidates its security.

Good.

But its security is still not: PROVEN UNBREAKABLE.

It is closer to:

That is how practical cryptography works.

RSA is not protected by a theorem saying:

We do not know that.

For all mathematics currently proves, there could be a polynomial-time classical factoring algorithm that nobody has discovered.

Perhaps some reclusive Russian mathematician has one running in his mother's basement.

I do not assign that scenario the same probability as a future quantum computer running Shor.

They are epistemically different.

For quantum factoring, we have

For a hypothetical classical factoring breakthrough, we have

The first has much stronger positive evidence.

But neither is a theorem predicting the future.

And precisely the same humility should apply to PQC.

We cannot prove that no future mathematical insight will substantially reduce the complexity of attacking Module-LWE.

We cannot prove that today's parameters will survive every algorithmic development for the next forty years.

That is not an accusation against ML-KEM.

It is simply how computational cryptography works.

Asymptotic complexity is not quite the point either

Suppose somebody discovers a better lattice attack tomorrow.

The interesting question is not merely whether its asymptotic complexity improved.

Suppose a work factor changes from

Mathematically exciting.

Operationally, probably still unpleasant enough.

But if some structural insight changes an effective attack cost from

we are suddenly having a very different conference.

What matters is when

That is where cryptanalysis becomes economics.

And here is the part I find particularly interesting.

A breakthrough in quantum cryptanalysis still requires quantum hardware.

A breakthrough in classical cryptanalysis can propagate through software.

Potentially: paper → reference implementation → Github → cloud compute → crimeware.

Software copies remarkably cheaply.

We have already seen PQC candidates die spectacularly under new cryptanalysis. SIKE is perhaps the most famous example: a serious post-quantum candidate based on supersingular isogenies was demolished by a classical attack.

That does not tell us that ML-KEM is fragile.

It tells us that cryptanalytic surprise is not a hypothetical category invented to win an argument.

The denominator they still don't sell you

I wrote previously about a fire-resistant pouch I almost bought for my power bank.

The pouch probably worked. Lithium-ion thermal runaway is real. Fire-resistant material is real.

The flaw in my reasoning was elsewhere: the pouch would mostly contain the power bank while it was idle, precisely when thermal runaway risk was lowest. I had tested the mechanism before asking whether it addressed the dominant part of my risk.

I later described that category as:

real hazard, real mechanism, potentially trivial reduction in actual risk.

PQC can fall into the same analytical trap.

Not because the cryptography is fake.

That would be easy.

The more interesting case is when every technical sentence is true:

• Shor breaks RSA and ECC on an adequate quantum computer.
• HNDL is possible.
• ML-KEM resists known quantum attacks.
• migration takes years.
• cryptographic inventories are messy.
• old systems are difficult to update.

All true.

Then our brain quietly adds the sentence nobody actually demonstrated:

Therefore PQC is one of the highest-priority cybersecurity investments for my organisation today.

That is where I want the denominator.

Security has a budget constraint

An SME does not possess an infinite pool of cybersecurity engineers.

Let the total security budget be

subject to

For each control (j), let

be the reduction in expected loss.

Then a rational allocation problem is something like

under the budget constraint.

Or, much more crudely, ask:

How much risk reduction am I buying per dollar, per engineer-month, and per unit of additional architectural complexity?

For an organisation with poor MFA coverage, secrets in source repositories, ancient internet-facing appliances, excessive privileges and backups that nobody has tested since the previous CTO left, I strongly suspect that at the current operating point:

If your production API keys are sitting in GitHub, I am not claiming PQC has zero value.

I am saying calculus exists.

There are absolutely organisations for which that derivative looks different.

Intelligence agencies. Defence systems. Diplomatic networks. Critical infrastructure. Strategic industrial research. Certificate authorities.

Perhaps major financial institutions with complex PKI estates, long-lived information and regulatory obligations.

Systems being designed today that must remain deployed for twenty years without practical hardware replacement.

For those organisations, starting early is perfectly rational.

But CIA, NSA, UBS, and the neighbourhood accounting firm do not share one threat model merely because they all use TLS.

The part of the programme I'd actually defend: crypto-agility

Everything above might make it sound as though I left the summit thinking the whole PQC programme is misplaced.

I didn't.

In fact, one idea came out stronger for me: crypto-agility.

The summit itself gives significant attention to crypto inventory, agility architecture, migration and vendor assessment, which I think is the most defensible part of the whole programme.

Most organisations have accumulated cryptography like geological sediment.

Some certificate was introduced twelve years ago.

Some Java service explicitly requests an obsolete cipher suite.

A vendor appliance contains an embedded certificate nobody remembers.

Firmware signing assumes a particular algorithm.

An HSM supports something different from what the new application expects.

A protocol has key sizes baked into packet structures.

A partner integration will break if certificate size triples.

Then one day somebody says:

"We need to replace algorithm X."

And everybody discovers that algorithm X has tentacles.

Real crypto-agility is not:

crypto_algorithm: RSA

crypto_algorithm: RSA

followed one day by:

crypto_algorithm: ML-KEM

crypto_algorithm: ML-KEM

and a triumphant Jira ticket marked Done.

It means knowing:

• where cryptographic primitives are used;
• which keys and certificates depend on them;
• which protocols negotiate them;
• which hardware constrains them;
• which external partners assume them;
• which data needs which confidentiality lifetime;
• how to migrate safely;
• how to prevent downgrade attacks;
• how to roll back;
• how to replace the next algorithm without another five-year archaeology project.

This has value even if useful quantum computers arrive fifty years later than predicted.

Because quantum computing is not the only reason cryptography changes.

Algorithms are deprecated. Protocols fail. Implementations leak. Side channels appear. Standards move. Regulations move. Mathematics moves.

If we define possible future cryptographic states as

then crypto-agility has something resembling option value:

I do not need to predict which (ω) occurs.

That is precisely the point.

Uncertainty itself is the argument for agility.

This is a much stronger architectural proposition than:

"We know Q-Day is coming in year X."

We don't.

What today's summit changed my mind about

I arrived already believing that sufficiently capable quantum computers pose a real problem for RSA and ECC.

Nothing today changed that.

I also arrived believing that organisations with long-lived sensitive information should be preparing for PQC.

Nothing changed that either.

What the summit reinforced for me was something slightly different.

The quantum researcher in me asks:

Can the cryptography fail?

Yes.

The CTF player asks:

Would I attack here?

Often, no.

The product manager asks:

Of all the things that can fail, where should the next dollar and the next engineer-month go?

That answer depends on the organisation.

And this is where I think some of the commercial PQC conversation jumps a step.

A technically real threat does not automatically become a high-priority business risk.

A working countermeasure does not automatically become a rational purchase.

A scary numerator does not remove the need for a denominator.

My position after the summit is therefore neither:

Quantum apocalypse. Buy everything.

nor:

Quantum computers are hype. Ignore everything.

It is less exciting.

Inventory your cryptography.

Build crypto-agility.

Understand your data's confidentiality lifetime.

Know which adversaries you actually face.

Use hybrid approaches where the threat model warrants them.

Start PQC migration early where (x+y>z) is plausibly true.

And if you want an SME to move PQC above identity, secrets management, patching, application security, recovery and ordinary operational hygiene, show the calculation.

Because Q-Day is not a threat model.

And "quantum-safe" is not the same thing as "secure."