Crypto-Agility Guide: Designing Systems That Can Change Algorithms

Most organisations cannot change a cryptographic algorithm without rewriting code, replacing hardware or breaking a partner integration, and the post-quantum transition is about to make that weakness expensive. Crypto-agility is the engineering and operational capability to replace algorithms, key sizes and protocols across software, hardware, firmware and services while keeping security and operations intact. Past transitions show why it matters: moving from DES to AES took decades, and SHA-1 lingered long after collisions were demonstrated. This guide covers how to design agile systems, how to run an agility programme, how to measure crypto-agility debt and where it fails. It is written for architects, platform engineers and security teams who own cryptography in practice, not only on paper.

Key takeaways

• Agility is a property you build in, not a project you run once: algorithm identifiers, crypto APIs, central policy and an inventory let you swap algorithms in configuration rather than code.
• History says transitions take decades. NIST CSWP 39 records that the move from DES through Triple DES to AES took 23 years, so post-quantum deadlines of 2030 to 2035 leave no slack.
• Negotiation needs integrity. Supporting many algorithms only helps if an attacker cannot force the weakest one; downgrade protection and removing disallowed algorithms are part of agility.
• Hardware and long-lived keys are the hard limit. Algorithms burned into chips, TPMs, secure boot code and fixed firmware cannot be changed by policy, so they need the most conservative choices and a replacement plan.
• Operational agility matters as much as design. Key rotation that stops after one outage, as in the Storm-0558 case, is crypto-agility debt even when the algorithm is strong.

What crypto-agility means

NIST CSWP 39, Considerations for Achieving Cryptographic Agility, 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. The final paper was published on 19 December 2025 and NIST has since superseded it with an updated revision (CSWP 39 upd1, June 2026), so check the CSRC page for the current version before citing section numbers.

Agility operates at three layers, and an organisation needs all three:

• Protocol agility: the protocol carries algorithm identifiers and can negotiate new ones without a new protocol version (TLS 1.3 cipher suites and named groups, IKEv2 transform identifiers, X.509 algorithm OIDs, JOSE alg values).
• Implementation agility: applications call a cryptographic API or provider rather than a hard-coded algorithm, so the library, module or HSM can change underneath them.
• Operational agility: the organisation knows where cryptography is, can set policy centrally, can rotate keys and certificates automatically and can retire an algorithm on a planned date.

The fundamentals of algorithms and key types are covered in the Cryptography Basics Guide. This guide focuses on the ability to change them.

Why it matters now: lessons from past transitions

CSWP 39 opens with historic transitions because they show the real timescales. The table summarises the examples NIST gives.

The post-quantum transition compresses this. NIST IR 8547 (still an initial public draft, published 12 November 2024) proposes that 112-bit RSA, ECDSA and finite field and elliptic curve Diffie-Hellman be deprecated after 2030, and that all quantum-vulnerable public-key algorithms be disallowed after 2035. The replacement standards exist: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), all published on 13 August 2024, with HQC selected in March 2025 as a backup key encapsulation mechanism. Migration detail is in the Post-Quantum Cryptography Migration Guide; planning for the threat itself is in the Q-Day Planning Guide.

Design patterns for agile systems

Protocols

• Carry identifiers, not assumptions: every signed or encrypted object should state its algorithm and parameters (OIDs in X.509 and CMS, alg and enc in JOSE, named groups in TLS). Formats that imply the algorithm from a version number force a version change for every algorithm change.
• Keep the mandatory list in a companion document: CSWP 39 recommends specifying mandatory-to-implement algorithms separately from the base protocol so the list can be updated without rewriting the protocol.
• Protect the negotiation: the handshake transcript must be authenticated so an attacker in the middle cannot strip strong options (MITRE ATT&CK T1689 Downgrade Attack, often combined with T1557 Adversary-in-the-Middle). TLS 1.3 signs the transcript and includes downgrade sentinels; older protocols often did not.
• Plan for size: post-quantum objects are larger. CSWP 39 notes an ML-DSA signature of 2,420 bytes at roughly 128-bit classical strength, against 64 bytes for an ECDSA P-256 signature. Fixed-length fields, MTU assumptions and database column sizes break first.
• Remove what is disallowed: each algorithm left enabled is attack surface and test burden. Agility includes the ability to delete.

Implementations

• Call a crypto API or provider: application code asks for "sign with the service key" or "encrypt this record", and a library, provider (OpenSSL 3 providers, Java JCA/JCE, Windows CNG, PKCS#11) or KMS chooses the algorithm from configuration. CSWP 39 gives AES-GCM and AES-CCM as an example of algorithms that can present the same interface.
• Centralise defaults: system-wide crypto policies (for example the crypto-policies mechanism on RHEL-family Linux) or a shared internal library let one change reach thousands of services. OpenSSL 3.5.0 (8 April 2025) added ML-KEM, ML-DSA and SLH-DSA and made the hybrid group X25519MLKEM768 a default TLS keyshare, which shows how much a library upgrade can change without application code.
• Version your ciphertext and signatures: store an algorithm or key identifier with every encrypted record and token so old data can still be decrypted or verified after the default changes.
• Use a gateway where you cannot change the code: CSWP 39 describes crypto gateways ("bump-in-the-wire") that wrap legacy systems whose cryptography cannot be modified.
• Treat hardware as fixed: hardware functions, removable UICCs, non-removable TPMs and secure boot keys embedded in boot code generally cannot be updated. For long-lived devices choose the most conservative variants and plan for the full lifetime; FPGAs are the exception because they can be reconfigured.

Agile and brittle designs compared

Certificate automation is the single biggest operational lever, because every algorithm change in PKI becomes a mass re-issuance. See the Machine Identity, PKI and Certificate Lifecycle Guide and the Certificate Expiry Outages and 47-Day TLS Certificates Guide.

Hybrid algorithms: agility tool or extra debt

Hybrid schemes combine a classical and a post-quantum algorithm. For key establishment the derived key stays secure if either component holds; for signatures (dual or composite) every component must verify. The IETF published the TLS hybrid key exchange as RFC 10024 in August 2026, registering X25519MLKEM768 (0x11EC, recommended), SecP256r1MLKEM768 (0x11EB) and SecP384r1MLKEM1024 (0x11ED), and marking the pre-standard Kyber code points obsolete.

• Choose hybrid key exchange for data in transit now: it addresses harvest-now-decrypt-later exposure and is already default in major libraries.
• Be more cautious with hybrid signatures and certificates: NIST IR 8547 draft and CSWP 39 both describe hybrids as typically temporary, adding complexity and cost, and implying a second transition to PQC-only.
• Watch the pre-standard trap: systems that shipped draft Kyber code points now need another change. That is the cost of adopting before a standard is final without an agile update path.

Running a crypto-agility programme

1. Set ownership and policy. Name an owner for cryptographic policy (often the CISO's architecture function) and publish an approved-algorithm list with dates for deprecation and disallowance, aligned to NIST IR 8547 and your regulator. CSWP 39 recommends translating these decisions into machine-consumable configuration profiles.
2. Build the inventory. Discover algorithms, key sizes, libraries, certificates, protocols and keys across code, hosts, network traffic, HSMs and cloud KMS, and record them in an asset-centric inventory or CBOM. See the Cryptographic Inventory and CBOM Guide.
3. Score agility, not only strength. For each system record whether its algorithm is configurable, who can change it, how long a change takes and whether hardware blocks it. This is the crypto-agility debt register.
4. Fix the platforms first. Upgrade shared libraries, base images, service mesh, load balancers and the internal PKI so that many applications become agile at once.
5. Pilot each change in rings. Enable a new algorithm in log-only or "offer but do not require" mode, then a pilot ring, then production. For TLS, offer the hybrid group alongside the classical one and watch handshake failures from middleboxes and old clients.
6. Keep a tested rollback. Keep the previous policy profile versioned and deployable in minutes; for data at rest, keep old keys available for decryption only (CSWP 39 notes policy can block encryption with an algorithm while still permitting decryption).
7. Retire on a date. Disable deprecated algorithms by policy, then remove them from code and configuration. Track exceptions with an owner and expiry.
8. Repeat. CSWP 39 treats crypto risk management as a continuous cycle with KPIs, not a one-off migration.

Small and large organisations

• Small organisations: most cryptography arrives through cloud services, SaaS and operating system updates. Agility here means staying on supported versions, asking suppliers for their PQC roadmap and avoiding home-grown cryptography.
• Large organisations: need a central crypto policy service, an inventory feed into the CMDB, an internal PKI that can issue new key types and a standing crypto review in architecture governance.
• Product vendors: carry the biggest obligation, because customers inherit their agility. Ship configurable algorithms, signed updates for crypto code and published cryptographic component lists.

Where identity fits

Most cryptography in an organisation is attached to non-human identities: TLS and mTLS certificates for workloads, SSH keys, token signing keys for identity providers, code signing keys and API request signing. Agility for these means the ability to rotate keys and change algorithms without outages. The Microsoft Storm-0558 key breach shows the operational side: a consumer signing key created in 2016 should have been retired in 2021, but manual rotation stopped after an outage and the key stayed trusted until it was used to forge tokens in 2023. See the Post-Quantum Migration for NHIs Guide and the Cryptographic Key Management Guide.

Detection and measurement

Monitor what is actually negotiated and used, not what policy says:

• TLS telemetry: log the negotiated protocol version, cipher suite and key exchange group at load balancers, proxies and service mesh; alert on TLS 1.0/1.1, RSA key exchange and deprecated groups.
• Certificate and key inventory: track key types and sizes, signature algorithms and expiry across public and private CAs, HSMs and cloud KMS; alert on keys past their retirement date.
• Code and dependency scanning: flag direct calls to specific algorithms and vulnerable library versions in CI.
• Downgrade signals: handshake failures and fallbacks after a policy change can indicate middleboxes or active interference.

Framework mapping

Common failure patterns

• Agility on paper only: a policy lists approved algorithms, but nobody can say which systems use what, so the policy cannot be enforced. Inventory comes first.
• Rotation abandoned after an outage: a failed rotation leads teams to switch it off rather than fix it, and old keys stay trusted for years, as the Storm-0558 key breach showed.
• Keys and algorithms fixed in hardware: in the MSI signing keys leak, firmware signing keys for 57 products and Intel Boot Guard keys for 116 products were exposed, and reporting noted such keys cannot easily be revoked on devices already in use. Long-lived roots of trust need a designed replacement path.
• Too many options enabled: teams add new algorithms but never remove old ones, leaving downgrade paths and an untestable matrix.
• Verifiers that trust the token: accepting whatever algorithm a signed object declares, or checking the signature but not the issuer and scope, turns agility into an attack path.
• Early adoption without an exit: deploying pre-standard algorithms or code points with no way to update them creates a second migration.

Practitioner checklist

• Publish an approved-algorithm list with deprecation and disallowance dates aligned to NIST IR 8547 and your sector rules.
• Build and maintain a cryptographic inventory that records agility (configurable or fixed) as well as algorithm and key size.
• Require new code to use a shared crypto library, provider or KMS rather than calling algorithms directly.
• Store algorithm and key identifiers with every ciphertext, signature and token.
• Enable hybrid post-quantum key exchange (X25519MLKEM768) on external TLS endpoints after a pilot ring.
• Automate certificate and key rotation, and alert on any key past its retirement date.
• Keep the previous crypto policy profile versioned and test rollback before every change.
• Write crypto-agility and PQC roadmap requirements into supplier contracts and request cryptographic component lists.
• Identify devices with fixed cryptography or embedded roots of trust and set replacement dates.
• Track the six metrics above quarterly and report agility debt to risk owners.

Standards and references

• NIST: CSWP 39, Considerations for Achieving Cryptographic Agility
• NIST: IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards
• NIST: FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST: FIPS 204, Module-Lattice-Based Digital Signature Standard
• IETF: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLS 1.3 (RFC 10024)
• OpenSSL: OpenSSL 3.5 release notes
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Downgrade Attack

Related NHI Mgmt Group resources: Post-Quantum Cryptography Migration Guide · Cryptographic Inventory and CBOM Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Post-Quantum Readiness Guide · Q-Day Planning Guide