Insider Brief
- The article explains why cryptographic agility is becoming a key requirement for organizations preparing for post-quantum cryptography migration and future algorithm changes.
- Crypto-agile systems allow organizations to replace cryptographic algorithms through adaptable architectures rather than disruptive infrastructure replacements.
- The article outlines practical approaches to crypto-agility, including cryptographic inventories, algorithm negotiation, abstraction layers, hybrid deployments, and automated certificate management.
The post-quantum conversation has focused heavily on which algorithms to adopt, but algorithm selection is the second problem, not the first.
The real challenge lies in developing the system’s ability to adapt itself to the adoption of new algorithms – all within years and without a massive disruptive replacement project, without breaking dependent systems and without the kind of disruptive changes that most organizations simply can’t afford. That is what cryptographic agility means, as was explained in TQI before .
What Crypto-Agility Means
NIST defines crypto-agility as the “capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations.”
In other words, a crypto-agile system can swap out its cryptographic components without requiring the surrounding architecture to be rebuilt.
A system that is not crypto-agile has the opposite property. The algorithm is hard-coded into the application, baked into firmware, embedded in hardware security modules, or assumed by dependent protocols in ways that make it effectively permanent. Replacing it requires replacing the system or accepting a period where known-broken cryptography remains in production because nothing else will work.
NIST’s CSWP 39 states the stake very directly – “This transition will certainly not be the last one required. Future cryptographic uses will demand new strategies and mechanisms to enable smooth transitions. As a result, crypto agility is a key practice that should be adopted at all levels, from algorithms to enterprise architectures.”
Why Most Systems are not Crypto-Agile
Most systems were not designed to be crypto-agile. Cryptography has historically been treated as settled infrastructure – chosen once, deployed, and left in place for the life of the system. “Set it and forget it” for a decade or more.
That approach is defensible when the threat environment is stable and algorithm lifespans are measured in decades, but it breaks down when either of those conditions changes – and interestingly, both have changed.
Hard-coded algorithms appear throughout enterprise infrastructure – in TLS implementations where the cipher suite is fixed, in certificate authorities where signing algorithms are embedded in hardware security modules with limited upgrade paths, in firmware for IoT devices that cannot be updated over the air, in legacy applications where cryptographic libraries are statically compiled rather than dynamically loaded.
The issue becomes more complicated in the context of a supply chain.
An organization may have replaced its own hard-coded dependencies while still relying on vendors, cloud providers, or hardware manufacturers whose products embed obsolete algorithms several layers down. As TQI’s analysis of quantum’s practical implications notes , legacy devices in finance, IoT, and manufacturing often rely on traditional cryptographic methods with long lifecycles that make upgrades challenging – and many organizations lack full visibility into where cryptography is used across their systems, which makes it impossible to know what needs to change until something breaks.
Why this isn’t Only a Quantum Problem
Quantum computing is the current driver of post-quantum migration urgency, and for good reason. But crypto-agility is not a quantum-specific concern. It is the correct architecture for any system that needs to remain secure across an uncertain future – which is every system.
SHA-1 illustrates the pattern perfectly. Researchers identified theoretical weaknesses in SHA-1 as early as 2005 . NIST deprecated it in 2011 and disallowed it for digital signatures in 2013. Major browsers dropped support in 2017. Microsoft dropped it from Windows Update in 2020. NIST’s final deadline for full removal is 2030. That is a 25-year arc from known weakness to complete phase-out – because the systems using SHA-1 were not built to change.
The SHA-1 to SHA-2 migration caused significant operational disruption. Windows XP systems without Service Pack 3 had no SHA-2 support. Organizations running SHA-1-signed certificates on internet-facing services faced user-facing errors that required emergency remediation.The cost was the accumulated technical debt from a decade of treating cryptography as permanent.
The post-quantum cryptography migration is on a larger scale than the migration away from SHA-1, in that all the public key cryptosystems have to be changed at the same time rather than just one hashing algorithm. Those organizations without cryptographic agility in place face a similar situation, but on a much larger scale.
What Crypto-Agility Looks Like in Practice
Palo Alto Networks’ guidance on cryptographic agility describes a communication protocol that can negotiate between classical and post-quantum algorithms during handshake, allowing endpoints to select the strongest mutually supported encryption method without code changes. That is modular, adaptive security – the algorithm selection is abstracted away from the application logic.
The architecture principles behind this are not complicated, though the implementation work can be substantial:
Abstraction Layers Between Applications and Cryptographic Primitives
Applications should call a cryptographic service or library through a stable API, not implement cryptographic operations directly. When the underlying algorithm changes, the application does not need to change with it.
Algorithm Negotiation in Protocols
Rather than embedding a fixed cipher suite into a system, protocols should support negotiation – both parties agree on the strongest algorithm they both support. This is already the model in TLS; the challenge is applying it to systems that predate that design philosophy.
Cryptographic Inventory
As TQI has covered in depth , the starting point is knowing where cryptography is used. A Cryptographic Bill of Materials (CBOM) maps every algorithm, key size, and protocol dependency across a system’s surface. Without this map, migration planning is guesswork.
Hybrid Deployments During Transitions
Rather than replacing classical algorithms all at once, crypto-agile systems can run both classical and post-quantum algorithms simultaneously. NIST’s project work on SP 1800-38 demonstrated hybrid certificate formats containing both a classical and a post-quantum signature – compatible with older systems while introducing PQC. Hybrid deployment buys time without creating the security gap of a delayed migration.
Automated Certificate Lifecycle Management
Manual processes for certificate rotation, key renewal, and algorithm updates do not scale to the volume of changes that post-quantum migration requires. Organizations that have built automated certificate management infrastructure face a substantially easier migration than those relying on manual processes. For a view of the vendor landscape building these capabilities, TQI’s guide to 25 companies in quantum cryptography and communications covers the commercial ecosystem from QKD providers to post-quantum software specialists.
The Regulatory Reality
Crypto-agility has moved from architecture best practice to compliance expectation. NIST CSWP 39 formalizes guidance on achieving it. NIST IR 8547 sets the timeline framework for algorithm deprecation. The Cyber Resilience Act in the EU is widely interpreted by analysts as requiring systems to support cryptographic updates over time – making crypto-agility a de facto requirement for compliance in European markets.
For organizations in regulated sectors, this means crypto-agility is not optional architecture. It is what auditors will eventually look for. FS-ISAC has published specific guidance on building cryptographic agility in financial services , and ATIS has produced a strategic framework for telecommunications.
The Real Lesson From Post-Quantum Migration
Post-quantum migration is the immediate pressure, but the underlying lesson applies beyond it. Cryptographic standards will continue to evolve. New vulnerabilities will emerge in algorithms assumed to be secure. Computing capabilities – both classical and quantum, will continue to advance. Any system designed around the assumption that its current cryptographic choices are permanent will face the same remediation cost again.
As clearly mentioned by NIST’s in CSWP 39 “The impact of this transition will be much larger in scale than previous transitions because all public-key algorithms will need to be replaced rather than just a single algorithm. Also, this transition will certainly not be the last one required.”
Organizations which will be able to migrate in post-quantum phase with reasonable costs will be the ones which have developed systems which are able to adapt their algorithms whenever needed. Such capability isn’t developed during a migration process; it’s done prior to it.
For readers looking to go deeper, TQI’s coverage of why RSA and ECC are being replaced , what the major players have committed to on post-quantum timelines , and cryptographic inventory challenges in post-quantum transitions provides useful context.