What Is Crypto-Agility? A Complete Guide

Crypto-agility is the ability to switch cryptographic algorithms as needed if algorithms are broken or otherwise require updates for compatibility. Organizations should be able to change algorithms, key lengths, and other features without the need to revise existing application code.

In general, this means abstracting away cryptographic code from the rest of an application's logic. If cryptography is implemented as a standalone module that an application calls to handle encryption, decryption, and digital signatures, it's much easier to change the cryptographic code than if this code were intermingled with application logic.

For decades, cryptography has been relatively stable, with the same algorithms being used relatively unchanged. However, the looming threat of quantum computing and the introduction of post-quantum cryptography (PQC) makes crypto-agility a priority for the modern business.

Why It Matters Now

Classical public key cryptography algorithms, such as RSA, Diffie-Hellman, and elliptic curve cryptography (ECC), will no longer be secure when cryptographically relevant quantum computers (CRQCs) become available. Shor's algorithm, which can be run on a large enough quantum computer, reduces the complexity of breaking these algorithms to polynomial complexity, making it infeasible to create secure, usable protocols based on the factoring and discrete logarithm problems.

While CRQCs aren't available today, they will be soon. While timelines vary somewhat, NIST plans to deprecate classical algorithms like RSA-2048 by 2030 and disallow them by 2035. Beyond the US government and its contractors, there is also growing regulatory pressure within the EU and US to make the change.

Even though several years remain before CRQCs are available, organizations are already at risk. Harvest now, decrypt later (HNDL) attacks involve collecting encrypted data now to decrypt when CRQCs are available. With that point only a few years away, data secured by vulnerable algorithms today may be exposed in the near future.

Crypto-agility is important because it eases the transition to PQC and any updates that may need to be made in the future. While standardized post-quantum algorithms exist, the strength of their resistance to quantum computing hasn't been proven, and future cryptanalytic efforts could undermine their security. Organizations should prepare to deploy hybrid cryptography (both classical and post-quantum algorithms) for the near future and to swap out or reconfigure algorithms if current PQC standards are updated.

Crypto-Agility vs. Related Terms

The term crypto-agility mostly comes up in the context of a migration to PQC because the threat of quantum computing makes crypto-agility necessary. Some important, related terms to know include:

PKI/Certificate Management: Public key infrastructure (PKI) and digital certificates are used to distribute trusted public keys for use in verifying websites, digital signatures, etc. The algorithms currently in use for this are generally classical ones that are vulnerable to Shor's algorithm and quantum computing. Modifications to PKI infrastructure and certificate management are a key element of a crypto-agility strategy.
Cryptographic Bill of Materials (CBOM): Software bills of materials (SBOMs) identify an application's use of third-party libraries and code. CBOMs do the same for the use of cryptography within an application. Building a CBOM is a key step toward crypto-agility since it identifies cryptographic code that must be decoupled from application logic.

Where Cryptographic Code Lives in an Organization

To be truly crypto-agile, an organization needs to be able to modify any of its cryptographic code as needed with minimal impact on application code or services. This cryptography is commonly scattered throughout the organization and includes:

Infrastructure and PKI: The Internet and corporate intranets both rely on cryptography for data encryption and digital signatures. PKI, TLS ciphersuites, and database encryption are examples of areas where the organization needs the ability to change algorithms without breaking things.
Applications and Code: Many applications incorporate cryptographic code to protect sensitive data from exposure or perform authentication via digital signatures. An organization's codebase may include many invocations to cryptographic libraries that play an important role in application logic and security.
Third-Party Software and Dependencies: Most companies use third-party software that uses cryptography, and developers commonly call external libraries to implement cryptographic functionality. These external uses of cryptography are part of the organization's cryptographic risk surface and should be managed as part of a crypto-agility program.

What a Crypto-Agile Organization Looks Like

Crypto-agility is a process, not a one-time effort. Organizations need to embrace its principles for all new code, as well as updating existing applications. Some of the key traits of a truly crypto-agile organization include:

Full, regularly updated CBOM
Cryptography implemented as replaceable modules, not hardcoded
Cryptographic functionality accessed via APIs and interfaces, not direct calls to cryptographic functions
Centralized management of cryptographic algorithms, keys, and configurations
Planned transitions to implement PQC or algorithm updates
Clear ownership of cryptographic code

NIST's PQC standards are expected to change. While digital signature standards exist (FIPS 204 and 205), new ones are in the works, and any algorithm could be broken. If changes are needed, a crypto-agile organization can make a few changes to the crypto module and roll out an update with minimal impact on deployed applications. An organization without crypto-agility will need to find and fix the cryptographic code in every app using it, a much larger lift.

Common Failure Points

Historically, organizations haven't really needed crypto-agility since algorithms in current use today have been secure and trusted for years. However, this is changing. Some of the common failure points for organizations looking to implement crypto-agility include:

Hardcoded Algorithms: Often, developers who need cryptographic functionality will import the relevant libraries and call them directly. This makes swapping out algorithms more difficult (since there are many places to check) and can have cascading impacts. For example, the assumption that a cryptographic key will be a certain length (e.g. 256 bytes for RSA 2048) is no longer correct as companies adopt PQC algorithms with keys 4-8x longer.
Undocumented Cryptography Usage: The ease of implementing cryptography within an application can also result in organizations lacking visibility into their cryptography usage. This lack of an inventory can be problematic since the company doesn't know what needs fixing if an algorithm is broken or requires updates. An up-to-date, complete CBOM is needed for a properly prioritized and comprehensive swap of cryptographic algorithms.
Vendor and Library Lock-In: Not all cryptography that an organization uses is under its control. Cryptographic code is complex and fragile, so developers commonly use libraries to ensure that they get it right. Vendors and suppliers may implement encryption or digital signatures in their products. Just because an organization adopts crypto-agile principles doesn't mean that their supply chains will follow suit.

How to Start Becoming Crypto-Agile

Achieving crypto-agility is an ongoing process as any new piece of software or code has the potential to introduce hardcoded or insecure cryptography into the organization. The following steps outline how an organization can start the process of implementing crypto-agile principles and best practices.

Inventory

Implementing crypto-agile practices involves understanding where cryptographic code can live within an organization. The first step of the process includes building a comprehensive CBOM that identifies the cryptographic algorithms in use and associated parameters (key length, etc.)

This inventory should include all potential cryptographic code in the organization, including internal code, third-party libraries and dependencies, and vendor software. Discovery should be automated and, ideally, built into CI/CD pipelines to ensure that new cryptographic code is identified and the CBOM is automatically updated.

Assess

A CBOM identifies the presence of cryptographic code within the organization. It doesn't necessarily determine whether that code is properly modularized or hardcoded into an application.

During the assessment step, each use of cryptography should be analyzed for its level of crypto-agility. This includes modularity, the ability to change the algorithm as needed, and the downstream effects of doing so. For example, changing a key length from 256 bytes to a longer value might break application logic if keys are stored in variables locked to this size.

Architect

Crypto-agility means decoupling application and cryptographic logic. Ideally, this should be implemented using APIs and interfaces that abstract away the details of the cryptographic code that an application uses.

In this stage, the APIs are designed to meet the needs of the business, defining required algorithms/capabilities and the related abstractions. Ideally, cryptographic APIs should be centralized to minimize the effort required to implement any updates needed in the future.

Prioritize

Imposing crypto-agile best practices on existing code can be a major job. If cryptography is hard-coded within application code, apps will need to be rewritten to use the cryptographic APIs instead.

At this stage, the team should prioritize the list of legacy applications that require changes. This should be based on risk, considering factors like data sensitivity, public-facing exposure, and any relevant compliance deadlines.

Migrate

The migration stage is focused on transitioning legacy systems over to the crypto-agile design. Any new use of cryptography should automatically use the cryptographic APIs and crypto-agile design principles.

This migration should be based on the priorities defined in the previous stage. These priorities should be regularly reassessed in case new assets added to the inventory or other factors change the relevant risk levels.

Govern

Governance is a critical component of a corporate crypto-agility strategy. Without oversight, policies, and clear ownership, it's easy to backslide.

A governance program should support crypto-agility principles at all levels of the organization. This includes everything from training developers on best practices to gaining executive buy-in by demonstrating the business benefits of crypto-agility for post-quantum migration.

FAQs

Is crypto-agility the same as post-quantum readiness?

No, crypto-agility refers to the ability to easily modify or swap out cryptographic algorithms as needed, while post-quantum readiness is the use of quantum-resistant public key cryptography. Organizations can be crypto-agile without implementing post-quantum cryptography (PQC) or implement PQC by hardcoding cryptography into application code (without being crypto-agile).

How long does it take to become crypto-agile?

Crypto-agility is an ongoing process, and the timeline can depend on various factors. For example, an organization with a large codebase and limited visibility into its use of cryptography will take longer to transition.

Do I need new tools, or just process changes?

Both, typically. Adopting crypto-agility involves various process changes, such as modularizing cryptography, maintaining a cryptographic inventory, and prioritizing changes to legacy code. Implementing this often requires new tools, such as scanners to identify the use of cryptographic code within a codebase.