The term "crypto agility" appears in procurement documents, vendor briefings, and RFP responses with a frequency that has outpaced its precision. In most vendor usage, it means "our product supports multiple algorithms." That is not what NIST means by the term, and the gap between the two definitions has material consequences for how organisations design their post-quantum migration programmes.
NIST Cybersecurity White Paper 29 (CSWP 29, initial public draft, June 2024) . the primary NIST document defining crypto agility . frames it as a risk management property, not a product feature. A system is crypto-agile when cryptographic algorithms, key sizes, or parameters can be replaced without architectural changes. In a crypto-agile system, the algorithm is a configuration parameter. The system does not need to be redesigned when algorithms are deprecated or replaced. The distinction matters because a system that supports ML-KEM (NIST FIPS 203, August 2024) today but requires a full redeployment to switch from ML-KEM-768 to ML-KEM-1024 is not crypto-agile in the NIST sense. It is post-quantum-capable for one specific configuration.
Why This Distinction Matters Now
NIST completed its first post-quantum cryptography standards round in August 2024, publishing ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). That is the beginning of the standardisation story, not the end. NIST's Round 4 alternate candidates . BIKE and HQC, both code-based key encapsulation mechanisms . are still under evaluation and may yield additional KEM standards. A separate NIST project is evaluating additional digital signature schemes. FN-DSA (FIPS 206, based on FALCON) was finalised in August 2024 alongside the main three algorithms.
An organisation that hard-codes ML-KEM into protocol implementations today, without crypto-agile abstraction, faces another re-implementation cycle when the next standard arrives. The PQC transition is not a one-time migration event. It is the beginning of a sustained cryptographic evolution. Each transition cycle costs less in a crypto-agile architecture than in a non-agile one . that is where the value of the property accrues. But it accrues on the second and subsequent transitions. Getting to a crypto-agile state requires doing the first migration properly.
There is a longer historical pattern here. MD5 was deprecated. SHA-1 was deprecated. 3DES followed. In each case, organisations that had built algorithm abstraction into their protocol stacks absorbed the transition as a configuration change. Organisations that had not rebuilt from scratch. The PQC transition is larger than any of those, but the architectural lesson has not changed. NIST SP 800-131A Rev. 2 (March 2019), which established the acceptable/deprecated/disallowed framework for algorithm transition, has been followed now by NIST IR 8547 (Initial Public Draft, November 2024), which applies that same framework to the post-quantum era. SP 800-131A set the deprecation precedent; IR 8547 executes it for RSA and ECC, targeting deprecation from federal use by 2030.
What Crypto-Agile Architecture Actually Requires
Implementing crypto agility requires abstraction at three distinct layers. Each has its own technical requirements and its own common failure mode.
Layer 1: Algorithm negotiation
Protocols must support algorithm advertisement and negotiation between communicating parties. TLS 1.3 (RFC 8446, August 2018) is the canonical model: cipher suite negotiation allows client and server to advertise supported algorithm lists and agree on the strongest mutually supported option. Adding an ML-KEM-768 plus X25519 hybrid key exchange group . following IETF draft-ietf-tls-hybrid-design (2024) . requires updating the server configuration to offer the hybrid group. The TLS implementation itself does not need rewriting.
The counter-example is instructive. SSH is multi-algorithm but not structurally agile. OpenSSH 9.0 (April 2022) added support for a hybrid sntrup761 key exchange. OpenSSH 9.9 (September 2024) added ML-KEM-768 hybrid support following FIPS 203 finalisation. Each extension required explicit code addition and a new release. A proprietary protocol that calls encrypt_with_ECDH(data) rather than encrypt(data, algorithm=config.algorithm) has the same structural problem as old versions of SSH: adding a new algorithm means touching code, not configuration. When you audit vendor products, "supports ML-KEM" is not the right question. The right question is: is the algorithm a parameter or a dependency?
IETF RFC 7696 (BCP 201, November 2015), "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms," defines the criteria for crypto agility in IETF protocol design: algorithm identifiers must be negotiable; the default algorithm must not be the only allowed algorithm; the protocol must support algorithm upgrade without version incompatibility. These criteria are now the standard for new IETF protocol design. Older protocols that predate RFC 7696 may not meet them, and that gap belongs on the inventory.
Layer 2: Key management
Key management systems . HSMs, key management services, and certificate authorities . must support post-quantum algorithm key generation and management. An HSM that cannot generate ML-KEM-1024 key pairs, or a CA that cannot issue ML-DSA-87 certificates, is a cryptographic bottleneck regardless of how agile the protocol stacks above it are. Crypto agility at the protocol layer is blocked at the key management layer.
PKCS#11 v3.0 (OASIS, 2020) added post-quantum algorithm identifiers . the specification basis for hardware support. But hardware firmware update availability, NIST FIPS 140-3 certification status, and feature timing vary significantly by product line across major HSM vendors. Major HSM vendors have published post-quantum roadmaps, but PQC support availability and FIPS 140-3 certification status vary significantly by product line and firmware version. Verify current PQC support directly with your HSM vendor before assuming agility extends to the hardware layer. A crypto-agile architecture assessment that does not include an explicit HSM audit has not assessed the binding constraint.
Certificate authority infrastructure introduces a second key management gate. X.509 certificates require Object Identifiers (OIDs) for public key algorithms. ML-DSA and ML-KEM OIDs were registered following FIPS 203/204/205 finalisation. IETF draft profiles for ML-DSA certificates (draft-ietf-lamps-dilithium-certificates, 2024) and ML-KEM certificates (draft-ietf-lamps-kyber-certificates, 2024) define the certificate issuance requirements. Certificate authorities cannot issue post-quantum certificates until these profiles are deployed in their issuance infrastructure . and many enterprise CA deployments are running versions that predate those profiles.
Layer 3: Algorithm policy
A crypto-agile system is only as well-governed as its algorithm policy layer. A system that will negotiate any algorithm on request . including deprecated or broken ones . is not well-governed. It is a vector for downgrade attacks. The algorithm policy layer specifies which algorithm families are acceptable, for which use cases, at which security levels. It is consumed systematically by all protocol stacks and applications. This is what NIST SP 800-131A achieves at the regulatory level; crypto-agile architecture implements it operationally.
QSECDEF's Algorithm Sunset Timer provides a consolidated view of when each algorithm transitions from acceptable to deprecated to disallowed across NIST, NSA, and ETSI timelines. That is the policy reference the algorithm negotiation layer needs . without it, the negotiation layer has no authoritative basis for rejecting deprecated algorithm proposals.
Our tools are designed as directional tools only. Advice and standards are changing rapidly and although we update tools as new information is periodically released they are not designed as a replacement for expert advice. If your organisation results show high-priority exposure the next step is to contact our team or speak to a qualified expert member.
What Crypto Agility Does Not Solve
This section carries more weight than the previous one, because the failure mode is believing it carries less.
It does not eliminate migration work
Crypto agility reduces the cost of future algorithm transitions after a crypto-agile architecture is in place. Getting to that architecture requires the same inventory, programme governance, and migration execution as any PQC migration. The benefit accrues on the second and subsequent transitions. The vendor framing that "crypto agility means you're future-proof" conflates the destination . a crypto-agile architecture . with the journey to it. NIST CSWP 29 and ETSI TR 103 619 V1.1.1 ("Migration Strategies for Quantum-safe Cryptography," 2021) both make this explicit. Buying a crypto-agile product does not mean your estate is agile. It means you have acquired a component that can participate in a crypto-agile architecture once that architecture is designed and implemented across the organisation.
It does not protect against HNDL
HNDL . Harvest Now, Decrypt Later . is the practice of collecting encrypted traffic today for decryption when a CRQC arrives. A crypto-agile system that has not yet migrated its TLS sessions to post-quantum algorithms remains exposed to HNDL on exactly the same terms as a non-agile system. Agility accelerates migration; it does not retroactively protect data that has already been captured and stored. For the full evidence base on HNDL exposure, see the HNDL in Motion article. The exposure question is live regardless of architectural decisions made today.
It does not make algorithm selection automatic
A crypto-agile system that accepts any algorithm is not a secure system . it is an agnostic one. The algorithm policy layer is a separate and necessary component. Without it, agility creates downgrade risk. The NIST PQC Algorithm Selector maps use cases and security requirements to appropriate FIPS 203/204/205 parameter sets. That is the input for the policy layer . specifying which algorithms are acceptable for which purposes at what security levels. Crypto-agile architecture and algorithm policy are complements. Neither substitutes for the other.
It does not extend to embedded and OT systems
This is the limit most security architects underweight when briefing boards. Crypto agility as described above applies to software-configurable systems: protocol stacks, application services, cloud infrastructure, managed devices. It does not apply to IoT devices, industrial controllers, medical devices, automotive ECUs, and other hardware where cryptographic implementations are hardcoded at the firmware level.
These systems are structurally non-agile. Algorithm transitions require firmware updates or physical replacement, not configuration changes. NIST SP 800-82 Rev. 3 (2023) addresses OT security specifically. ETSI EN 303 645 (2020) establishes the IoT security baseline. Neither standard makes the OT/IoT migration problem go away . they define the responsible framework for managing it. For organisations with substantial embedded or OT estates, a parallel programme is needed that tracks hardware replacement cycles and vendor firmware roadmaps, not software configuration timelines. A CISO whose estate includes ICS/SCADA environments should not leave a crypto agility briefing believing the concept applies uniformly. It applies to the software-configurable portion. For the rest, the programme is a hardware programme.
I have seen this gap surface late in PQC programmes, when the OT estate . which was implicitly assumed to be covered by the software migration tracks . turns out to have a ten-year hardware replacement cycle and firmware that has not been updated since installation. At that point, the governance response is damage limitation, not architecture. The time to establish the OT programme track is at programme initiation, not after the software migration is complete.
Building for Crypto Agility: The Practical Starting Point
The honest recommendation is not to retrofit crypto agility into every existing system. That is an architecture programme that will compete with the migration programme for resources and timeline.
The practical approach is phased. For new systems and systems undergoing significant refactoring: build the three abstraction layers into the design. Algorithm negotiation via IETF-standard mechanisms, key management via PKCS#11 v3.0-capable infrastructure, algorithm policy expressed in configuration and consumed systematically. For existing systems in mid-life: assess whether the cost of retrofitting agility is justified by the expected residual life. A risk assessment that scores data longevity, regulatory obligation, and legacy complexity provides the prioritisation argument for that decision. For legacy and embedded systems: accept that they are structurally non-agile and plan their migration as a hardware replacement programme with its own timeline.
None of this is achievable without knowing what algorithms your estate is running. Crypto-agile or not, the algorithm policy layer cannot be built without the inventory that tells you which algorithms are in use, in which systems, protecting which data. The starting point is the same as it is for any PQC migration programme: the cryptographic inventory. The architecture decisions follow from that data.
Discuss your results with a QSECDEF expert member. A directional assessment is the starting point, not the programme. If your results show high-priority exposure, the next step is a discussion about a structured migration programme with defined milestones. Request a consultation with our team or find a qualified expert member.
