Crypto Agility in Practice

What crypto agility means

Crypto agility is the capability to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations. In practice, this means that cryptographic choices are treated as governed, changeable components rather than permanent assumptions embedded throughout a system. The objective is not change for its own sake: an organization should be able to respond to a newly identified weakness, an algorithm or key-length transition, a protocol requirement, or the need to introduce PQC without causing uncontrolled outages or weakening protection.1

The scope is broader than a cryptographic library. Relevant dependencies can include network protocols, software libraries, cryptographic hardware, PKI and related infrastructure, applications and services, code-signing systems, user and machine authentication, email and document protection, and key-management processes. Applications may need changes to encryption, digital signatures, and key exchange; they may also need to accommodate different key sizes, performance characteristics, protocols, libraries, and user interfaces.12

Why crypto agility matters now

Crypto agility reduces dependence on cryptographic mechanisms that may become unsuitable over time. NIST SP 800-131A Rev. 2 distinguishes among acceptable, deprecated, and disallowed algorithm or key-length uses; the status can depend on the algorithm, key length, domain parameters, and mode of use. An agile program therefore needs a way to identify affected uses and change them under policy, rather than relying on undocumented, one-time upgrades.3

PQC is a major driver. The cited NIST draft states that no existing cryptographically relevant quantum computer currently threatens the cited security levels, but also notes that cryptographic migrations can take over a decade and that this more complex migration will likely take at least that long. The associated timing logic compares the time data must remain secure and the time required to complete migration with the expected time until a cryptographically relevant quantum computer. Consequently, organizations with long-lived sensitive data should not wait for a future threat event before beginning preparation.2

The risk is not limited to stored data. Systems that create or validate digital signatures, including software and firmware update mechanisms, can contain quantum-vulnerable cryptography. High-impact systems, industrial control systems, and data requiring long-term confidentiality or secrecy deserve particular attention. In OT environments, confidentiality may not always be the dominant concern for field data, while integrity of sensor readings and commands can be critical because faulty readings or commands can contribute to industrial-control failures.45

A practical operating model

Crypto agility is best managed as an ongoing security and engineering capability, not as a single migration project. Begin by assigning a project or governance team that can coordinate security, architecture, application engineering, infrastructure, procurement, OT, risk, and suppliers. Define migration and resilience goals in terms of robust cryptographic infrastructure and wider cyber-resilience objectives, while accounting for sector-specific risks and regulatory requirements.615

The work phases are related rather than perfectly linear. Discovery informs prioritization; prioritization shapes architecture and procurement; implementation generates new inventory data; testing and operational monitoring reveal exceptions; and lessons from each transition improve the next one. This feedback loop is important because older estates often contain cryptographic services that evolved over many years in inconsistent ways, making both discovery and mitigation more difficult.6154

1. Define the security, business, regulatory, and operational outcomes that the program must achieve.
2. Discover cryptographic use and record the systems, data, algorithms, keys, protocols, dependencies, owners, and suppliers involved.
3. Assess risk and prioritize high-impact, exposed, long-lived, difficult-to-replace, or integrity-critical uses.
4. Design changeable cryptographic interfaces, policy controls, configuration mechanisms, and transition paths.
5. Implement in controlled waves, with preimplementation evaluation, testing, training, and rollback or exception procedures.
6. Assure the result through production verification, metrics, governance reviews, and continued supplier and technology monitoring.

Discovery, inventory, and risk prioritization

A useful inventory starts with the current estate, not with a preferred algorithm. Identify key services and applications, the data held and its expected lifetime and value to an adversary, and how data is protected in transit and at rest. Map the systems through which the data is processed and establish processes for identifying and managing software and hardware assets effectively.54

The inventory should cover IT and OT systems and should use discovery techniques to identify quantum-vulnerable algorithms in network protocols, end-user systems and servers, applications and associated libraries, and the cryptographic functions embedded in those assets. It should also include digital-signature uses such as software and firmware updates, custom-built technologies, commercial products, and cloud dependencies. Each record should support ownership, criticality, data security life, exposure, current protection, dependencies, migration state, and an accountable decision-maker.4

Prioritization should be risk-based rather than based only on the number of instances. Consider the impact of compromise or outage, the sensitivity and expected security life of data, external exposure, the role of cryptography in authentication or integrity, the difficulty of changing the system, and its dependency on suppliers or obsolete platforms. Key-management guidance also identifies factors such as operating environment, personnel turnover, transaction volume, security life, algorithm-use limits, security function, rekeying method, and network scale as relevant to management decisions.46

Architecture and transition mechanisms

Agility depends on separating cryptographic policy and implementation choices from business logic wherever practical. Applications should use controlled cryptographic services or interfaces, explicit configuration, centrally governed policy, and versioned protocol behavior. This reduces the need to find and rewrite every business function when an algorithm, key size, library, or protocol changes. It does not remove the need for engineering: new algorithms can change key sizes, performance, message formats, storage requirements, and interoperability behavior.62

During a PQC transition, interoperability and backward compatibility are important to maintaining trust and security across the network. A hybrid key-establishment method or dual signatures may provide a transition path where appropriate. However, hybrid solutions add architectural and implementation complexity, which can increase security risks and costs. They should be selected only after analyzing application constraints, security requirements, performance, independent review needs, and the relevant standards and supplier support. They are typically expected to be temporary, leading to a later transition to tools using only PQC algorithms.2

Key management must evolve with the cryptographic design. NIST describes four key-management phases—preoperational, operational, post-operational, and destroyed—and emphasizes that metadata, such as the identity associated with a key and the information it is authorized to access, is crucial even though it is not part of the cryptographic algorithm. An agile design therefore needs lifecycle states, ownership, metadata, rekeying, revocation or retirement procedures, and evidence that applications select the intended key for the intended service.6

Implementation, testing, and assurance

A controlled implementation should include preimplementation evaluation, testing before deployment, training for people whose key-management or operational tasks change, and a managed transition. NIST warns that strong cryptography can still be poorly implemented and that security measures retained from the old system should be reviewed to ensure they remain effective after the change. Teams should therefore test not only algorithm correctness but also protocol negotiation, certificate and key handling, authorization, performance, error behavior, logging, recovery, and interactions with dependent systems.65

Testing must verify what is actually used in production. The cited migration guidance specifically cautions that once standardized PQC cipher suites are available for protocols such as TLS, organizations should check that systems use them rather than silently falling back to traditional cryptography. Assurance should include representative clients, services, hardware, firmware, network paths, cloud services, and failure conditions. Where a transition mechanism is temporary, define the evidence and decision criteria for removing legacy support instead of allowing it to become permanent by default.5

Operational teams need a way to detect configuration drift and newly introduced cryptographic dependencies. Inventory updates should be part of architecture review, procurement, software release, certificate and key-management operations, and incident response. Exceptions should have an owner, rationale, compensating controls where applicable, review date, and planned remediation. This turns agility into a repeatable control rather than a capability that exists only during a major migration.615

Suppliers, cloud services, and OT considerations

Commercial products, custom-built systems, and cloud services require different forms of engagement. Organizations should ask each relevant vendor or cloud service provider for its quantum-readiness roadmap, including when and how updates or upgrades will support PQC and the expected migration cost. For custom-built technology, especially older systems, the organization may need to migrate the technology itself or implement security upgrades that mitigate continued use of vulnerable cryptography.4

Treating PQC migration as an IT/OT modernization effort can align cryptographic work with planned replacement and maintenance. In industrial-control environments, OT and IT zones may be separated by a DMZ firewall, and remote logins over the internet require quantum-secure authentication. Wireless field devices and sensors introduce additional constraints; even where confidentiality is less demanding, integrity can be essential. Physical-infrastructure changes require significant planning and should, where possible, coincide with other maintenance and improvements.5

Supplier statements are not substitutes for verification. Vendor roadmaps may describe future support, while final implementation specifics for PQC algorithms may be incomplete in draft materials. Record the supplier commitment, supported versions, configuration dependencies, testing responsibility, lifecycle date, and evidence required before accepting the product as migrated. This is especially important where a service is externally hosted or where a supplier controls protocol behavior that the organization cannot directly inspect.5

Measures and practical next steps

Metrics should show both coverage and residual risk. A useful measure is the proportion of relevant applications, clients, services, protocols, devices, and data stores represented in the inventory. Other measures can track the proportion of prioritized uses remediated, the number and age of exceptions, the number of systems still dependent on quantum-vulnerable algorithms, supplier roadmap coverage, test pass rates, and the percentage of software clients using PQC where that deployment is in scope. Metrics should identify clients or services that are not using the intended protection so that remedial action can be targeted.615

• Appoint accountable leadership and establish a cross-functional crypto-agility or quantum-readiness team.
• Build and maintain a cryptographic inventory, including IT, OT, cloud, suppliers, software and firmware signing, protocols, libraries, hardware, and key-management dependencies.
• Classify data by sensitivity, exposure, integrity requirement, and expected security life; then prioritize high-impact, long-lived, and difficult-to-change systems.
• Review application and platform designs for hard-coded algorithms, inflexible certificates, protocol fallback, fixed-size assumptions, and unmanaged cryptographic dependencies.
• Engage product and cloud suppliers on PQC roadmaps, supported configurations, costs, upgrade paths, and evidence of interoperability.
• Pilot controlled changes in representative environments, test performance and fallback behavior, train operators, and document rollback or exception handling.
• Report migration coverage and residual risk to governance forums, and use the results to schedule the next remediation wave.

Conclusion

Crypto agility is an operational discipline for making cryptographic change safe, repeatable, and observable. Its practical foundation is an authoritative inventory, risk-based priorities, adaptable interfaces and lifecycle controls, disciplined supplier engagement, and testing that verifies real production behavior. PQC gives the program urgency, particularly for long-lived sensitive data and high-impact or integrity-critical systems, but the capability also prepares the enterprise for broader algorithm, key-length, protocol, and implementation changes. Start with discovery and governance, then improve the architecture and assurance process with every migration wave.1254