Crypto-agility explained: how to measure it before the post-quantum migration

Published 7 October 2026 · 7 min read · By Ali Korsi Post-quantum migration will not be your last cryptographic migration. Agility is what makes the next one cheap — and you can measure it.

Lire en français

“Crypto-agility” appears in almost every post-quantum strategy document, usually as a goal and rarely as something anyone measures. That is a problem, because the cost of your migration to ML-KEM and ML-DSA will be decided less by the new algorithms than by how tightly the old ones are wired into your systems.

What crypto-agility actually means

NIST’s Cybersecurity White Paper 39, finalised in December 2025, describes crypto agility as the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations.

In practice, an agile system lets you change three things without re-architecting:

• Algorithms — RSA to ML-KEM, ECDSA to ML-DSA, SHA-1 to SHA-256.
• Parameters — key sizes, curves, security levels, modes.
• Implementations — the library, provider, HSM or KMS that does the work.

If changing any of these means touching application logic in dozens of places, rewriting a file format or waiting for a vendor’s next major release, you are not agile — whatever the architecture diagram says.

Why post-quantum will not be the last migration

Cryptographic migrations are routine, not exceptional. A few that most enterprises have already lived through:

• SHA-1 — deprecated by NIST for digital signatures in 2011, hit by the first public practical collision in 2017, and due to be phased out of NIST-approved use entirely by 31 December 2030.
• Triple DES — weakened by its 64-bit block (the 2016 Sweet32 attack) and disallowed for encryption by NIST after 31 December 2023.
• RSA-1024 — disallowed for new digital signatures under NIST SP 800-131A after 2013.

Each of these took most organisations years, largely because nobody knew where the algorithm was used. Post-quantum is the same problem at a larger scale: NIST’s draft transition plan (IR 8547) proposes deprecating quantum-vulnerable RSA and elliptic-curve algorithms after 2030 and disallowing them after 2035.

And the new algorithms are young. In 2022, SIKE — then a fourth-round candidate in NIST’s post-quantum process — was broken by a classical key-recovery attack that ran in about an hour on a single core. The same year, the Rainbow signature scheme, a third-round finalist, fell to a practical classical attack. Neither was standardised, but both show that confidence in a new algorithm can collapse quickly.

That is why European agencies push hybrid deployments, combining a classical and a post-quantum algorithm so that security does not rest on either one alone. ANSSI and BSI both recommend hybrid mechanisms during the transition, and in November 2024 18 EU member states, led by France, Germany and the Netherlands, issued a joint statement urging organisations to make the transition a priority. Hybrid is a hedge; agility is what lets you remove the weaker half later.

The anti-patterns that kill agility

In code and configuration reviews, the same patterns recur:

• Hard-coded algorithms — algorithm names and constructors scattered through business logic.
• Pinned key sizes and curves — 2048 or secp256r1 as literals, often duplicated in tests, schemas and database column widths.
• Cryptography baked into protocols and storage formats — fixed-length signature fields, binary formats without an algorithm identifier, tokens that assume one key type. ML-DSA signatures are several kilobytes; a field sized for ECDSA will not hold them.
• Vendor libraries you do not control — appliances, SDKs and SaaS components whose cryptography only changes when the vendor ships an update.
• No owner — certificates and keys created by projects that no longer exist.

The first two are the easiest to spot and to fix. Compare:

# Brittle: algorithm and key size fixed at the call site
from Crypto.PublicKey import RSA
key = RSA.generate(2048)

# Agile: algorithm chosen by policy, behind one interface
from crypto_provider import get_signer
signer = get_signer(purpose="document-signing")  # reads central policy
signature = signer.sign(payload)

The second version does not make the code post-quantum. It makes the change a policy update plus a provider implementation, instead of a search-and-replace across every repository — and it keeps the algorithm identifier with the data, so old and new signatures can coexist during the transition.

A practical five-level maturity model

Maturity models are only useful if each level is observable. This one is deliberately evidence-based: you should be able to show an auditor why you are at a given level.

Many organisations will find themselves at level 1 or 2. That is a normal starting point, not a failure — but you cannot plan a migration credibly from level 1.

Indicators you can actually measure

Pick a handful of indicators, measure them now, and re-measure each quarter. Four are enough to start:

1. Inventory coverage — percentage of applications, certificates and endpoints with known cryptography. Without this, every other number is a guess. See our guide to cryptographic inventory.
2. Centralisation rate — percentage of cryptographic call sites that go through an approved provider or abstraction rather than calling a primitive directly.
3. Time-to-rotate — elapsed time to replace an algorithm, key size or certificate across a representative system, measured in an exercise rather than estimated.
4. New-weak-crypto gate — whether a CI/CD control prevents new quantum-vulnerable or deprecated cryptography from being merged. If it does not, your inventory decays from the day you finish it.

An agility programme without a gate is a one-off clean-up. The debt starts growing back with the next pull request.

Two supporting measures are worth tracking where relevant: the proportion of quantum-vulnerable assets protecting long-lived data (your HNDL exposure), and the number of critical dependencies whose cryptography only a vendor can change.

Where to start

1. Inventory first. Scan code, certificates and TLS endpoints. You need to know where RSA, ECC, SHA-1 and 3DES live before you can measure centralisation.
2. Baseline the four indicators on two or three representative systems, not the whole estate.
3. Introduce a provider abstraction for new code and for the systems you will migrate first.
4. Add a CI gate so new weak cryptography is caught at pull-request time.
5. Feed the results into your migration plan — systems with low agility need earlier starts and more budget. Our PQC migration roadmap explains how to sequence the waves.

If you want a quick sense of where you stand, the free 2-minute PQC readiness self-assessment is a reasonable first step. To see how CRYPTAGION supports each step, read crypto agility with CRYPTAGION.

The takeaway

Crypto-agility is not a product feature or a slogan; it is a measurable property of your estate. Organisations that can show inventory coverage, a centralisation rate, a tested time-to-rotate and a working CI gate will find the post-quantum migration — and the one after it — far cheaper than those that start from scratch each time.

Sources

• NIST, CSWP 39, Considerations for Achieving Cryptographic Agility: Strategies and Practices (final, 19 December 2025).
• NIST, IR 8547 (initial public draft), Transition to Post-Quantum Cryptography Standards (November 2024).
• NIST NCCoE, SP 1800-38, Migration to Post-Quantum Cryptography (preliminary drafts, 2023; not yet final).
• NIST, SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths (2019).
• NIST, NIST retires SHA-1 cryptographic algorithm (December 2022).
• W. Castryck and T. Decru, An efficient key recovery attack on SIDH, IACR ePrint 2022/975.
• ANSSI, BSI et al., Securing Tomorrow, Today: Transitioning to Post-Quantum Cryptography (joint statement, November 2024).
• ANSSI, PQC transition in France.

← All resources · Home