Skip to content
Encryptorium

PQC

Crypto agility: designing systems that survive broken cryptography

Andreas Renz · · 9 min read
PQC cryptography migration

Cryptography is often treated as a permanent foundation: something selected once during system design and rarely revisited. In practice, cryptography is one of the most time-sensitive components in any security architecture. Algorithms age, attacks improve, hardware evolves, and regulatory requirements change. What was considered secure ten years ago may be deprecated today and broken tomorrow.

MD5 was widely used for integrity checks until Wang et al. demonstrated practical collision generation in 2004, with more damaging certificate-forgery attacks following in subsequent years. SHA-1 persisted in TLS certificates until browser vendors forced deprecation in 2017. RC4 was the most widely deployed stream cipher in TLS until 2015, when RFC 7465 banned it. 1024-bit RSA was standard for key exchange until NIST deprecated it in SP 800-131A (2011, disallowed after 2013). In each case, organizations that had hard-coded these primitives faced costly, rushed remediation. Organizations that had built in the ability to swap algorithms migrated on their own schedule.

That ability is called crypto agility.

What crypto agility means in practice

Crypto agility is a system's ability to replace or upgrade cryptographic primitives, algorithms, or parameters without requiring a full redesign or causing operational disruption.

A crypto-agile system can:

  • Migrate from one algorithm to another (e.g., RSA-2048 to ML-KEM-768)
  • Support multiple algorithms simultaneously during a transition period
  • Rotate keys and parameters without downtime
  • Adapt to regulatory or threat-driven changes on a planned schedule
  • Deploy emergency cryptographic patches when a primitive is broken

This is not a theoretical requirement. RFC 7696 ("Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms") formalized the principle in 2015, recognizing that every cryptographic algorithm has a finite lifespan and protocols must be designed to accommodate replacement. NIST expanded on this in CSWP 39 ("Considerations for Achieving Cryptographic Agility," December 2025), which addresses operational mechanisms, challenges, and trade-offs in making crypto agility practical across organizations.

Why algorithms keep breaking

Cryptographic change is driven by three forces:

Cryptanalytic advances. New attacks weaken existing primitives. The Wang et al. (2004) collision attack on MD5 did not break it overnight; it made collision generation feasible, which undermined certificate integrity and forced a multi-year deprecation effort. Even partial breaks change risk models and accelerate migration timelines.

Hardware evolution. Increases in compute capacity, GPU acceleration, and ASICs erode security margins over time. NIST's IR 8547 (draft, November 2024) proposes deprecating RSA-2048 and ECC P-256 by 2030 and disallowing all classical public-key algorithms by 2035, anticipating that quantum computing will make them unsafe. The migration planning is no longer speculative; NIST's draft transition timeline already provides concrete target dates for deprecation and removal.

Regulatory and compliance requirements. Governments and standards bodies periodically mandate algorithm changes. The NSA's CNSA 2.0 (September 2022) requires quantum-resistant algorithms for national security systems by specific dates. NCSC UK published migration timelines in March 2025 targeting full PQC migration by 2035. PCI DSS and FedRAMP tie cryptographic expectations directly to NIST-validated modules and recognized standards. HIPAA treats encryption as an addressable safeguard rather than mandating specific algorithms, but its requirements still shift as NIST guidance evolves. ENISA has also published guidance on post-quantum preparedness for EU organizations.

Without crypto agility, each of these events becomes a crisis. With it, they become planned maintenance.

What crypto agility requires

Crypto agility is an architectural property, not a feature you add after the fact. It spans six areas.

Cryptographic observability

You cannot migrate what you cannot see.

Organizations need to know which algorithms are deployed, which key sizes are in use, and where deprecated primitives remain. This requires more than a manual audit. Automated discovery and analysis tools can generate cryptographic inventories using standardized formats like CycloneDX CBOM, which documents cryptographic assets across applications, infrastructure, and supply chain dependencies.

In readiness assessments, cryptographic inventory often deserves the highest weight because everything else depends on knowing what you have. The Encryptorium Post-Quantum Readiness Assessment allocates 20% to this domain for that reason.

Governance and policy

Algorithm decisions should be deliberate, not accidental. Organizations need:

  • An approved algorithm list that maps to current standards (NIST FIPS 203/204/205, CNSA 2.0)
  • Defined deprecation timelines that reference published guidance
  • Clear ownership of key management and cryptographic policy
  • Vendor cryptography requirements in procurement contracts

Without governance, individual teams make independent algorithm choices, and the organization discovers its cryptographic diversity only when migration is urgent.

Modular cryptographic architecture

The most important technical principle is decoupling cryptography from business logic.

Consider the difference between these two approaches to encrypting data at rest:

Hard-coded (not agile): The application calls AES-256-GCM directly, stores ciphertext with no algorithm metadata, and assumes the key format will never change. To switch algorithms, you rewrite the encryption code, write a migration script for all stored data, and coordinate deployment across every service that reads or writes the data.

Abstracted (agile): The application calls an encrypt(plaintext, policy) interface. The policy resolves to a specific algorithm and key version. Ciphertext is stored with a version header identifying the algorithm and key ID. To switch algorithms, you update the policy and the new algorithm applies to new data. Old data is readable because the version header tells the decryption path which algorithm to use.

The same principle applies to signing, key exchange, and hashing. TLS 1.3 is a protocol-level example of negotiated cryptographic agility: peers negotiate cipher suites, supported groups, and signature algorithms at connection time rather than assuming one fixed cryptographic choice.

Protocol-level adaptability

Even with modular application code, the protocols a system uses must support algorithm negotiation and coexistence. TLS 1.3 (RFC 8446) supports cipher suite negotiation. IKEv2, extended by RFC 9370, now supports multiple key exchanges in a single SA setup, enabling hybrid post-quantum/classical key agreement for VPNs. These protocol-level mechanisms allow phased migration without flag days.

Systems that use fixed cipher configurations, hard-coded certificate formats, or single-algorithm authentication cannot migrate safely even if their application code is modular.

Operational tooling

Crypto agility depends on operational maturity: certificate lifecycle management, key rotation automation, dependency scanning for cryptographic libraries, and configuration auditing. An organization that cannot enumerate its TLS certificate inventory will struggle to migrate those certificates to future post-quantum or hybrid PKI ecosystems.

Tools like certificate transparency logs, SBOM/CBOM generators, and cryptographic linters in CI/CD pipelines turn cryptographic posture from an invisible property into a measurable one.

Lifecycle management

Cryptography is not "set and forget." Mature organizations maintain algorithm rotation plans, incident response playbooks for cryptographic failures, scheduled key replacement cycles, and periodic architecture reviews. Crypto agility is sustainable only when it is treated as an ongoing process, not a one-time project.

Common anti-patterns

Several design choices that seem reasonable at implementation time sabotage future migration:

  • Hard-coded algorithm names in application code (e.g., SignatureAlgorithm.SHA256withRSA as a constant rather than a configuration value)
  • Fixed-size buffers tied to specific key lengths (e.g., a 32-byte field for ECDH public keys that cannot accommodate ML-KEM's 1,184-byte keys)
  • Implicit algorithm identifiers in stored data: ciphertext stored without metadata about which algorithm and key version produced it
  • Database schemas coupled to key formats: a BINARY(32) column for keys that becomes a migration blocker when key sizes change
  • Unversioned cryptographic metadata: no way to distinguish data encrypted with v1 keys from data encrypted with v2 keys

These shortcuts work fine until the first algorithm change. Then they become the most expensive technical debt in the system.

Crypto agility and the post-quantum transition

The strongest motivation for crypto agility today is the transition to post-quantum cryptography. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 proposes deprecating classical public-key algorithms by 2035. NCSC UK's migration timelines set 2028 as the deadline for completing discovery and planning.

The PQC migration will require changes that are qualitatively different from past algorithm upgrades:

  • Key sizes increase dramatically. An ML-KEM-768 public key is 1,184 bytes; an X25519 public key is 32 bytes. Systems with fixed-size key buffers, constrained packet formats, or database columns sized for classical keys will need structural changes.
  • Hybrid modes add complexity. The transition period will use hybrid key exchange (classical + PQC) to protect against both quantum and implementation risks. This means protocols must support carrying two key exchanges simultaneously.
  • Certificate formats change. Post-quantum and hybrid certificates are larger and are likely to require updates to PKI infrastructure, certificate storage, and parsing logic. How to incorporate post-quantum signatures into WebPKI while maintaining compatibility remains an open challenge.
  • Performance characteristics differ. ML-KEM key generation is fast, but ML-DSA signatures are larger than ECDSA. SLH-DSA is hash-based with no lattice assumptions but has significantly larger signatures. Systems need to be tested under realistic PQC workloads.

Organizations with crypto-agile architectures can absorb these changes incrementally. Organizations without them face a choice between a multi-year redesign and accepting unmanaged risk during the transition.

Where to start

If your systems were not designed with crypto agility in mind, the path forward is incremental:

Architecture. Introduce abstraction layers for cryptographic operations in new code. Store algorithm identifiers alongside keys and ciphertext. Version cryptographic data structures so old and new formats coexist.

Operations. Build a cryptographic inventory. Track algorithm usage across systems and dependencies. Automate certificate and key monitoring.

Governance. Define an approved algorithm baseline aligned to NIST and CNSA 2.0. Establish a deprecation policy with specific dates. Require vendor transparency on cryptographic dependencies.

Testing. Simulate an algorithm migration in staging. Run compatibility testing across protocol versions. Add cryptographic configuration checks to CI/CD pipelines.

None of these require a big-bang redesign. Each one makes the next migration, whatever it is, cheaper and less disruptive. For a practical starting point on inventory, see why every organization needs a CBOM.

References