Designing For Crypto-Agility

Post-quantum migration will not be the last time organisations have to change cryptographic algorithms. New attacks will appear, parameter sets will be revised and some first-generation post-quantum deployments may themselves need replacing. Systems that make every change a major project will keep paying that cost.

Crypto-agility is the design goal that reduces it. This article explains NIST’s definition, the concrete practices US federal guidance now expects, and the common habits that work against agility.

What Crypto-Agility Means

In NIST’s terms, crypto-agility is about being able to swap one cryptographic algorithm for another, or adjust how it is used, wherever it appears, from a network protocol down to a chip’s firmware, without weakening security or stopping the service.¹ NIST’s white paper on the subject, CSWP 39, was first published on 19 December 2025 and replaced by an updated version, CSWP 39 upd1, on 29 June 2026.¹

A practical test: if a weakness were announced tomorrow in an algorithm you rely on, how many systems could switch by changing settings, and how many would need new code or new hardware?

The starting point is not encouraging. NIST’s National Cybersecurity Center of Excellence observes that almost all information systems lack crypto-agility: few were built with the expectation that their algorithms would ever need replacing.²

The Practices OMB Expects

OMB’s memorandum M-26-15 makes agility a requirement for US federal agencies. It requires agencies to ensure all systems are cryptographically agile during its prioritised and signature migration phases.³ Its technical appendix says agility takes more than avoiding hard-coded algorithm names, and lists four practices.³

1. Use libraries designed for agility. OMB’s examples are OpenSSL 3.x, where algorithms come from add-on “providers” that a configuration file can switch between, and Java’s cryptography architecture (JCA/JCE), which works on the same plug-in principle.
2. Drive algorithm choice from configuration. Which algorithm or hybrid scheme a service uses should live in a settings file that operators control. If it is compiled into the program, every change means a new release.
3. Negotiate algorithms in protocols. When both ends can state what they support, they can agree on a post-quantum option as soon as both have one, and drop old options later. OMB adds that devices must be able to restrict the list to approved algorithms, so an attacker cannot force a weaker choice (a downgrade attack).
4. Make key management agile too. Key management services and hardware security modules (HSMs) need to handle elliptic curve keys and post-quantum keys side by side, with native support for the new algorithms rather than workarounds.

Before And After

Europol’s financial services report names hard-coded credentials, defaults and cryptographic parameters as an antipattern, and recommends scanning code for them before deployment, applying the same checks to existing code, moving keys into protected key management systems and moving parameters into configuration.⁴ It describes these as no-regret actions: they improve security today and make the post-quantum change easier later.

Agility Has Limits

Agility moves the hard part rather than removing it. A system that can switch algorithms by configuration still needs every component it talks to, and every device that verifies its signatures, to support the new choice. The NCCoE points out that some components stay in service for a decade or more, giving electricity generation and distribution as an example.² For those, agility is best specified at purchase time, because adding it later is expensive at best and impossible where the trusted keys or algorithms are fixed in hardware.

Negotiation also brings its own risk. If both old and new algorithms remain enabled indefinitely, an attacker may be able to push a connection back to the weaker option. OMB’s point about restricting endpoints to acceptable algorithms addresses this.³ Agility should include a plan for switching old options off, not only for adding new ones.

Building Agility Into Everyday Decisions

Agility is easier to build in than to retrofit, so it belongs in normal engineering and buying decisions. In the zero trust section of its technical appendix, OMB says secure development practices must require post-quantum-agile libraries for all new applications.³ Its sample roles give the programme office, or whoever owns requirements, the job of making sure vendor requirements include crypto-agility as well as post-quantum readiness.³

In practice that means a few standing questions. Can this product change algorithms through configuration? Does it record which algorithms it negotiated, so you can tell when an old option is no longer used? Can its keys move into your key management system? A supplier who cannot answer these today may still be the right choice, but the gap should be recorded in the inventory and revisited at renewal.