What Does Crypto Agility Actually Mean in Practice?

Crypto agility, also written as cryptographic agility, is the ability to change cryptographic algorithms, key sizes and parameters across an estate without re-engineering the systems that depend on them.

The practical test is simple. If replacing an algorithm would require a project, you do not have it. If it can be done through configuration and controlled rollout, you do.

The term appears throughout vendor marketing, government guidance and industry frameworks, positioned as both the goal and the means of a successful post-quantum transition. Despite that ubiquity it remains poorly understood in practical terms. For many organisations it exists as an aspiration rather than a defined capability, and vendors present it as something their products deliver out of the box.

The reality is considerably more involved. This article sets out what crypto agility actually requires, how to assess where you stand, and what a platform can and cannot do for you.

Why crypto agility matters now

It helps to look at the history of cryptographic change. RSA was described by Rivest, Shamir and Adleman in 1977 and has protected the integrity, authenticity and confidentiality of information for decades. For most of that period the underlying algorithms remained stable. Organisations could implement them, embed them into systems, and reasonably expect them to remain effective for years without fundamental change.

It would be natural to assume the post-quantum transition follows a similar pattern: migrate once to quantum-resistant algorithms, then enjoy a comparable period of stability.

The quantum era is different. Quantum computing will continue to advance, and over time even today's quantum-resistant algorithms may be challenged. Cryptographic research does not stand still, and the possibility that new weaknesses will be found in the recently standardised algorithms cannot be ruled out — NIST has acknowledged this by continuing to evaluate additional candidates beyond the initial approved set.

Crypto agility is therefore not a one-off transformation but an ongoing responsibility, much like maintaining security patches or updating threat detection. Organisations that treat post-quantum migration as a destination rather than a capability will find themselves back at square one when the next algorithm change arrives.

The four requirements of crypto agility

Achieving it requires four capabilities working together. None are trivial, and collectively they represent a significant shift in how most organisations manage cryptography.

1. Visibility of the cryptographic estate

You cannot change what you cannot find. Before any of the following is possible, you need to know which algorithms and key lengths are in use, where they sit, and which systems depend on them.

Most organisations have no structured view of this. Cryptography is embedded in applications, operating systems, network devices and cloud services, frequently without central documentation. A Cryptographic Bill of Materials provides that inventory, mapping every algorithm, certificate, key and library to the systems depending on them. Our guide to building a cryptographic inventory covers where to start.

2. Consolidated and modernised PKI

In many enterprises PKI has evolved organically over years or decades, producing fragmented, inconsistent and poorly documented implementations. Multiple certificate authorities operate across business units, each with different policies, configurations and levels of oversight.

Agility requires bringing these under centralised control, with consistent cryptographic policy that can be updated and enforced across the estate. A hierarchy designed for a different organisation constrains what can be changed, and that constraint surfaces at precisely the moment you need to move quickly.

3. Cryptographic operations decoupled from applications

This is the hardest requirement and the one most often skipped.

In many organisations, encryption routines, certificate handling, key management and signature verification are built directly into application logic. That tight coupling means changing an algorithm requires changing every application using it — expensive, slow and operationally risky at scale.

The alternative is abstraction. Cryptographic operations exposed as standardised services and APIs that applications consume rather than implement. Centralising the function allows algorithms, key sizes and parameters to change at the service layer without touching every consuming application.

This is the architectural change that actually delivers agility, and it is the one no product can do for you.

4. Automated certificate lifecycle management

When an organisation manages thousands or hundreds of thousands of certificates, the ability to issue, renew, revoke and replace at speed is essential. An algorithm change means reissuing every affected certificate, and manual processes cannot absorb that.

Automation is not optional here; it is a prerequisite. Certificate lifecycle management is what turns a migration from a programme into an operation, and the same capability is already required by shortening certificate lifetimes regardless of post-quantum considerations.

And a design principle running through all four

New systems should be designed so that algorithms, key sizes and parameters can be changed through configuration rather than source-code rewrites. That is a design philosophy embedded into architecture governance and procurement standards, not a technical control.

Every new system, application or device entering the estate should be evaluated for its ability to support cryptographic change without re-engineering. Adding that question to procurement costs nothing today and avoids the most expensive category of remediation later.

Underneath all of this sits encryption key security. Understanding how keys are generated, stored and rotated is a prerequisite to managing them at the speed and scale genuine agility demands.

A crypto agility maturity assessment

Organisations frequently ask where they stand. These five levels are a practical way to place yourself, and each is defined by what you could actually do rather than what you have bought.

Level 1: Unknown

No inventory of cryptographic assets. Algorithms and key lengths in use are unknown. An instruction to replace an algorithm could not be scoped, let alone costed.

Level 2: Visible

An inventory exists covering the major systems, with algorithms, key lengths and owners recorded. You could produce a list of affected systems if an algorithm were deprecated tomorrow, though the inventory needs manual effort to keep current.

Level 3: Managed

Discovery is continuous rather than periodic. PKI is consolidated under consistent policy, certificate lifecycle management is automated for the majority of the estate, and you know which systems could not be changed if required.

Level 4: Agile

Cryptographic operations are abstracted from applications for the significant majority of the estate. Algorithm and key length changes are configuration changes, applied centrally and rolled out in a controlled way. Procurement standards require crypto-agility in new systems.

Level 5: Sustained

Agility is maintained as business as usual. There is named ownership, a defined review cycle for algorithms and profiles, and the capability survives staff changes and budget cycles. Algorithm rollout resembles security patching rather than a programme.

Most organisations we assess sit between levels 1 and 2. The gap between level 2 and level 3 is largely tooling and process. The gap between 3 and 4 is architectural, and it is where most of the cost and time sits.

Is there such a thing as a crypto agility platform?

People search for crypto agility platforms and crypto agility solutions, which is a reasonable thing to look for. The honest answer is that platforms provide part of the capability and cannot provide the rest.

What a platform can do

• Discovery and inventory. Automated scanning across networks, certificate authorities, cloud services and configuration to build and maintain the cryptographic picture.
• Certificate lifecycle automation. Issuance, renewal, deployment and revocation at scale, which is what makes mass reissuance feasible.
• Policy enforcement. Applying consistent algorithm, key length and profile standards at the point of issuance, so drift does not reintroduce what you have just removed.
• Reporting. Evidence of coverage and progress, which matters for both governance and audit.
• Algorithm support. The ability to issue certificates using post-quantum algorithms, and increasingly hybrid constructions.

What a platform cannot do

• Decouple cryptography from your applications. If an algorithm is hardcoded in application logic, no external platform can change it. That is development work in your codebase.
• Reach systems it cannot integrate with. Operational technology, embedded devices and appliances with no enrolment support remain outside the automated estate regardless of what the platform claims.
• Fix a hierarchy that constrains you. If the PKI design cannot support the segregation or algorithm parallelism you need, managing it better does not resolve that.
• Create ownership. The most common reason agility programmes stall is that nobody owns the cryptographic estate. Tooling does not solve an accountability gap.
• Change procurement standards. Ensuring new systems arrive crypto-agile is a governance change, not a technical one.

So a platform is necessary and insufficient. It handles levels 2 and 3 of the maturity model well. Level 4 is architecture and level 5 is governance, and neither is purchasable.

This distinction matters for investment planning. Organisations that equate crypto agility with platform procurement will underestimate the scope of work and risk discovering — as many did during cloud and big data transitions — that the technology investment was a fraction of the total cost. We have written on why post-quantum must not repeat those mistakes separately.

Questions worth asking a vendor

• Which post-quantum algorithms are supported, and is that generally available or on a roadmap?
• Does it support hybrid certificates, and in which model?
• What proportion of a typical estate does your discovery actually reach, and where does it not?
• Can it distinguish which algorithms a system supports from which it actually negotiates?
• What does the performance look like with post-quantum keys and signatures under production load, rather than in a benchmark?

That last one matters more than it sounds. Support and performance are separate questions, and post-quantum keys and signatures are substantially larger than their classical equivalents.

A shift in design philosophy

At its core, crypto agility requires a change in how organisations think about cryptography within their estates. Rather than treating it as a fixed, embedded component of each system, it needs to be treated as a managed, centralised service that evolves independently of the applications depending on it.

This is analogous to architectural shifts enterprises have already navigated. Organisations moved from monolithic applications to microservices, and from local identity management to centralised identity platforms. The cryptographic layer needs the same treatment: extracted, centralised and governed as a distinct capability.

The benefit extends well beyond post-quantum. Organisations that achieve genuine agility are better positioned to respond to any future cryptographic challenge — a newly discovered weakness in an existing algorithm, a change in regulatory requirement, or an entirely new class of threat. The investment pays across multiple scenarios, not just the quantum one.

From transformation to business as usual

Implemented well, the ongoing rollout of new cryptographic algorithms can eventually become as routine as security patching. Getting to that state is not a business-as-usual exercise. It requires deliberate transformation of PKI architecture, application design, certificate management and governance.

PKI underpins almost every digital interaction across an enterprise, usually invisibly. Every application call to a network or cloud service, every device authentication, every encrypted transfer and even communication between components inside a corporate network relies on certificates. All of it will ultimately need to support quantum-resilient algorithms and the ability to adopt future changes efficiently.

The scale of that dependency is precisely why crypto agility cannot be treated as a technical project. It is an enterprise capability that must be planned, funded and governed at a strategic level, with clear ownership and sustained investment across multiple programme cycles. That is the argument for treating post-quantum as a business transformation rather than an algorithm swap.

Common pitfalls

Underestimating cryptographic dependency

Most organisations significantly underestimate how many systems, applications and processes depend on cryptographic services. Without a comprehensive understanding of where cryptography is used, efforts to centralise and modernise will miss critical dependencies — and those tend to surface late, during delivery, when they are most expensive.

Treating it as a project rather than a capability

Achieving the initial transformation matters, but maintaining agility requires sustained investment in tooling, skills and governance. Organisations that declare victory after the initial migration and reduce investment will gradually lose what they built.

Failing to secure executive sponsorship

Crypto agility touches every part of the technology estate and requires changes to procurement standards, architecture governance and application design practice. Without visible, sustained support from senior leadership, cross-cutting changes of that kind are difficult to drive and easy to deprioritise.

Buying the platform first

The sequencing error. A platform bought before the estate is understood is a platform configured against assumptions. Discovery and assessment first, then selection against actual requirements.

How Unsung approaches crypto agility

We help organisations move beyond the term and build genuine cryptographic agility. We work across PKI consolidation, certificate lifecycle management and architectural design to assess your current landscape, identify where dependencies are tightly coupled and develop a practical roadmap.

Our approach recognises that agility is not achieved through a platform purchase. It requires coordinated change across architecture, governance and operations, sustained over time. We help organisations plan for that reality, ensuring cryptographic flexibility is built into the foundations rather than bolted on afterwards.

A PKI health check establishes where you sit against the maturity model above, and our PKI consultancy practice delivers the coordinated changes that follow.

The decisions you make now about PKI architecture and cryptographic management will determine your ability to adapt for years to come. Talk to our team about where to start.

Want to explore this topic further?

This blog is part of a series drawn from our strategic whitepaper, Post-Quantum Cryptography: A Strategic Whitepaper for the C-Suite. It provides vendor-neutral, business-focused guidance on navigating the quantum era — covering the threats already in play, lessons from previous hype cycles, and practical steps your organisation can take today. Download your copy here: https://2f4v3l.share-eu1.hsforms.com/20qJjHSynQkuJKhI_xq9Msg