What is crypto agility, and why does it matter for OT?

Crypto agility is the ability to replace or adapt the cryptographic algorithms in protocols, software, hardware and infrastructure without stopping the systems that depend on them. In OT and critical infrastructure, it decides whether the move to post-quantum cryptography means changing a configuration or ripping out equipment that was meant to run for another fifteen years.

This article explains what crypto agility means in practice and why long equipment lifecycles make it urgent. It also covers how to change algorithms without replacing hardware, how to build a cryptographic inventory, and how to decide which OT connections to migrate first.

What is crypto agility?

Crypto agility is the capability to swap cryptographic algorithms in a running system while keeping it secure and operational. NIST treats it as both a design property of products and a management capability of organizations.

The current reference text is NIST Cybersecurity White Paper 39. In its updated final version, 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. The white paper was updated as CSWP 39upd1 (Final) on 06/29/26.

NIST describes three levels of agility, and each one matters differently for OT:

• System level: the ability to adopt new cryptographic algorithms and stop the use of vulnerable algorithms in applications without disrupting the running system.
• Protocol level: the ability to maintain interoperability when introducing new cryptographic algorithms and preventing the use of vulnerable algorithms. For a link between a substation and a control centre, both ends must agree on the new algorithm at the same time.
• Enterprise level: a capacity to seamlessly and rapidly transition away from vulnerable cryptographic algorithms and adopt new, stronger ones without incurring significant changes to their infrastructure.

The important distinction is that post-quantum cryptography is a set of algorithms, while crypto agility is the ability to change algorithms. You need both. The first post-quantum key-establishment standard, ML-KEM, was published August 13, 2024 as FIPS 203. NIST considers it an approved alternative that is presently believed to be secure, even against adversaries in possession of a large-scale fault-tolerant quantum computer. “Presently believed” is the phrase that makes agility necessary.

Why does crypto agility matter for equipment that runs for years?

OT assets often stay in service for decades, so the algorithms built into them today will outlive the timelines regulators have set for retiring classical public-key cryptography. Without agility, every future algorithm change becomes a hardware project.

Three timelines collide in critical infrastructure.

The deprecation timeline is already published

Statistic (NIST IR 8547 initial public draft, November 2024): quantum-vulnerable algorithms such as RSA and ECDSA at 112-bit security strength are deprecated after 2030, disallowed after 2035.

Statistic (NSM-10, cited by NIST, 2024): US policy states that “The United States must prioritize the transition of cryptographic systems to quantum-resistant cryptography, with the goal of mitigating as much of the quantum risk as is feasible by 2035.”

A remote terminal unit or industrial router commissioned in 2026 with a 20-year design life will still be running well past both dates.

Migrations take longer than lifecycles suggest

The NCCoE warns that replacing cryptographic algorithms is technically and logistically hard: “It can take years or even decades to complete.” In OT, change windows are short, recertification is expensive, and many sites are unstaffed. A migration that needs physical access to every device will run into maintenance schedules long before it runs into budget limits.

The first post-quantum standard may not be the last

NIST has already picked a backup key-encapsulation algorithm. Dustin Moody, who heads NIST’s Post-Quantum Cryptography project, explained why: “it’s essential to have a fallback in case ML-KEM proves to be vulnerable.” For long-lived equipment, this means planning for at least one more algorithm change during the asset’s lifetime, not just a single switch to post-quantum.

How do you change encryption algorithms without replacing hardware?

Separate the cryptography from the equipment that needs protecting. Put it in a layer that can be updated through software, such as an encryption gateway at each end of a connection, so that field devices, PLCs and existing firewalls stay as they are.

NIST’s design guidance shows why many embedded devices can’t simply be patched. CSWP 39 notes that replacing an algorithm may also necessitate the replacement of hardware to incorporate new hardware accelerators. It also identifies resource limits as the most difficult challenge for achieving crypto agility. Post-quantum keys and ciphertexts are larger than their classical counterparts. A controller with fixed buffers and limited memory may not be able to handle them at all.

In practice, organizations use three approaches:

For the network-layer approach, check three properties:

• Hybrid key agreement. A classical and a post-quantum algorithm are combined into one session key, so the link stays protected if either one turns out weaker than expected. NIST notes that hybrid schemes increase protocol complexity and exercise the capability to accommodate many cipher suites, which is exactly why the design must assume algorithms will change.
• Algorithm-neutral design. NIST advises that the design should avoid making assumptions based on specific algorithms to ensure that buffers, memory, and storage can handle diverse cryptographic data. Ask vendors directly how a future algorithm change gets delivered and what it requires on site.
• No fallback to cleartext. When an algorithm is being renegotiated or a line fails, the connection should drop or retry, never carry unencrypted traffic.

As an example of this pattern, Quantum Network’s QPN gateway sits at each end of a site-to-site, edge-to-cloud or remote-access connection. It encrypts at Layer 3, combines a classical part with ML-KEM in a hybrid key agreement, and allows the post-quantum algorithm to be changed if necessary. No software is installed on the equipment behind it. Automatic algorithm and software updates depend on an active subscription. That dependency is worth recording in your own lifecycle planning for any agile product you choose.

How do you create a cryptographic inventory?

A cryptographic inventory records where public-key cryptography is used, which algorithms and key lengths are involved, what data they protect, and who can change them. For OT, it has to combine automated discovery with vendor engagement and manual review of devices that scanners can’t reach.

Federal guidance gives a usable structure. CISA’s initiative page notes that US guidance requires each federal agency to establish and maintain a current inventory of IT vulnerable to quantum decryption and establishes criteria for agencies to prioritize their inventory efforts. Private operators aren’t bound by OMB M-23-02, but its data items are a sound template.

Step 1: Assign ownership across IT and OT

The joint CISA, NSA and NIST factsheet recommends that the inventory be lead by an organization’s Information Technology (IT) and Operational Technology (OT) procurement experts. Procurement matters because, in OT, many cryptographic choices sit inside vendor firmware that the operator can’t see or change.

Step 2: Discover what is on the wire and in the boxes

Start with the network paths: site-to-site tunnels, links from OT to the cloud or data centre, vendor remote-access channels, and certificate-based authentication on engineering workstations. The NCCoE Migration to PQC project, documented in the NIST SP 1800-38 practice guide series, includes a demonstration focused on tools that discover where and how public key algorithms are being used.

Statistic (CISA, September 2024): CISA is a collaborator along with over 28 industry partners in the NIST National Cybersecurity Center of Excellence Migration to PQC project.

Be realistic about what tools find. CISA notes that it is not clear if these tools will be able to detect the embedded algorithms used within software packages. In OT, passive network observation, vendor documentation and direct questions to suppliers fill that gap. Active scanning of fragile controllers should only be done in agreement with operations.

Step 3: Record what each entry protects

For each entry, record the algorithm and key length, the protocol, the asset and location, the type of data, how long that data must stay confidential, whether the cryptography can be updated (and by whom), and the vendor’s post-quantum roadmap. The data-lifetime field is the one most inventories leave out, and it drives every prioritization decision that follows.

Step 4: Keep it alive

Tie inventory updates to change management: new firmware, new remote-access paths, new cloud connections. An inventory that is accurate once and then left alone loses its value within a year.

How do you prioritize post-quantum migration in OT?

Rank connections by how long their data must stay confidential, how exposed the path is, and how hard the cryptography is to change. Then protect the most exposed links first with an agile layer, and leave device-level changes to the normal refresh cycle.

Statistic (CISA, 2022): to help critical infrastructure partners prepare, CISA analyzed how each of the 55 NCFs is vulnerable to quantum computing capabilities. Use your own National Critical Function dependencies to decide which business processes matter most, then map them onto the inventory.

Two procurement decisions stop the problem from growing. First, CISA advises that where PQC-capable products are widely available, organizations should acquire only PQC-capable products when planning acquisitions and procuring products in these categories. Second, write crypto agility into OT tender requirements: how algorithms are updated, whether that works remotely, and how long the vendor commits to delivering updates.

Finally, measure progress against a maturity model rather than a single deadline. NIST’s CSWP 39 sketches tiers where, at the top level, crypto agility is monitored, measured, and reported to executives as part of the risk register and linked to financial, business, and mission objectives. For an OT operator, a realistic first goal is that every link crossing an untrusted network is inventoried and protected by encryption whose algorithms can be changed without a site visit.