What is cryptographic agility and why does it matter now?

Cryptographic agility is the ability to replace and adapt cryptographic algorithms in protocols, applications, software, hardware and infrastructure while keeping systems secure and running. It matters now because new post-quantum standards exist and every system that hard-codes an algorithm will eventually have to change.

What does NIST say?

NIST's white paper on the subject, CSWP 39, 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. It surveys current approaches, discusses challenges and trade-offs, and identifies working areas that need more thought. One detail to check: the NIST page for the original version, published 19 December 2025, now says it was withdrawn on 29 June 2026 and superseded by an updated version, CSWP 39upd1. Read the current version on NIST's site.

Why now?

NIST has been running a process to standardize quantum-resistant public key algorithms. NIST's project page says that if large scale quantum computers are ever built, they will be able to break many of the public key cryptosystems in use today. On 13 August 2024 NIST published FIPS 203, FIPS 204 and FIPS 205. FIPS 203 specifies ML-KEM, a key-encapsulation mechanism for establishing a shared secret key over a public channel, with three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. FIPS 204 and 205 cover digital signatures. NIST selected the HQC key-encapsulation mechanism for further standardization on 11 March 2025, and that process continues.

So the algorithms in use today are going to change, and the exact replacements are still settling. Agility is the response to a moving target.

Why is it hard?

Algorithms are embedded in many places: protocols such as TLS and IPsec, certificates, code signing, firmware, databases, hardware modules and third-party products. Some are fixed in silicon. Some are in software you do not control. Some have size limits: new algorithms often have larger keys or signatures, which can break fields, packets and storage assumptions that were sized for the old ones.

There is a trade-off. WireGuard, for example, deliberately fixes its primitives and has no negotiation, which simplifies the design and avoids downgrade attacks, but means changing algorithms needs a new protocol version. Negotiable protocols such as IPsec give flexibility but with more configuration to get wrong.

A constructed example

A company runs a payment API, mobile apps and an internal certificate authority. An inventory finds that the API's TLS settings are in a load balancer's configuration, so they can change in an afternoon. The mobile app pins a certificate and ships with a hard-coded signature check, so changes need an app release. The internal certificate authority issues certificates with a signature algorithm the vendor's firmware cannot replace. Without the inventory, the team would have planned only for the load balancer. With it, they put the app and the hardware vendor on the roadmap years before they become urgent.

What makes a system agile?

• Inventory. A list of every place cryptography is used, with algorithm, key size, owner and replacement difficulty.
• Configuration, not code. Algorithm choices set in config that can change without a rebuild.
• Abstraction. Application code calls a crypto library interface, not a specific algorithm.
• Versioning. Data and protocols carry an algorithm identifier so old and new can coexist during migration.
• Vendor commitments. Contracts and roadmaps that say how products will adopt new algorithms.
• Testing. A way to try new algorithms in a staging environment and measure size and performance effects.

How to check or apply this

1. Build a cryptographic inventory, starting with internet facing services, certificates, VPNs, code signing and data at rest.
2. Mark long lived secrets and data that must stay confidential for many years first, since those are most exposed to future attacks.
3. Rank each item by how hard it would be to change.
4. Ask each vendor for its post-quantum plan in writing.
5. Remove hard-coded algorithms from code you own, and put them behind configuration.
6. Test larger keys and signatures in staging.
7. Re-read NIST's current guidance each quarter, since the details are moving.

Software inventory is the first step for this. Dependency scanning and SBOMs help show which libraries supply your cryptography. Safeguard's dependency scanning can support that inventory work.

Quick check

Sources

• NIST CSWP 39, Considerations for Achieving Cryptographic Agility
• NIST, Post-Quantum Cryptography project
• NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
• WireGuard, Protocol and Cryptography

Last reviewed: 18 October 2026.