Quantum Readiness vs. Crypto-Agility
Quantum readiness and crypto-agility are commonly confused, but the difference is important.
Often, the terms quantum readiness and crypto-agility are used interchangeably. For many organizations, quantum migration is the reason to implement a crypto-agility program.
However, these two concepts are distinct. Quantum readiness is an organizational goal with implications for regulatory compliance and security. Crypto-agility, on the other hand, is a capability that makes quantum readiness far easier to achieve. Conflating the two can cause significant harm to the business.
What the Two Terms Mean
Quantum readiness and crypto-agility are related but distinct terms. The definitions:
Crypto-Agility: The ability to swap out cryptographic algorithms as needed without revising application code. Often achieved via abstracting away cryptographic code from application logic.
Quantum Readiness: Deployment of NIST-standardized post-quantum cryptographic algorithms. Intended to prepare for the arrival of cryptographically-relevant quantum computers (CRQCs) that can break classical asymmetric cryptography.
Quantum readiness refers to your organization's ability to protect itself against quantum computing. Crypto-agility is a property that measures how easy it is to achieve quantum readiness.
Why the Terms Are Commonly Conflated
An organization can pursue crypto-agility for various reasons. For example, the company might want to be able to rapidly respond to deprecated cryptographic algorithms or vulnerabilities in trusted cryptographic libraries.
However, the most common reason for organizations to pursue crypto-agility is for quantum migration. The advent of CRQCs is a major risk to system and data security, and companies have budget for crypto-agility programs because of security and compliance requirements around quantum migration.
The Four Potential Combinations
Crypto-agility and quantum readiness are related but not the same. Understanding the various combinations of the two helps to highlight where conflating the two can introduce planning and security gaps.
| Crypto-Agile | Not crypto-agile | |
|---|---|---|
| Quantum Ready | Ready for CRQCs and able to rapidly adapt as needed | Ready for CRQCs, but evolving standards or broken PQC algorithms require expensive changes |
| Not Quantum Ready | Cryptographic algorithms can be easily swapped, but PQC hasn't been deployed | Vulnerable to CRQCs and facing significant work to achieve this goal |
Most organizations are starting from a point of no crypto-agility and quantum readiness. Ideally, they'll reach the point of achieving both.
The problem arises when the two are conflated and an organization implements one but not the other. The two risks are:
PQC, Not CA: An organization that has deployed PQC but not in a crypto-agile way may incur significant costs if standards change or algorithms are broken. PQC algorithms are relatively untested, and it's likely that standards will change and new ones will be introduced, requiring further changes.
CA, Not PQC: A crypto-agile organization that isn't quantum-ready is in a better but not ideal position. This organization can easily change algorithms but hasn't implemented PQC yet. This can carry regulatory risk and introduces vulnerability to harvest now, decrypt later (HNDL) attacks.
Why the Difference Matters for Planning and Budgeting
Quantum migration is a high-priority project with a clear goal and end date. Various regulations (EO 14412, EU Roadmap, etc.) have imposed deadlines of 2030/2031 for organizations to adopt post-quantum encryption and digital signature algorithms. Even if these laws don't directly apply to an organization, market pressure and the HNDL threat make compliance a good idea.
In contrast, only NSM-10 explicitly requires an organization (US government agencies and critical infrastructure) to implement crypto-agility. While it's also useful for quantum migration, it's not explicitly required for most organizations. Additionally, crypto-agility is an ongoing process as organizations continue to ensure that new code using cryptographic algorithms is implemented in line with corporate policies.
This difference between drivers and timelines can significantly impact an organization's planning and budgeting efforts, especially if the two terms are conflated. Quantum migration has the urgency and regulatory pressure required to drive funding, while crypto-agility might be seen as a "nice to have" but not a requirement. Also, quantum migration has a clear end date (past which funds will likely no longer be required), while crypto-agility programs will continue for the foreseeable future.
Conflating the two becomes problematic if crypto-agility efforts fall apart after quantum migration is completed. If this is the case, the organization will be unprepared for updates to post-quantum algorithms requiring changes or a non-quantum cryptographic issue, such as a deprecated algorithm or vulnerable trusted library.
How to Tell Which One You Actually Need First
By now, most organizations should have a roadmap in place for quantum migration. With less than five years until the deadline, waiting too long risks the company starting too late to finish in time if the effort required is greater than expected.
Ideally, a crypto-agility program starts before or alongside quantum migration efforts. Preparing in advance makes it easier to swap in post-quantum algorithms when they become available, while implementing the two in tandem just means revising cryptographic code to be crypto-agile when the company is rewriting it anyway to be quantum-resistant.
To maximize the impact (and cost savings) of a crypto-agility program, organizations should start today or as soon as possible. Training developers on best practices, implementing automated code review rules, and ensuring that all new code is written in a crypto-agile way doesn't require a large up-front investment. However, it does ensure that the organization's crypto-agility posture doesn't degrade further over time even if existing code isn't immediately rewritten in-line with crypto-agile best practices.
Further Reading
EU Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography
FAQs
If we've completed PQC migration, are we crypto-agile?
No, PQC migration involves replacing classical public-key cryptography with post-quantum versions. This can be done in a non-crypto-agile way by hardcoding calls to these algorithms instead of the previous ones.
Can a vendor claim to be 'PQC-ready' without being crypto-agile?
Yes, the two terms are distinct. A PQC-ready organization has implemented quantum-resistant cryptographic algorithms, while crypto-agility means the ability to change these algorithms easily if needed.
Will NIST's standardized PQC algorithms ever change?
Yes, while NIST has standardized some PQC algorithms, they are likely to receive some updates. Also, NIST is in the midst of standardizing another post-quantum digital signature algorithm (FN-DSA), which has some benefits over existing standardized algorithms.