Crypto agility was never about quantum computers

Almost every conversation I have about the future of enterprise cryptography follows the same storyline. A quantum computer eventually arrives. RSA and elliptic-curve cryptography break. Organizations migrate to post-quantum algorithms. Problem solved.

The first three steps are correct. I've spent a good part of this year writing about them, and I stand by every word. Post-quantum migration is necessary, it's urgent, and regulators have already turned it into deadlines.

The fourth step is the dangerous one.

It assumes cryptographic change is a single event, with a known cause, a known destination and an end date. It assumes that the algorithms we choose in this migration will stay acceptable for as long as we need them. And that if they ever stop being acceptable, we'll get years of warning.

The last four years say otherwise.

Five warnings. Zero quantum computers.

Rainbow. A finalist in NIST's post-quantum signature competition. In February 2022, a single paper recovered its secret key for one parameter set in about 53 hours on a laptop. Years of public scrutiny, two rounds of selection, and then one weekend of computation. It was never standardized.

SIKE. NIST advanced it to the fourth round of its post-quantum process in July 2022. Less than a month later, researchers broke it with a classical attack in about ten minutes on a single core. The attack built on a mathematical result from 1997 that nobody had connected to the scheme.

HAWK. A lattice-based signature scheme that advanced to the third round of NIST's additional signatures process in May 2026. Eleven weeks later, an AI-assisted analysis disclosed by Anthropic's Frontier Red Team found a structural property that halved its effective key size. The authors withdrew the scheme the next day. The attack is still exponential and specific to HAWK. But it shows something new: the speed at which weaknesses are found is itself changing.

Classic McEliece. This one matters most, because it is not young. It comes from a 1978 design, one of the oldest public-key systems we have. Its long track record was precisely the argument for it. Germany's BSI had recommended it since 2020, and ISO standardized it in June 2026. Then, in a matter of months, a wave of structural cryptanalysis brought down cost estimates that had held for decades. In September 2026, BSI advised against using it in new developments. BSI was careful to say that no practical attack exists. Classic McEliece was not broken. It just stopped being acceptable for new use.

RSA. In September 2026, researchers carried out at real scale a signature forgery technique first described in 2007, using a real hardware security module as the target. It does not mean RSA has been factored, and it applies to a specific attack model. But it lowered the concrete security estimate of one of the most deployed algorithms in history by 15 to 30 bits in that model. A theory from 2007 became practice in 2026.

None of these required a quantum computer.

To be precise: three of these five were candidates, and catching weak candidates is exactly what a selection process is for. ML-KEM and ML-DSA, the finalized NIST standards, are not affected by any of these results. That's not the point.

The point is that the security assessment of cryptographic mechanisms moves. Sometimes abruptly. For reasons that include quantum computing but are not limited to it. And it can move for mature, standardized, recommended mechanisms just as it moves for new ones.

Algorithms don't suddenly change. Our knowledge about their security does.

This isn't my opinion

I want to be clear that this is not a vendor narrative. It's the stated position of the institutions that define cryptographic practice, and it predates the post-quantum wave by years.

NIST's crypto agility work says that advances in computing, cryptographic research and cryptanalysis periodically force the replacement of algorithms that no longer provide adequate security. The same work documents how slow those replacements have been: the full transition from Triple DES to AES took 23 years.

The IETF formalized it back in 2015 in RFC 7696: algorithms age and become weaker over time, the timing of those advances can't be known in advance, and the move away from an algorithm should happen before it reaches the breaking point.

In other words, the standards community has treated cryptographic obsolescence as something you manage before failure, not after it. For a decade.

Broken is not the threshold that matters

Security discussions tend to treat cryptography as binary. Secure or broken.

Enterprises don't live on that line. They live on acceptability. And acceptability can be withdrawn long before anything breaks.

NIST's own guideline for algorithm transitions, SP 800-131A, doesn't classify algorithms as secure or insecure. It assigns them a status: acceptable, deprecated, legacy use, disallowed. And the same algorithm can hold different statuses for different operations. Triple DES can no longer encrypt, but it can still decrypt. SHA-1 can't generate new signatures, but it can still verify old ones.

Look at the dates already on the calendar. NIST proposes deprecating quantum-vulnerable algorithms after 2030 and disallowing them after 2035. Those dates apply whether or not a quantum computer has been demonstrated by then. BSI's decision on Classic McEliece shows the same mechanism working in months instead of years, based on evidence that stops well short of a practical attack.

For an enterprise, cryptographic obsolescence comes before cryptographic failure.

So the question a CISO needs to ask changes. It's no longer "has this algorithm been broken?"

It's "is this mechanism still acceptable, for this use, under the standards and policies that apply to us?"

That second question has more possible answers, changes more often, and is decided by people outside your organization: standards bodies, national agencies, regulators, auditors, counterparties. An organization that can only react to the first question is structurally late.

The cryptographic response gap

If acceptability can change suddenly and for reasons you don't control, then what determines your risk is not only the change itself. It's how long you stay dependent on a mechanism after it stops being acceptable.

We call this the Cryptographic Response Gap. It runs from the moment the assessment, standard or status of a mechanism changes for a given use, to the moment your organization has finished remediating it: no new protection applied with it, and the data it protected handled according to policy.

The idea isn't new. Bruce Schneier described the "window of exposure" for software vulnerabilities in 2000. Mosca's inequality puts migration time at the center of post-quantum planning. The Response Gap applies the same logic to cryptographic mechanisms, where remediation means replacing a mechanism across every system that depends on it. That's why it's measured in months or years, not days.

The gap has several parts: detecting that something changed, finding where you use the mechanism, deciding what replaces it, engineering the change, deploying it, and exiting the old mechanism. Most organizations invest in the first two through discovery and inventory programs. That investment is necessary. But in a typical enterprise, the longest part of the gap is engineering, deployment and exit. And those are determined by architecture.

Here's the part that I think changes the conversation. Two organizations using exactly the same algorithms can face very different risk. One can stop new use of a mechanism across its estate through a governed policy change. The other has to open a multi-year program to do the same thing.

The algorithm determines your exposure on the day of the change. The architecture determines your exposure on every day after.

Migration is not agility

Let me make it concrete.

An organization has 200 applications using RSA and elliptic-curve cryptography. It runs an excellent post-quantum migration. Each application is analyzed, its code changed, a new library introduced, tested, certified, and deployed with Algorithm X. The program takes three years. It succeeds.

The following year, Algorithm X stops being acceptable for one of its uses. A new result. A revised national guideline. A regulator's decision.

The organization now has to modify the same 200 applications again. Same analysis, same engineering, same testing, same certification, same deployment cycle.

It completed a cryptographic migration. It did not achieve crypto agility. It changed the algorithm. It didn't change the architecture that made the change expensive.

That's why post-quantum migration and crypto agility shouldn't be treated as the same project. Migration answers "which algorithm do we use next?" Agility answers "how expensive will it be to change that answer again?"

Recent research from IBM makes the same point formally: when algorithm choice is made at each call site, the cost of every algorithm change multiplies with the number of call sites.

And one more source of false confidence: being able to rotate keys is not the same as being able to change algorithms. Rotation replaces key material. Algorithm agility changes the governed mapping between a use, like "sign invoices," and the mechanism that serves it. You can rotate keys routinely and still find that changing an algorithm is a three-year program.

Where the gap really lives: your data, not your channels

When people hear "crypto agility," most of them think about TLS. Upgrade the protocol, change the cipher suites, move to hybrid key exchange. That work matters, and nothing here argues against it. But it's not where the response gap is longest.

Transport cryptography was designed with agility built in. Algorithms are negotiated per session. Session keys are ephemeral. When a cipher suite stops being acceptable, the fix lives in a relatively small set of places: load balancers, gateways, web servers, libraries maintained by vendors and open-source communities. You update the endpoints and the next session uses the new mechanism. Your business applications usually don't notice.

And look at the five cases again. None of them forced anyone to rewrite their TLS stack. Three were candidates that never got deployed. The two that touch real systems point somewhere else: Classic McEliece was valued precisely as a conservative choice for long-term confidentiality, and the RSA forgery was executed against an HSM acting as a signing oracle. That's application cryptography. That's data cryptography.

Data at rest and data in use don't have any of transport's advantages.

Data at rest is protected with long-lived keys and stays protected for years. Financial records, medical archives, contracts, backups, logs. When a mechanism stops being acceptable, a new session doesn't fix anything. The data already encrypted under the old mechanism is still there, and it has to be re-encrypted. Signatures applied years ago still have to be verifiable, or re-signed.

Data in use is the cryptography inside your business logic. Field-level encryption in a database. Document and transaction signing. Tokens. Payment data. Here the algorithm choice usually lives in application code, in libraries the developer picked, in formats the application expects. That's exactly where the 200-application problem lives.

Transport agility is largely solved by the protocols. Data agility is not solved by anyone unless you architect for it.

This is the same argument I made in the first article of my series "Your TLS upgrade won't save you": quantum safety must begin at the data layer. It turns out crypto agility must begin there too. Upgrade your channels, yes. But your channels can change in weeks. Your data and your applications are where a change in acceptability turns into a multi-year program.

The half nobody talks about: leaving old cryptography

Most conversations about crypto agility focus on adopting new algorithms. The harder half is leaving old ones.

When a mechanism stops being acceptable for new protection, you rarely stop needing it. Archives still need to be decrypted. Signed contracts, invoices and logs still need to be verified. Data needs to be re-encrypted. Historical evidence needs to remain verifiable for years.

That requires states between "approved" and "forbidden," expressed per operation. Not for new deployments. Deprecated. Legacy use only. Migration only, within governed re-encryption workflows with an end date. Disallowed. Most of this vocabulary already exists in NIST and BSI guidance.

And two things make it work in practice. The state has to be enforced where cryptography executes, so a mechanism in legacy use can't be used to encrypt even if an application asks for it. And the organization has to be able to prove it: that a given mechanism hasn't applied new protection since a given date.

Adopting new cryptography is half of crypto agility. A controlled exit from old cryptography is the other half.

Agility done right, and the critics who are right

Crypto agility has serious critics, and they deserve an answer. Adam Langley argued years ago that extensibility adds code, bugs and dangerous interactions, and tends to fail exactly when you need it. RFC 7696 warns that negotiation creates downgrade attacks and that supporting too many algorithms is harmful. NIST itself acknowledges that agility adds complexity.

They're right. And they point to a specific kind of agility, not away from agility:

• Governed, not negotiated. The mechanism for a use is decided by policy and enforced centrally, not negotiated per session between parties that can be manipulated into choosing the weakest option.
• Curated, not exhaustive. A small set of approved mechanisms per use. Agility doesn't mean supporting everything.
• One joint, well exercised. Change happens at a single governed point, used routinely, so it works when it's needed.
• Exit as a first-class operation. Deprecated mechanisms are removed from new use deliberately, not left lying around as fallbacks.

This is the architectural consequence of everything above. If cryptographic security changes over time, algorithm choice can't stay a permanent decision embedded in each application. Applications should express what they need, like protecting a record or signing a document. Policy should decide which mechanism serves that need. And that policy should be owned by the people accountable for cryptographic risk and enforced where the operations execute.

Why you can't wait for your PQC migration to finish

Here's the uncomfortable consequence of everything above. The worst time to think about crypto agility is after your post-quantum migration.

If you migrate 200 applications by hardcoding a new algorithm into each one, you'll have spent three years recreating the exact architecture that made the migration expensive. Just with newer math. The next change in acceptability, whatever causes it, will find you in the same place.

The best time is now, while you're going to touch those applications anyway. If you're going to open the code, open it once: replace the embedded algorithm with a stable cryptographic capability governed by policy. Then the PQC migration becomes the last time you need to touch that application for cryptographic reasons, not the first of many.

Meanwhile, three things keep growing every day you wait.

The data you encrypt today under today's mechanisms is data you may have to re-encrypt tomorrow. The volume only goes up.

Every new application your teams build with embedded cryptography adds to the response gap you'll have to close later.

And regulators have started asking the question directly. Saudi Arabia's central bank now requires financial institutions to assess not only which cryptographic assets they have, but the constraints, challenges and third-party dependencies that limit their ability to change them. Knowing what you have is no longer enough. You're expected to know whether you can move it.

Three questions for Monday morning

The whitepaper includes six questions designed to reveal the length of your response gap before a real change does. Here are the three I'd start with:

1. If the mechanism protecting your most critical data became unacceptable tomorrow, how many applications would you have to modify?
2. If that mechanism protects data stored for the next ten years, can you re-encrypt it without going back to the applications that created it?
3. Can you demonstrate to an auditor that a mechanism has not been used to apply new protection since a given date?

Organizations that can answer these with evidence are ready for the post-quantum transition, and for the transitions that will follow it. Organizations that can't are preparing for one change at a time.

The real question

Post-quantum migration prepares you for the cryptographic transition everyone can see coming. Crypto agility prepares you for the ones nobody can predict.

The quantum computer is one clock. It's not the only one. Classical cryptanalysis, AI-assisted research, cheaper computing, theory becoming practice, and above all standards and regulators changing what's acceptable: all of them run on their own schedules, and none of them will give you notice.

The question is not whether cryptography will change. It will.

The question is how much of your enterprise has to change when it does.

If the answer is "every application that touches sensitive data," the time to change that answer is now. Not after the migration. During it. Starting with the layer where the gap is longest: the cryptography that protects your data at rest and in use.

The full whitepaper, Crypto agility beyond the quantum clock, including the evidence, the Response Gap model and all six questions, is available on the crypto-agility solution page.

Crypto agility is the first property we designed ANKASecure© to provide at ANKATech: applications invoke stable capabilities, algorithms are governed as policy, and old cryptography is retired deliberately, with evidence.