State of Crypto Agility

Scope, date, and evidence method

This article is a dated desk review of the cited primary-source passages and source metadata. The cited source set includes current or final publications from NIST, CISA, NSA, the UK National Cyber Security Centre, and the OWASP Foundation. It also includes one NIST AI Risk Management Framework source, which is used only as a comparison for risk-management structure, not as evidence of cryptographic adoption. Source dates and statuses are preserved rather than normalized: for example, the NIST PQC overview is marked current and published on 2024-08-13; the joint CISA, NSA, and NIST fact sheet is final and dated 2023-08-17; NIST CSWP 39 Update 1 is final, published 2025-12-19, and updated 2026-06-29; and the NCSC migration guidance is current and dated 2025-03-20.13

The method is qualitative synthesis. Statements are separated into observations—what the cited passages explicitly say—and inferences—what follows reasonably for planning. No cited passage reports a representative survey of organizations, a measured global maturity baseline, a quantified market share, or a completed migration rate. Accordingly, this review quantifies only figures explicitly present in the evidence, such as the 82 algorithms assessed by NIST, the 25 countries represented in that account, the 69 candidate algorithms submitted by the deadline, and the three principal PQC standards released in 2024.5

What crypto agility means in practice

NIST defines cryptographic, or 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. This definition makes agility broader than selecting a new cipher or signature scheme. It concerns the surrounding mechanisms that allow a change to be governed, implemented, tested, deployed, monitored, and eventually completed without unacceptable disruption.1

The practical implication is that cryptography should be treated as an operational dependency rather than an invisible implementation detail. The NCSC identifies older systems whose cryptographic services evolved over many years in sometimes haphazard ways; that complexity can make discovery and mitigation more difficult. It also describes PQC migration as an opportunity to simplify an estate and reduce other cybersecurity risks. The latter is an inference about potential benefit, not evidence that every migration will reduce risk or cost.6

Why crypto agility is now linked to quantum readiness

The cited NIST material describes a future cryptographically relevant quantum computer as a potential threat to widely used cryptographic systems. It explains that post-quantum algorithms are intended to address both general encryption and digital signatures, including confidentiality and identity authentication use cases. The evidence does not establish when such a machine will exist; the NIST project passage describes the machines as potentially years or decades away.52

The joint CISA, NSA, and NIST fact sheet gives a reason to prepare before that uncertainty is resolved: adversaries could target data today that will still require protection in the future, an approach described as “harvest now, decrypt later.” It urges organizations to create quantum-readiness roadmaps, conduct inventories and risk assessments, and engage vendors. This is guidance to prepare, not evidence that a particular organization has already done so.3

NIST’s account of the standardization effort provides context for the transition. It says NIST assessed 82 algorithms from 25 countries, identified 15 leading candidates, and described a multiyear, open evaluation process. A separate NIST project passage states that the principal three PQC standards were released in 2024 and that additional standards are being developed as backups or alternatives.5

Standards are available, but transition remains a systems problem

The cited NIST project evidence identifies the first three final standards as FIPS 203 for ML-KEM, a module-lattice-based key-encapsulation mechanism; FIPS 204 for ML-DSA, a module-lattice-based digital-signature standard; and FIPS 205 for SLH-DSA, a stateless hash-based digital-signature standard. NIST says these standards should be put into use now and expects them to provide the foundation for most deployments, while evaluation of additional candidates continues.2

The same evidence says that under the transition timeline in NIST IR 8547, NIST will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning much earlier. This is a statement about the cited NIST standards transition, not a claim that every organization, system, or jurisdiction has the same deadline.2

The NCSC cautions that most systems will not move in one simple event. Except for very simple systems, traditional public-key cryptography and PQC will likely coexist for a period. New systems may need to support traditional algorithms as an option during migration, and organizations should define criteria for ending that support. The guidance also says that a system will not provide quantum-secure authentication until PKI migration is complete and traditional certificates have expired or been revoked.6

This produces a central distinction: standards availability is an observation; organizational readiness is an implementation condition. A standard can exist while an organization still lacks inventory data, compatible protocols, supplier support, tested implementations, certificate lifecycle controls, or a safe rollback and assurance process. That conclusion is an inference from the dependencies and testing requirements described by the cited guidance.63

The evidence-supported starting point: inventory and prioritization

The joint fact sheet recommends a cryptographic inventory that provides visibility into how an organization uses cryptography in IT and operational-technology systems. It says the inventory should identify quantum-vulnerable algorithms and associate them with data criticality so the organization can begin risk assessment and prioritize migration. It also recommends involving procurement experts, cybersecurity and privacy risk managers, and supply-chain vendors.3

The NCSC is explicit that an initial exercise is not intended to be a formal asset register. At this stage, understanding the nature of each system matters more than recording every individual item. Nevertheless, organizations should quantify system scale where possible, capture version and patch information, and identify dependencies between components and services. This combination of breadth and increasing detail supports a staged discovery process rather than waiting for a perfect inventory before acting.6

The systems in scope are wider than servers and applications. The cited NCSC passage names software applications; networking and communications hardware; managed mobile devices; servers and workstations; IoT and industrial-control devices with communications functions; end-user devices and tokens; and field-installed devices and sensors. The joint fact sheet additionally points to network protocols, end-user systems and servers, applications, and associated libraries.63

Prioritization should consider high-impact systems, industrial-control systems, and data with long-term confidentiality or secrecy requirements. Custom-built products, particularly older ones, may require the most effort; commercial off-the-shelf products require vendor engagement about roadmaps, updates, upgrades, and expected migration costs. Cloud-hosted products require equivalent discussion with cloud service providers.3

Migration dependencies: protocols, PKI, suppliers, and assurance

A migration plan must account for dependencies between systems and services. The NCSC gives protocols such as TLS and IKE as examples of mechanisms that may need to negotiate certificate choices so PQC certificates can be used when both communicating parties are upgraded. It also describes a possible new PQC root of trust that cross-signs an older one, while emphasizing that the security implications must be assessed case by case.6

The evidence also places responsibility outside the organization’s direct boundary. CISA, NSA, and NIST recommend asking vendors how they are addressing quantum readiness and supporting migration. For commercial products, vendor roadmaps should state when and how updates or upgrades will enable PQC and the expected cost. For cloud products, organizations should understand the provider’s roadmap and later focus on how PQC can be enabled through configuration changes or application updates.3

Testing and measurement are part of the transition, not a final administrative step. The NCSC warns that a migration can cause loss of service or weaken security and recommends additional tests to confirm that cryptography performs as expected. Once standardized PQC cipher suites are available for TLS, organizations should verify that systems are actually using them rather than falling back to traditional cryptography. It also suggests metrics such as the number of software clients using PQC and the identity of clients that are not.6

The evidence therefore supports an assurance loop: discover use, prioritize risk, change or replace components, test negotiated behavior and operational effects, measure adoption and exceptions, and use the results to determine when traditional support can be retired. This sequence is a synthesis of the cited guidance, not a published universal implementation methodology.6

Governance: make agility a continuing risk-management capability

NIST CSF 2.0 provides a useful governance pattern for the operational problem. It describes organizational profiles that can be scoped to an entire organization or to a defined area, and it recommends gathering policies, risk priorities, resources, impact analysis, requirements, practices, tools, and work roles. Organizations can analyze gaps between current and target profiles and create an action plan.7

Applied cautiously to crypto agility, this suggests that leadership should define a target state, managers should prioritize risk and resources, and practitioners should implement and measure changes. NIST CSF 2.0 says practitioners provide managers and executives with key performance and risk indicators so they can understand posture and adjust strategy. The application to cryptographic migration is an inference; the cited CSF is a general cybersecurity framework rather than a crypto-agility maturity study.7

The OWASP CycloneDX evidence is relevant to visibility because it identifies a cryptography bill of materials as one supported bill-of-materials type, alongside software, SaaS, hardware, machine-learning, manufacturing, operations, vulnerability, and attestation formats. The cited passage establishes the specification’s stated support; it does not demonstrate that any organization has implemented a cryptography bill of materials or that it solves discovery by itself.4

What the evidence does—and does not—show

Several boundaries are important. The cited source set is strong on official guidance, standards context, inventory concepts, and migration considerations, but it is not a market census. It does not quantify how many enterprises are agile, how many systems use PQC, the cost of migration, the duration of coexistence, or the performance of any particular implementation. It also does not resolve organization-specific regulatory obligations, architecture choices, supplier commitments, or risk tolerances. Any conclusion about market maturity would therefore exceed the cited evidence.13

Conclusion

The evidence portrays crypto agility as an operational capability required to manage cryptographic change safely, not as a label that can be inferred from purchasing a PQC product. The defensible near-term position is to build visibility, identify long-lived and high-impact data, map cryptographic and system dependencies, engage suppliers, prepare for coexistence, and test actual negotiated behavior. NIST’s 2024 standards provide a concrete basis for planning, while the stated 2035 transition direction adds urgency without eliminating organization-specific sequencing. The cited sources support disciplined preparation and measurement; they do not support a universal maturity score or a claim that the market has already completed migration. claim-01 claim-031236