Crypto agility beyond the quantum clock

Executive summary

Most enterprise conversations about the future of cryptography follow a single storyline. A cryptographically relevant quantum computer will eventually arrive, RSA and elliptic-curve cryptography will stop being safe, and organizations must migrate to post-quantum cryptography (PQC) before that happens. Harvest-now, decrypt-later attacks make part of that risk present today, and governments have turned it into deadlines.

That storyline is correct. It is also incomplete. It describes one cryptographic transition, the one everyone can see coming, and it invites a dangerous conclusion: that once the migration to PQC is finished, the problem is solved.

The evidence of the last four years points in a different direction. Rainbow, a finalist in NIST's post-quantum process, fell to a classical attack that recovered keys on a laptop. SIKE was broken in minutes on a single core, less than a month after NIST advanced it to the fourth round. HAWK, a Round 3 signature candidate, was withdrawn in July 2026 after an AI-assisted analysis halved its effective key size. Classic McEliece, a design from 1978 standardized by ISO/IEC in June 2026, was the subject of such a rapid wave of structural cryptanalysis that by September 2026 Germany's BSI advised against using it in new developments, while confirming that no practical attack exists. And an RSA forgery technique described in 2007 was carried out at real scale against a hardware security module in 2026. None of these events required a quantum computer.

Post-quantum migration prepares organizations for a cryptographic transition they can see coming. Crypto agility prepares them for the cryptographic changes they cannot predict.

This paper makes four arguments. First, cryptographic security is an evolving assessment, not a permanent property, and the world's leading standards bodies have said so for years. Second, an algorithm does not need to be broken to become unusable for an enterprise: standards, regulators and policies can withdraw acceptability before any practical attack exists. Third, what determines enterprise risk is not only whether a mechanism becomes unacceptable, but how long the organization remains dependent on it afterwards, a period we call the Cryptographic Response Gap. Fourth, an organization can complete a full cryptographic migration and still not be crypto-agile, because changing the algorithm does not change the architecture that made the change expensive.

From these arguments the paper derives an architectural consequence. If cryptographic security changes over time, the choice of algorithm should not remain a permanent decision embedded in each application. It should be governed as policy, enforced through a stable abstraction, and accompanied by a controlled way to exit old cryptography, because adopting new algorithms is only half of crypto agility.

This document is a companion to The Cryptographic Control Plane whitepaper, which introduces the CAPA framework (Crypto Agility Posture Architecture) ^[22]. Crypto agility is the first of CAPA's five pillars. This paper develops it in the context where it is most often misunderstood: the belief that the post-quantum transition is the last cryptographic change an organization will need to make.

How to read the evidence in this paper

Every claim in this paper belongs to one of four categories, and the text signals which. Citations in brackets refer to the references at the end of the document.

We never attribute our interpretations to the institutions we cite. NIST does not say that enterprises need a Cryptographic Control Plane. NIST defines the problem of crypto agility, the IETF has required algorithm agility for a decade, recent research shows several distinct causes of cryptographic change, and we derive an architectural consequence from all three.

The comfortable assumption

Every cryptographic transition is shaped by the story organizations tell themselves about why it is happening. The story of the post-quantum transition is unusually clear, and that clarity is both its strength and its limitation.

2.1 What the quantum narrative gets right

The quantum threat to public-key cryptography is real and well understood. A sufficiently capable quantum computer running Shor's algorithm would break RSA, finite-field Diffie-Hellman and elliptic-curve schemes, which together protect most key exchange and digital signatures in use today. Because encrypted traffic and stored data can be captured now and decrypted later, the risk to long-lived information begins before such a machine exists.

Governments have converted this threat into calendars. NIST's transition plan deprecates quantum-vulnerable public-key algorithms (RSA, ECDSA, EdDSA, Diffie-Hellman and MQV) after 2030 and disallows them after 2035 ^[5]. In the United States, Executive Order 14412 of June 2026 requires high-value assets and high-impact systems to move to post-quantum key establishment by the end of 2030 and to post-quantum signatures by the end of 2031, explicitly citing adversaries who collect data today to decrypt it later ^[6]. The UK NCSC asks organizations to complete discovery and planning by 2028, priority migrations by 2031 and full migration by 2035 ^[7], and the European Union's coordinated roadmap converges on similar milestones ^[8].

None of this is in question here. Post-quantum migration is necessary, it is urgent, and organizations that delay it are accumulating risk.

2.2 What the narrative leaves out

The comfortable version of the story has a simple shape:

The flaw is in the last step. It treats cryptographic change as a single event with a known cause, a known destination and an end date. It assumes that the algorithms chosen in the migration will remain acceptable for as long as the organization needs them, and that if they ever stop being acceptable, there will be years of warning.

Neither assumption is supported by the history of cryptography, and the events of the last four years have made the point difficult to ignore.

2.3 Quantum is not the only clock

A cryptographically relevant quantum computer is one force that can change the security assessment of a cryptographic mechanism. It is not the only one. The assessment can also change because of:

• New classical cryptanalysis, which finds structure that earlier analysis missed.
• Advances in classical computing capacity, which make known attacks cheaper.
• New ways of exploiting existing capabilities, which turn a theoretical attack into a practical one under realistic access conditions.
• AI applied to mathematical research and cryptanalysis, which changes the speed at which weaknesses are found.
• Changes in standards, recommendations and policy, which can withdraw the acceptability of a mechanism before it is broken.
• Quantum computing, eventually.

Post-quantum migration is a known transition. Cryptographic change is a permanent condition.

Cryptographic security is an evolving assessment

The claim that cryptographic security changes over time is not a marketing position. It is the stated view of the institutions that define cryptographic practice, and it predates the current wave of post-quantum attention by many years.

3.1 What NIST says

NIST's Crypto Agility project states that advances in computing capabilities, cryptographic research and cryptanalytic techniques periodically create the need to replace algorithms that no longer provide adequate security for their use cases ^[2]. Its white paper on crypto agility, updated in June 2026, defines crypto agility as the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware and infrastructures while preserving security and ongoing operations ^[1].

The same paper documents how slow such replacements have been in practice. The complete transition from Triple DES to AES took 23 years. SHA-1, whose collision weakness was identified in 2005, continued to be accepted in limited circumstances long afterwards for interoperability reasons. Minimum RSA key sizes moved from 1024 to 2048 bits as factoring and computing improved ^[1]. NIST's post-quantum transition plan adds that past cryptographic migrations have taken more than a decade, and that the post-quantum migration will likely take at least as long ^[5].

3.2 What the IETF has said since 2015

The IETF formalized the same view in RFC 7696, a Best Current Practice (BCP 201) published in November 2015. It states that cryptographic algorithms age and become weaker over time, as new cryptanalytic techniques are developed and computing capabilities improve, and that the timing and extent of those advances cannot be known in advance. Protocols therefore need mechanisms to migrate from one algorithm to another ^[3].

RFC 7696 goes further, in a way that matters for enterprises. It recommends that the transition away from an algorithm should happen before the algorithms in the current set have weakened to the breaking point ^[3]. It also defines requirement levels designed to signal, ahead of time, that an algorithm is expected to be demoted or deprecated. In other words, the standards community has long treated obsolescence as something to be managed before failure, not after it.

3.3 Algorithms don't give notice

Taken together, these positions lead to a formulation that this paper uses throughout. It is our formulation, not a phrase attributed to NIST or the IETF:

Algorithms do not suddenly change. Our knowledge about their security can.

There is no reason to expect a graceful decline from fully secure to slightly weaker to a formal warning to six months of remaining life. A single result can move the assessment of a mechanism abruptly, and the cases in the next chapter show exactly that. An organization therefore cannot assume that it will always have several years to react.

Five warnings from the real world

The following five cases were selected because each illustrates a different way in which the assessment of a cryptographic mechanism can change. They are not presented as evidence that cryptography is broken, or that post-quantum standards are unsafe. They are evidence that the assessment moves, and that it moves on its own schedule.

Not one of these required a quantum computer.

That observation does not diminish the quantum risk. It widens the risk model.

4.1 Rainbow: a finalist falls on a laptop

Rainbow was one of three digital signature finalists in the third round of NIST's post-quantum standardization process. In February 2022, Ward Beullens published new attacks that outperformed all previously known attacks for every parameter set submitted to NIST. For the level-1 parameters of the second-round submission, his attack recovered the secret key in about 53 hours on average on a standard laptop. He estimated that recovering a key for the third-round level-1 parameters would be only about 28 times more costly ^[9]. Rainbow was not selected for standardization.

Rainbow is the cleanest example of an abrupt reassessment. A scheme that had survived years of public scrutiny and two rounds of selection was, after one paper, no longer a candidate anyone would deploy.

4.2 SIKE: broken weeks after advancing

SIKE was an isogeny-based key encapsulation mechanism that NIST advanced to the fourth round of its process in July 2022, as a candidate for additional standardization. Less than a month later, Wouter Castryck and Thomas Decru published a classical key-recovery attack that, in the revised version of their paper, breaks SIKEp434, the level-1 parameter set, in about ten minutes on a single core ^[10]. The attack built on a 1997 mathematical result by Ernst Kani whose consequences for the scheme had not been recognized during years of public analysis.

SIKE illustrates how short the interval between institutional confidence and practical failure can be.

4.3 HAWK: AI-assisted cryptanalysis

HAWK was a lattice-based signature scheme. On 14 May 2026, NIST announced that it was among the nine candidates advancing to the third round of its additional digital signature process ^[11]. On 28 July 2026, Anthropic's Frontier Red Team disclosed an improved key-recovery attack on HAWK, found with its Claude Mythos Preview model, that exploits a previously unknown structural property of HAWK's lattices and reduces the effective key size by a factor of two. For HAWK-256, the expected attack cost fell from about 264 to about 238. The attack remains exponential-time and, according to Anthropic, is specific to HAWK and does not affect other NIST post-quantum candidates or lattice-based cryptography in general. The HAWK authors received the result in advance, in June ^[12]. On 29 July 2026, the HAWK team withdrew the scheme, and NIST recorded the withdrawal as following Anthropic's announcement ^[11].

HAWK was never deployed, so its withdrawal had no operational impact. Its significance is different: it shows that the rate at which weaknesses are discovered is itself changing. A careful characterization matters here. The result was an exponential improvement in a candidate scheme, verified with demonstration code and disclosed in coordination with its authors, not a general demonstration that AI can break modern cryptography.

4.4 Classic McEliece: maturity does not freeze the assessment

Classic McEliece is conceptually the most important of the five cases, because it is not a young scheme. It derives from the McEliece cryptosystem published in 1978, one of the oldest public-key designs, and its long record of analysis was precisely its main argument. NIST evaluated it in the fourth round of its process, and in March 2025 selected HQC instead, citing the size of Classic McEliece's public keys and limited deployment interest rather than a security weakness ^[16]. ISO/IEC standardized Classic McEliece in June 2026 ^[15], and Germany's BSI has recommended it with selected parameters in its Technical Guideline TR-02102-1 since 2020 ^[14].

Over the following months, the structural analysis of McEliece changed faster than at any point in its history. BSI's own summary, published on 29 September 2026, describes the shift ^[14]. For decades, the best known structural key-recovery attack had an estimated cost above 23000 even for the smallest parameters. Distinguishers published in 2025 and 2026 brought estimates for the parameter sets recommended in TR-02102-1 to 2683 and then 2550. In August 2026, Ghoshal, Ishai, Jain and Sun presented a distinguisher with asymptotically quasipolynomial complexity, which they estimate at between 2120 and 2124 operations for those parameters, together with a heuristic key-recovery method at 2140 to 2148 ^[13][14]. In September, a further preprint claimed key recovery at 299 to 2102 ^[14].

The authors of the quasipolynomial result state that their concrete attacks are not yet practical ^[13]. BSI emphasizes that the most recent papers have not completed peer review, that their cost models, including memory-access costs, must still be examined carefully, and that so far the results do not enable a practical attack on the recommended parameter sets ^[14]. It is therefore wrong to say that Classic McEliece has been broken.

Yet BSI concluded that Classic McEliece should currently no longer be used in new developments or when planning new cryptographic applications. Its recommendation is limited to hybrid use, combined with a classical scheme so that both must be broken to recover the key, and the guideline entry will be revised in early 2027. BSI adds that the other recommended post-quantum schemes, ML-KEM and FrodoKEM, as well as HQC, are not affected, and that the new results underline the importance of crypto agility during the migration because "cryptanalytic advances can never be ruled out" ^[14].

Classic McEliece was not broken. It became unacceptable for new use. That distinction is the subject of the next chapter.

4.5 RSA: when theory becomes practice

The fifth case concerns classical cryptography, and it requires particular precision. In September 2026, Shea, Haller, Suhl, Heninger and Thomé reported a real-scale implementation of an algorithm published in 2007 by Joux, Naccache and Thomé ^[17]. With temporary access to a raw RSA signing or decryption oracle, an attacker can later forge RSA signatures without factoring the modulus and without extracting the private key. The researchers used a real hardware security module as the oracle: 232 queries, about 1,380 CPU core-years of computation and five calendar months. After that precomputation, each chosen signature could be forged offline for about 180 core-years. They estimate that, in this attack model, the concrete security of RSA from 1024 to 4096 bits is 15 to 30 bits lower than factoring-based estimates suggest ^[17].

This result does not mean that RSA-1024, let alone RSA in general, has been factored or broken. It applies to a specific model in which an attacker can obtain unpadded RSA operations from an oracle; the paper's abstract does not establish applicability to padded signature schemes such as PKCS#1 v1.5 or PSS. Its relevance is different: cryptographic change does not have to come from quantum computing, or even from new mathematics. It can come from making something that was theoretical practical at a relevant scale, and security estimates that depended on one attack model can move when another becomes realistic.

4.6 What the five cases show, and what they do not

Three of the five schemes were candidates in a selection process and never became standards. One could argue, correctly, that this is the selection process working as intended. The finalized NIST standards ML-KEM and ML-DSA are not affected by any of these results, and nothing in this paper suggests otherwise.

But the argument of this paper does not depend on standards failing. It depends on a narrower and better-supported observation: the assessment of cryptographic mechanisms changes, sometimes abruptly, for reasons that include but are not limited to quantum computing, and it can change for mature, standardized and widely recommended mechanisms as well as for new candidates. Classic McEliece moved from ISO standard to "not for new developments" in roughly three months. The RSA signing-oracle result revised the concrete security of one of the most deployed algorithms in history. An enterprise architecture that assumes the post-quantum algorithms it selects today will remain acceptable for the life of its systems is making a bet that the evidence does not support.

Broken is not the enterprise threshold

Security discussions often treat cryptography as binary: an algorithm is either secure or broken. Enterprises do not operate on that boundary. They operate on acceptability, and acceptability can be withdrawn long before anything breaks.

5.1 Acceptability is a status, not a property

NIST SP 800-131A, the guideline NIST uses to manage algorithm transitions, does not classify algorithms as secure or insecure. It assigns them a status ^[4]:

The same mechanism can hold different statuses for different operations. Under SP 800-131A, three-key Triple DES encryption was deprecated through 2023 and disallowed afterwards, while decryption remains permitted as legacy use. SHA-1 is disallowed for generating digital signatures, except where specific protocol guidance allows it, but permitted as legacy use for verifying them ^[4]. Acceptability is therefore a property of a mechanism, for a purpose, at a point in time.

5.2 Obsolescence by policy

Several of the most consequential cryptographic changes enterprises will face in the next decade are policy decisions, not cryptanalytic results. NIST's proposed deprecation of quantum-vulnerable algorithms after 2030 and their disallowance after 2035 will apply on those dates whether or not a cryptographically relevant quantum computer has been demonstrated ^[5]. Executive Order 14412 sets its own deadlines in the same way ^[6]. BSI's decision on Classic McEliece shows the same mechanism operating on a much shorter timescale and in response to evidence that stops well short of a practical attack ^[14].

For an enterprise, cryptographic obsolescence can precede cryptographic failure.

5.3 The question a CISO should ask

The practical consequence is a change in the question that cryptographic risk management has to answer. The traditional question is:

Has the algorithm been broken?

The question that actually determines an enterprise's obligations is:

Is this mechanism still acceptable, for this use, under the standards and policies that apply to us?

The second question has more possible answers, its answer changes more often, and it is decided by parties outside the organization's control: standards bodies, national agencies, sector regulators, auditors and counterparties. An organization that can only react to the first question is structurally late.

The cryptographic response gap

If acceptability can change abruptly and for reasons outside the organization's control, the variable that determines enterprise exposure is not only the change itself. It is how long the organization remains dependent on a mechanism after that mechanism is no longer acceptable.

6.1 Definition

We define the Cryptographic Response Gap as the interval between two moments:

• T0, when the security assessment, the applicable standard or the acceptable-use status of a cryptographic mechanism changes for a given use; and
• T1, when the organization completes remediation for that use, meaning that the mechanism is no longer used to apply new protection and the information it protected has been handled according to policy.

Cryptographic risk is not only a function of whether a mechanism becomes unacceptable. It is also a function of how long the organization remains dependent on it after that happens.

6.2 Where the concept comes from

The Cryptographic Response Gap is a specialization of ideas that already exist, and it should be read that way. In 2000, Bruce Schneier described the window of exposure: the period during which a vulnerability can be exploited, from discovery until patches are installed, and he argued that risk grows with both its duration and the number of people able to exploit it ^[18]. In post-quantum planning, Mosca's inequality, which NIST uses in its transition plan, compares the shelf life of data plus the time required to migrate against the time until a quantum computer is available; the migration time is a central variable of that analysis ^[5].

The Cryptographic Response Gap borrows the structure of the first and the migration-time variable of the second, and differs from both in two ways. Its trigger is any change in acceptability, not only an exploitable flaw and not only the arrival of a quantum computer. And its remediation is not a vendor patch but the replacement of a mechanism across every system that depends on it, which is why it is usually measured in months or years rather than days. We found no existing term for this precise interval; we propose it as a practical lens, not as a new standard.

6.3 What determines the length of the gap

The gap is the sum of several activities, each of which can be short or long depending on architecture rather than effort:

Most organizations invest in shortening the first two activities through discovery and inventory programs. Those investments are necessary. But in a typical enterprise, the longest part of the gap lies in engineering, deployment and exit, and those are determined by architecture.

6.4 Why the gap, not the algorithm, is the enterprise variable

An organization cannot control when a mechanism becomes unacceptable. It can control how long its gap will be when that happens. Two organizations that use exactly the same algorithms face very different risk if one can stop new use of a mechanism across its estate through a governed change and the other must open a multi-year program to do the same. The choice of algorithm determines the organization's exposure on the day of the change; the architecture determines its exposure on every day after.

The 200-application problem

The difference between migration and agility is easiest to see in a single, deliberately simple example.

7.1 Migration is not agility

Consider an organization with 200 applications that use RSA and elliptic-curve cryptography. It runs a well-executed post-quantum migration: each application is analyzed, its code is changed, a new cryptographic library is introduced, the application is tested and certified, and it is deployed to production using Algorithm X. The program takes three years and succeeds.

Now suppose that, the year after, Algorithm X is no longer acceptable for one of its uses: a new result, a revised national guideline, a sector regulator's decision. The organization must now modify the same 200 applications again, through the same analysis, engineering, testing, certification and deployment cycle.

The organization completed a cryptographic migration. It did not necessarily achieve cryptographic agility. It changed the algorithm; it did not change the architecture of the problem.

This is the central reason why post-quantum migration and crypto agility should not be treated as the same project. Migration answers the question of which algorithm to use next. Agility answers the question of how expensive it will be to change that answer again.

If tomorrow the cryptographic mechanism protecting your business became unacceptable, how many applications would you have to modify to replace it?

7.2 The cost of coupling

Recent academic work on application-level crypto agility makes the same point formally. Rameshan and Messmer of IBM Research propose an assessment framework that measures how tightly applications are coupled to specific algorithms and providers. They show that, in a system with minimal agility, the cost of migrating to a new algorithm grows with the number of places where cryptographic operations and keys are created, multiplied by the number of parameters that differ between the old and new mechanisms. Evaluating PKCS#11, OpenSSL 3.0, the Java Cryptography Architecture, Google Tink, AWS KMS and HashiCorp Vault Transit, they find recurring gaps, including the absence of a governance authority over cryptographic choices ^[19].

The 200-application example is illustrative, not a dataset. But the mechanism it describes is general: as long as algorithm choice is made at the call site, every change of algorithm costs a multiple of the number of call sites.

7.3 Key rotation is not algorithm agility

A frequent source of false confidence is the assumption that an organization able to rotate keys is also able to change algorithms. They are different capabilities, governed by different guidance. Key management standards treat key replacement through cryptoperiods and usage periods as a lifecycle function ^[21], while algorithm transitions are managed through status changes of the kind described in SP 800-131A ^[4].

The architectural question underlying all three columns is whether the algorithm remains coupled to the application. If it does, rotation can be routine and migration will still be a program.

Architecting for cryptographic change

If cryptographic security is an evolving assessment, the architectural consequence follows directly. This is our interpretation, consistent with but not attributed to the institutions cited in this paper:

Algorithm choice should not remain a permanent application-level decision.

8.1 Separate cryptographic intent from cryptographic mechanism

NIST's crypto agility paper describes the first building block: a cryptographic API that separates the implementation of applications from the implementation of cryptographic algorithms, so that applications can make the same calls while the algorithm behind them changes, and old and new algorithms can coexist during a transition ^[1]. The Cryptographic Control Plane whitepaper describes the same principle at enterprise scale as the separation of cryptographic intent from cryptographic execution: applications express what they need, such as protecting a record or signing a document, and infrastructure determines how ^[22].

8.2 Make policy the decision point

An abstraction alone does not create agility; it creates a place where a decision can be made. NIST describes how an administrator-defined algorithm policy can block calls to deprecated algorithms while still allowing decryption of stored data, and how cryptographic policy can be expressed as a machine-consumable profile deployed with automated tools ^[1]. The decision about which mechanism serves which use, under which conditions, belongs in that policy, owned by the people accountable for cryptographic risk and enforced where cryptographic operations execute.

8.3 Agility without negotiation: answering the critics

Crypto agility has thoughtful critics, and a credible architecture has to address them. Adam Langley argued in 2016 that extensibility mechanisms add code, bugs and dangerous interactions, that they tend to fail when they are finally needed, and that protocols should concentrate extensibility in one place and keep it exercised ^[20]. RFC 7696 itself warns that complex negotiation creates opportunities for downgrade attacks and that supporting too many algorithms is harmful, because weak options persist and are hard to remove ^[3]. NIST acknowledges that accommodating agility adds complexity and can increase the attack surface ^[1].

These criticisms are correct, and they point toward a specific kind of agility rather than away from agility altogether:

• Governed, not negotiated. The mechanism for a given use is decided by policy and enforced centrally, not negotiated per session between parties that may be manipulated into choosing the weakest option.
• Curated, not exhaustive. The policy admits a small set of approved mechanisms for each use; agility does not mean supporting everything.
• One joint, well exercised. Change is concentrated at a single governed point and used routinely, so that it works when it is needed.
• Exit as a first-class operation. Deprecated mechanisms are removed from new use deliberately, rather than left as fallbacks.

8.4 Hybrid as a hedge

The Classic McEliece case also shows the value of hybrid constructions, in which a post-quantum mechanism is combined with a classical one so that both must be broken. BSI notes that its recommendation to deploy post-quantum cryptography in hybrid mode has proven its worth, because the impact of a weakened scheme is mitigated ^[14]. Hybrid mode is not a substitute for agility, but it buys time, and agility is what makes hybrid configurations practical to introduce, adjust and eventually retire.

Adoption is only half of crypto agility

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

9.1 Obsolescence does not mean deletion

When a mechanism stops being acceptable for protecting new information, the organization rarely stops needing it. Encrypted archives must still be decrypted. Signed contracts, invoices and logs must still be verified. Data must be recovered, migrated, re-encrypted or re-signed under new mechanisms, and historical evidence must remain verifiable for years. NIST makes the same point: replacing a signature algorithm requires a mechanism to handle documents already signed with it, and replacing an encryption algorithm requires a mechanism to handle data already encrypted with it ^[1].

Adopting new cryptography is only half of crypto agility. Organizations also need a controlled way to exit old cryptography.

9.2 A lifecycle of cryptographic states

A controlled exit requires states between "approved" and "forbidden", and those states should be expressed per operation. Existing terminology already covers most of what is needed, and we recommend adopting it rather than inventing a new vocabulary. The table maps the states an enterprise needs to existing references, and marks the one we propose as an extension.

Two properties make this lifecycle operational rather than descriptive. The state must be enforced where cryptographic operations execute, so that a mechanism in legacy use cannot be used to encrypt or sign even if an application requests it. And the organization must be able to demonstrate the state: that a given mechanism has not been used to apply new protection since a given date, and that the remaining legacy use is confined to the workflows that policy allows.

9.3 Modernizing what is already protected

The exit is complete only when the information protected under the old mechanism has been handled. For data with long retention periods, that means re-encrypting it under acceptable mechanisms; for long-lived signatures, it may mean re-signing or adding new evidence. When this work depends on the applications that created the data, it becomes another multi-application program. When it can be performed by governed infrastructure, progressively and without recreating the underlying information, it becomes an operational process ^[22].

From PQC migration to continuous cryptographic readiness

The objective that follows from this analysis is not a completed migration. It is a state in which the organization can absorb changes in cryptographic acceptability, from any cause, with a short and predictable response gap.

10.1 Mapping the response gap to CAPA maturity

The CAPA maturity model described in The Cryptographic Control Plane whitepaper ^[22] can be read through the lens of the response gap. The characterization below is ANKATech's interpretation of the model, not an external benchmark.

NIST proposes a complementary view, adapting the tiers of its Cybersecurity Framework to crypto agility, from partial and unplanned practices to an adaptive state in which cryptographic risk is monitored, measured and reported to executives ^[1]. Both models point to the same conclusion: maturity is measured by the ability to change, not by the algorithms currently in use.

10.2 Six questions for the CISO

The following questions are designed to reveal the length of an organization's response gap before a real change does:

1. If the mechanism protecting your most critical data became unacceptable tomorrow, how many applications would you have to modify?
2. Can you list every place a given algorithm is used, distinguishing operations such as encrypt from decrypt and sign from verify?
3. Can you stop new use of a mechanism without stopping the decryption and verification of what it already protects?
4. Who decides which mechanism serves which use, and where is that decision enforced?
5. Can you demonstrate to an auditor that a mechanism has not been used to apply new protection since a given date?
6. Have you measured your response gap for each class of system, and do you know which systems define its upper bound?

Organizations that can answer these questions with evidence are prepared for the post-quantum transition and for the transitions that will follow it. Organizations that cannot are preparing for one change at a time.

ANKASecure© and crypto agility

The preceding chapters describe an architectural model that can be implemented in more than one way. ANKASecure© is ANKATech's implementation of the Cryptographic Control Plane, and crypto agility is the first property it is designed to provide.

11.1 Stable capabilities, governed mechanisms

Applications invoke stable cryptographic capabilities such as encrypt, decrypt, sign and verify against stable key identifiers. The mechanism behind a capability is governed by the platform: a key rotation advances to a new material version under the same identifier, and that version may use a different algorithm within the same purpose family, without changes to the applications that use it. Hybrid composite keys combining classical and post-quantum algorithms, and post-quantum mechanisms based on NIST FIPS 203, 204 and 205, can be introduced through the same path.

11.2 Three policies for the full lifecycle

ANKASecure© expresses crypto agility through three policy types, defined at deployment and tenant level:

• Algorithm availability determines which algorithms may be used, by explicit list, family, category (classical, post-quantum or hybrid), security level, mandatory standards body or permitted operations. A hybrid-only profile, for example, implements a BSI-style requirement as policy rather than code.
• Algorithm rotation governs which transitions are allowed, for example forbidding security downgrades or a return from post-quantum to classical algorithms.
• Key lifecycle governs which operations are permitted in each state. Superseded and retired material remains available for decrypt and verify while new encryption and signing are denied, and a key revoked with an algorithm-deprecation cause keeps its historical data readable, while a key revoked for compromise is sealed on every operation.

Together, these policies implement the controlled exit described in Chapter 9: stopping new use of a mechanism, preserving legacy processing where policy allows it, and ending it deliberately.

11.3 Modernizing protected data

Dedicated re-encryption and re-signing operations, including streaming operations for large data objects, allow information protected under an old mechanism to be moved to a new one without requiring the applications that created it to recreate the data. This is what turns the last part of the response gap, the exit, from a program into a process.

11.4 Evidence of cryptographic state

Every operation is recorded with its context, including the algorithm and key used, producing evidence of which mechanisms are applying protection, for which uses, and since when. Demonstrating that a mechanism is no longer used for new protection becomes a query against governed records rather than an audit of individual applications.

11.5 Getting started

1. Response-gap assessment: identify the mechanisms and systems that would define the organization's gap if a mechanism it relies on became unacceptable.
2. Demonstration and reference architecture: ANKASecure© changing an algorithm, retiring a mechanism and re-encrypting data end to end, on a case analogous to the organization's own.
3. Scoped pilot: one critical use governed by policy, with keys anchored in the organization's existing HSM or KMS.

Conclusion

The post-quantum transition is the largest cryptographic change most organizations will undertake, and it deserves the urgency it is receiving. But it is not the last cryptographic change they will face. The evidence of the last four years, from Rainbow and SIKE to HAWK, Classic McEliece and the RSA signing oracle, shows that the assessment of cryptographic mechanisms moves for many reasons, on its own schedule, and sometimes in months.

For enterprises, the decisive threshold is not whether a mechanism is broken but whether it is still acceptable for a given use, and acceptability can be withdrawn before any practical attack exists. What determines risk when that happens is the Cryptographic Response Gap: how long the organization remains dependent on a mechanism after it stops being acceptable. That gap is set by architecture. An organization that completes a migration with algorithms embedded in every application has changed its cryptography but kept its gap.

Crypto agility closes it. It means separating what applications need from the mechanisms that provide it, governing those mechanisms as policy, enforcing that policy where cryptography executes, and managing the exit from old cryptography as deliberately as the adoption of new cryptography.

The question is not whether cryptography will change. It will. The question is how much of your enterprise must change when it does.

References

1. [1] NIST. Considerations for Achieving Crypto Agility: Strategies and Practices. Cybersecurity White Paper CSWP 39, December 2025, updated June 29, 2026. https\://doi.org/10.6028/NIST.CSWP.39-upd1
2. [2] NIST Computer Security Resource Center. Crypto Agility project. https\://csrc.nist.gov/projects/crypto-agility
3. [3] R. Housley. Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms. IETF RFC 7696 / BCP 201, November 2015. https\://www.rfc-editor.org/rfc/rfc7696
4. [4] E. Barker, A. Roginsky. Transitioning the Use of Cryptographic Algorithms and Key Lengths. NIST SP 800-131A Rev. 2, March 2019. https\://doi.org/10.6028/NIST.SP.800-131Ar2
5. [5] NIST. Transition to Post-Quantum Cryptography Standards. NIST IR 8547, October 2026. https\://doi.org/10.6028/NIST.IR.8547
6. [6] The White House. Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks, June 22, 2026. https\://www.whitehouse.gov/wp-content/uploads/2026/06/eo-14412.pdf
7. [7] UK National Cyber Security Centre. Timelines for migration to post-quantum cryptography, March 2025. https\://www.ncsc.gov.uk/guidance/pqc-migration-timelines
8. [8] NIS Cooperation Group. A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, June 2025.
9. [9] W. Beullens. Breaking Rainbow Takes a Weekend on a Laptop. CRYPTO 2022; IACR ePrint 2022/214. https\://eprint.iacr.org/2022/214
10. [10] W. Castryck, T. Decru. An efficient key recovery attack on SIDH. EUROCRYPT 2023; IACR ePrint 2022/975. https\://eprint.iacr.org/2022/975
11. [11] NIST. Nine candidates advance to third round of additional digital signatures for PQC, May 14, 2026, updated July 29, 2026. https\://www.nist.gov/news-events/news/2026/05/nine-candidates-advance-third-round-additional-digital-signatures-pqc
12. [12] Anthropic Frontier Red Team. Discovering cryptographic weaknesses with Claude, July 28, 2026. https\://www.anthropic.com/news/discovering-cryptographic-weaknesses
13. [13] A. Ghoshal, Y. Ishai, A. Jain, N. Sun. Quasipolynomial Cryptanalysis of the McEliece Cryptosystem (or: PIR Meets McEliece). IACR ePrint 2026/1630, August 2026. https\://eprint.iacr.org/2026/1630
14. [14] Bundesamt für Sicherheit in der Informationstechnik (BSI). Notes on recent developments concerning Classic McEliece, September 29, 2026.
15. [15] ISO/IEC 18033-2:2006/Amd 2:2026. Information technology, Security techniques, Encryption algorithms, Part 2: Asymmetric ciphers, Amendment 2.
16. [16] NIST. Status Report on the Fourth Round of the NIST Post-Quantum Cryptography Standardization Process. NIST IR 8545, March 2025. https\://doi.org/10.6028/NIST.IR.8545
17. [17] L. Shea, M. Haller, A. Suhl, N. Heninger, E. Thomé. Forging 1024-bit RSA signatures in nearly SNFS time. IACR ePrint 2026/2131, September 2026. https\://eprint.iacr.org/2026/2131
18. [18] B. Schneier. Full Disclosure and the Window of Exposure. Crypto-Gram, September 15, 2000. https\://www.schneier.com/crypto-gram/archives/2000/0915.html
19. [19] N. Rameshan, G. Messmer. An Assessment Framework for Application-Level Cryptographic Agility. arXiv:2606.13425, 2026. https\://arxiv.org/abs/2606.13425
20. [20] A. Langley. Cryptographic Agility. ImperialViolet, May 16, 2016. https\://www.imperialviolet.org/2016/05/16/agility.html
21. [21] E. Barker. Recommendation for Key Management: Part 1, General. NIST SP 800-57 Part 1 Rev. 5, May 2020. https\://doi.org/10.6028/NIST.SP.800-57pt1r5
22. [22] ANKATech Solutions INC. The Cryptographic Control Plane: Introducing CAPA, Crypto Agility Posture Architecture. Whitepaper V2, September 2026.
23. [23] ANKATech Solutions INC. Cryptographic Sovereignty in Third-Party Information Exchange. Whitepaper V3, 2026.

ANKATech Solutions INC. ANKASecure© is a product of ANKATech Solutions INC. This document is provided for information purposes and reflects the state of the cited sources as of October 2026.