Executive summary
Cryptographic agility is emerging as a foundational requirement for sustainable PQC compliance. This approach enables security teams to swap algorithms quickly without disrupting systems. Because algorithm transitions have historically taken decades, organizations need hybrid cryptography, a decoupled architecture, and a cryptographic bill of materials (CBOM) to manage PQC migration without repeating the same disruptive process for every future transition.
The looming threat of quantum computing has created an urgent need to transition to post-quantum cryptography (PQC). Traditionally, cryptographic transitions have unfolded over decades, and the public-key algorithms that have secured digital communications and devices have been tested through years of real-world use. PQC algorithms haven’t had that same runway. However, organizations can’t afford to defer PQC migration until every implementation and dependency is fully in place.
Cryptographic migrations are typically expensive, time-consuming, and disruptive. Yet PQC migration guidance, requirements, and implementations are still maturing. The scale and current fluidity of the migration process raise the question: How do you commit to a complex, expensive, multi-year effort when things are still evolving?
Cryptographic agility allows you to update or replace algorithms as standards develop and requirements change, without the need for “rip and replace.” While the practice of cryptographic agility is not new, it’s a critical capability for maintaining quantum-resistant security and reducing risk in the PQC era.
What is cryptographic agility?
The National Institute of Standards and Technology (NIST) describes cryptographic agility as “the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, libraries, software, hardware, firmware, and infrastructures while preserving security and ongoing operations.” Essentially, crypto-agility enables organizations to migrate to new algorithms with minimal changes to code, configurations, or hardware.
Previous cryptographic transitions have demonstrated how slow this process can be and why crypto-agility is necessary. A good example is SHA-1, one of the most commonly used hashing algorithms of the late ‘90s and 2010s.
The research showing that SHA-1 is vulnerable to collision attacks — where attackers can create two different inputs that produce the same SHA-1 hash — first surfaced in 2005. But NIST didn’t begin restricting SHA-1 until 2011, and it took until 2022 to announce its full retirement, with the full phase-out not arriving until the end of 2030.
One of the reasons it took until 2011 to restrict SHA-1 was that at the time it was still difficult to carry out collision attacks. But backward compatibility, interoperability, and embedded legacy dependencies were also major contributors to a prolonged transition, according to NIST. Organizations still needed to verify legacy signatures, process previously protected information, and maintain connectivity with systems that had not yet adopted newer hash algorithms.
PQC migration has similar issues. But the scale is larger because many widely used cryptographic algorithms, not just one, need to be replaced within a limited time window. Organizations without built-in agility can face exactly this kind of drawn-out, disruptive timeline whenever an algorithm needs to be replaced.
Hybrid cryptography: practical application of crypto-agility
Cryptographic agility is not a single technique, and can encompass architecture, governance, and migration approaches. For PQC migration, multiple standards and security authorities, including NIST and the European Union Agency for Cybersecurity (ENISA), recommend a hybrid implementation.
A hybrid scheme combines a traditional algorithm with a PQC algorithm. Since PQC algorithms haven’t had the decades of scrutiny that classical algorithms have, hybrid schemes allows you to continue relying on well-tested traditional cryptography while the newer algorithms and their implementations mature. The idea is that if one algorithm has a newly discovered flaw, the system remains secure as long as the other algorithm holds.
Let’s say you configure two VPN gateways to use a hybrid IKEv2/IPsec exchange. The gateways use their existing methods to establish a shared encryption key, as well as ML-KEM — a post-quantum method — to add a second layer of protection when creating that key. The secrets produced by both methods are combined to create the encryption keys that protect data traveling through the VPN tunnel. The VPN’s encrypted traffic remains secure even if one of the methods fails.
A hybrid deployment allows you to reduce the risk of PQC migration because you can add protection against the quantum risk before you’re able to safely retire classical cryptography. It also gives you a longer transition runway when it’s not yet practical to use only PQC algorithms.
From an operational standpoint, hybrid deployment better enables a phased PQC migration based on your prioritized risks. Since you don’t have to change every application, connection, and vendor system at the same time, you’re also reducing the disruption to operations.
While hybrid schemes help avoid the need for a “rip-and-replace” approach, it may not be right for every organization. A 2026 Ponemon survey found that organizations are almost evenly split on their approach to the PQC transition: 36% plan a hybrid strategy, 35% will implement pure PQC, and 25% haven’t decided.
For those choosing the hybrid path, a complete move to PQC is still the end goal. Hybrid cryptography is designed to serve as a temporary bridge that enables security teams to begin migration while PQC implementations mature.
What a crypto-agile architecture looks like
A cryptographically agile architecture has three connected layers:
- Design principles that separate cryptography from application logic
- Technical components that allow algorithms and providers to be replaced
- Governance that directs, inventories, and manages those changes across the organization
At the system level, an agile design relies on crypto abstraction and modularity. You’re separating cryptographic logic from application code and making it easy to replace the components, rather than hardcoding a specific algorithm into every piece of software that uses it.
The technical layer contains the parts that must change when cryptographic policy changes. These may include algorithms and the software or services that provide them, protocol and connection settings, keys and certificates, and any specialized hardware or firmware used in cryptographic operations. For every component, you need a defined way to identify, replace, validate, and retire it.
Without governance, different teams may make conflicting decisions about what should change and when. NIST frames governance as a defined cryptographic policy that names an accountable owner, specifies which algorithms are approved, and gets communicated to IT teams, business partners, and vendors alike. The policy also needs to account for outside pressure such as regulatory mandates and industry standards.
Implementing a cryptographic bill of materials
A cryptographic bill of materials (CBOM) helps turn policy into an actionable migration plan. CBOM is an emerging extension of a software bill of materials (SBOM), an established practice in the software supply chain and a common requirement in federal software procurement.
Similar to how an SBOM provides a structured inventory of the software components and dependencies used to build an application, a CBOM does the same for cryptographic assets and dependencies. The CBOM can link the assets and dependencies to system owners, business criticality, compliance status, approved exceptions, remediation deadlines, and evidence of retirement. It’s an effective way to prioritize changes, assign accountability, track progress, and verify that legacy cryptography has been retired.
A CBOM also speeds up response when a cryptographic weakness emerges. By querying it to find which components are affected, you can quickly route remediation to the component owners.
Making the PQC transition sustainable
PQC migration is not a one-time project. Cryptographic agility enables the ongoing capability to manage cryptographic change. It minimizes disruption every time an algorithm needs to be replaced due to new standards, vulnerabilities, or policy requirements.
Agility also requires knowing your cryptographic posture in the first place — and tracking it continuously. Ciphersound’s free tool, Cipherscan, gives you the starting point for getting visibility into what you’re running across your systems. And if any of this raises questions specific to your environment, Ciphersound’s engineers are available to talk through it.