Crypto‑Agility Explained Preparing Cryptography for the Quantum Era

Crypto agility is one of those terms that sounds like it belongs in a technical architecture discussion rather than a boardroom.

But as the quantum threat moves from theoretical to operational, and as regulators begin requiring demonstrable cryptographic resilience, it has become one of the most strategically important concepts in post-quantum security planning.

The core idea is straightforward: a crypto-agile organisation can update, replace, or swap cryptographic algorithms quickly and safely, without redesigning the systems that depend on them.

In practice, very few organisations have built this capability. And that gap, more than anything else, is what makes post-quantum cryptography (PQC) migration so operationally complex.

This article explains what cryptographic agility means in practice, why so much existing infrastructure lacks it, and what security leaders need to do to build it – before the quantum deadline arrives.

For a broader introduction to the post-quantum landscape, see our Post-Quantum Cryptography guide.

Why cryptography must evolve faster than threats

Cryptographic standards have always had a shelf life. MD5 was once considered secure. SHA-1 is now deprecated. DES gave way to 3DES, then to AES.

The difference today is the pace and scale of what is coming.

The UK’s NCSC has set phased migration deadlines at 2028, 2031 and 2035. NIST published its first post-quantum standards – ML-KEM, ML-DSA and SLH-DSA – in August 2024. DORA, in force since January 2025, explicitly requires financial entities to demonstrate the ability to update cryptographic technology as cryptanalysis evolves.

These are not distant obligations. They are current operational requirements.

But the threat horizon is also shortening in ways that make waiting dangerous.

“Harvest now, decrypt later” attacks – where adversaries collect encrypted data today with the intention of decrypting it once quantum computers become capable – mean that data protected by current algorithms is already at risk.

Any information that must remain confidential for the next decade or more carries exposure right now: harvest now, decrypt later attacks are not waiting for the arrival of quantum computers.

For a deeper look at this threat and its implications, see our article on harvest now, decrypt later attacks.

Against this background, the ability to change cryptographic algorithms quickly is not a nice-to-have. It is a fundamental requirement of any credible PQC transition strategy.

An organisation that has not built crypto agility into its infrastructure will find that migration is not a straightforward swap – it is a system-by-system reconstruction exercise, carried out under time pressure, with regulatory scrutiny increasing throughout.

Why most infrastructure is not crypto-agile

To understand why crypto-agile infrastructure is rare, it helps to understand how cryptography has historically been implemented.

In most organisations, cryptographic algorithms are not treated as a configurable parameter. They are baked into systems at build time, embedded in libraries that were chosen years or decades ago, hardcoded into application logic, or inherited through third-party software with no upgrade path.

The team that originally selected an algorithm is often long gone. The documentation that would explain what depends on it has either never existed or been lost.

This is not negligence. It reflects how cryptography has always been treated: as infrastructure that, once deployed, does not need to be touched.

Until now, that assumption was largely correct. The algorithms in widespread use have been stable for long enough that treating them as permanent fixtures carried little obvious risk.

The quantum threat breaks that assumption.

And it exposes a structural problem that has been building quietly for years: most organisations have accumulated what practitioners are beginning to call “cryptographic debt” – a sprawling, undocumented estate of algorithms, certificates, keys and cryptographic libraries that no single team fully understands, and that was never designed to be changed at scale.

The result is that when an organisation tries to begin PQC migration, it faces a dependency problem as much as a technical one.

Replacing an algorithm affects every system, application and integration that depends on it. Without a complete map of those dependencies, migration cannot be safely sequenced.

Without safe sequencing, well-intentioned migrations cause outages.

How rigid encryption slows PQC migration

The relationship between cryptographic rigidity and migration speed is direct.

Organisations with hardcoded or undocumented cryptographic implementations face significantly longer migration timelines, higher costs and greater risk of disruption than those that have built flexibility into their cryptographic architecture.

This is not theoretical.

The challenge of cryptographic lifecycle management has become one of the most pressing operational problems facing security teams preparing for PQC, as it involves managing the full lifespan of keys, certificates, algorithms and protocols.

Several specific patterns make migration slower and riskier.

Hardcoded algorithm choices.

When an algorithm is specified directly in code rather than through a configuration layer, changing it requires locating every instance, testing each one independently and coordinating changes across teams and release cycles. In large estates, this can involve hundreds of separate interventions.

Third-party and supply chain dependencies.

Cryptographic choices made by SaaS vendors, APIs and managed service providers sit outside direct control. Where those vendors have not published PQC roadmaps, organisations face an information gap that can only be resolved through direct engagement, which itself takes time.

Shared cryptographic libraries with no version control.

Many organisations rely on shared libraries that are used by dozens of different applications. Updating one to a post-quantum algorithm can break others that depend on specific protocol behaviours. Without dependency mapping, the blast radius of a library update is unknowable in advance.

Legacy systems that cannot be updated remotely.

Hardware Security Modules (HSMs), IoT devices, embedded systems, and certain legacy applications cannot receive software updates in the way that modern cloud workloads can. Some will require physical replacement. These systems need to be identified early in any encryption migration strategy, because their lead times are measured in years, not sprints.

Each of these patterns reflects the same underlying problem: cryptography was not designed to be changed. Building crypto agility means redesigning the relationship between cryptographic choices and the systems that depend on them, so that the next algorithm change, whenever it comes, is a configuration update rather than a migration programme.