Enterprise Migration Benchmark Report

Scope, date, and evidence method

Review date: 2026-06-30. This article is a primary-source desk review of the cited source set cited for this topic. It synthesizes passages from NIST, CISA, NSA, the UK National Cyber Security Centre, and the OWASP Foundation. The sources are identified in the cited source set as primary, and their cited statuses and dates are preserved rather than supplemented with external material. The review asks what a defensible enterprise migration benchmark can measure from the evidence: planning activities, visibility, prioritization, transition design, governance, and supplier readiness. It does not claim to measure how many enterprises have completed those activities.125

The method is deliberately qualitative. Each observation is tied to one or more cited passages. Where this article says that a practice is a useful benchmark indicator, that is an inference from the guidance, not a reported industry statistic. No denominator, respondent population, organization list, performance dataset, cost model, or independently validated maturity score appears in the cited bundle. Consequently, terms such as “leading,” “lagging,” “high maturity,” or “benchmark” should be read as descriptions of capability evidence, not as rankings of named enterprises.5

What “enterprise migration” means in this review

In the cited evidence, enterprise migration is broader than replacing an encryption library. It includes identifying where public-key cryptography is used, understanding dependencies across applications, protocols, hardware, firmware, services, and operational technology, assessing the importance and secrecy lifetime of information, selecting a transition sequence, and confirming that products and suppliers can support the required changes. The NIST crypto-agility source defines crypto agility as the capability to replace and adapt cryptographic algorithms across protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. That definition makes continuity a central migration outcome, not an optional engineering refinement.34

The risk case is prospective but actionable. The cited NIST material describes quantum computers as a future threat that could eventually break many widely used cryptographic systems. It also describes “harvest now, decrypt later”: an adversary may capture encrypted information today and seek to decrypt it when a sufficiently capable quantum computer becomes available. CISA, NSA, and NIST therefore urge organizations to prepare now through roadmaps, inventories, risk assessments, and vendor engagement. This is an evidence-supported rationale for early planning; it is not evidence that a cryptographically relevant quantum computer currently exists or that the date of such a capability is known.162

The standards baseline has also changed. NIST says that in August 2024 it released three principal post-quantum cryptography standards: FIPS 203, ML-KEM, for key establishment; FIPS 204, ML-DSA, for digital signatures; and FIPS 205, SLH-DSA, for digital signatures. The same project material says organizations should begin migrating systems to quantum-resistant cryptography and that additional standardization work continues. The cited evidence therefore supports a benchmark that tests both present planning and the ability to track an evolving standards ecosystem.1

Benchmark dimensions supported by the evidence

A practical benchmark should examine whether an organization can show evidence of the following capabilities. These are not scores assigned by the source documents; they are review dimensions inferred from repeated recommendations across the cited source set.5

1. Scope and ownership. The organization has defined the business, technology, data, or operational scope of the migration and assigned accountable roles. NIST CSF 2.0 describes organizational profiles as scopeable to an entire organization or to a particular system or threat, and recommends documenting assumptions, gathering relevant information, creating a current and target profile, analyzing gaps, and creating an action plan.
2. Cryptographic and asset visibility. The organization can identify vulnerable algorithms and where they occur in network protocols, applications, libraries, end-user systems, servers, IT and OT systems, devices, and cloud dependencies. The inventory should capture the nature and scale of systems, and, where available, versions, patch levels, and dependencies.
3. Risk-based prioritization. The organization links cryptographic use to data criticality, system impact, secrecy lifetime, and operational consequences. The cited joint fact sheet specifically calls for prioritizing high-impact systems, ICSs, and systems with long-term confidentiality or secrecy needs.
4. Transition design. The organization has a staged plan for coexistence, certificate and protocol changes, testing, retirement of traditional algorithms, and exceptions. The NCSC warns that PQC can introduce compatibility-breaking changes and that traditional public-key cryptography and PQC may need to coexist for a period.
5. Agility and continuity. Products and architectures can support alternative algorithm suites and changes without unacceptable disruption. This includes technical mechanisms and decision criteria for ending support for traditional algorithms.
6. Supplier and lifecycle control. Procurement and risk teams engage vendors about migration roadmaps, update or upgrade timing, costs, cloud-provider readiness, and support for cryptographic changes. Supply-chain inventories and monitoring are treated as continuing lifecycle activities.
7. Governance and improvement. Migration is connected to enterprise risk management, risk appetite, tolerance, standardized prioritization, executive communication, and continuous improvement rather than treated as an isolated cryptography project.

These dimensions distinguish an evidence-backed readiness review from a simple count of systems upgraded. A reported algorithm deployment without a dependency inventory may conceal unmanaged legacy devices. Conversely, a complete inventory without prioritization or supplier commitments may create visibility without a credible route to risk reduction. The sources do not prescribe one universal scoring scale, so this review recommends recording evidence, gaps, dependencies, assumptions, and planned decisions rather than fabricating a numeric maturity score.52

Inventory is the foundation of migration sequencing

The strongest recurring operational requirement in the cited source set is visibility. CISA, NSA, and NIST state that organizations are often unaware of the breadth of application and functional dependencies on public-key cryptography in products, applications, and services. Their recommended cryptographic inventory is intended to reveal quantum-vulnerable technology and associate it with data criticality so that risk assessment and migration prioritization can begin. The inventory is not limited to a list of algorithms: it should provide visibility into how cryptography is used across IT and OT environments and identify relevant protocols, assets, applications, libraries, devices, and services.2

The NCSC passage adds a useful distinction between early discovery and a formal asset register. At the initial stage, understanding the nature of each system may be more important than enumerating every individual item. Organizations should nevertheless seek to quantify system scale where possible and capture version information, patch levels, and dependencies. This supports a practical benchmark question: can the organization explain not only where cryptography exists, but also which component depends on which other component and how a change could propagate?4

Prioritization should be explicit. The joint fact sheet directs attention to high-impact systems, industrial control systems, and data with long-term confidentiality or secrecy requirements. It also identifies the value of correlating external access to datasets and considering information that may be targeted now and decrypted later. NIST CSF 2.0 similarly describes maintaining inventories and prioritizing assets according to classification, criticality, and organizational objectives. These passages support a risk-ranked queue, not a first-come, first-served technology refresh.25

Why the evidence favors staged migration

The cited sources do not support a universal “big bang” migration. The NCSC says that, except for the simplest systems, organizations will likely need traditional public-key cryptography and PQC to coexist for a period. It recommends seeking solutions with cryptographic agility and identifying criteria for ending support for traditional algorithms. The same guidance says that systems are fully protected against the quantum-computing threat only when they no longer have sole dependence on traditional public-key cryptography; this is a security-state observation, not a claim that every environment can reach it on one timetable.4

Public-key infrastructure illustrates the sequencing problem. The cited NCSC material says that protocols such as TLS and IKE may need to negotiate certificates during transition, while another approach could introduce a new PQC root of trust that cross-signs an older one. The security implications must be assessed case by case. In general, the source says quantum-secure authentication is not achieved until PKI migration is complete and traditional certificates have expired or been revoked. Planning must therefore account for certificate lifetimes, trust relationships, communicating parties, and the readiness of implementations—not merely the presence of a new algorithm in a test environment.4

OT and ICS environments raise additional constraints. Physical infrastructure may have significant planning requirements and infrequent replacement cycles. Remote logins into ICS IT zones need secure authentication, while wireless field devices and sensors may require particular attention to integrity: faulty readings or commands can cause ICS failures even where confidentiality needs are less demanding. Industrial IoT devices may be resource-constrained, difficult to service, embedded in larger products, non-replaceable, proprietary, or not yet PQC-compatible. Internet-connected devices can also provide an entry point toward control networks and the enterprise IT zone through a DMZ. These observations support prioritizing operational consequences and serviceability alongside cryptographic strength.52

Suppliers, procurement, and governance

Migration readiness extends beyond assets directly controlled by the enterprise. The joint CISA, NSA, and NIST guidance recommends involving IT and OT procurement experts and supply-chain vendors in the inventory. It says organizations should ask vendors how they are addressing quantum readiness and supporting migration to PQC. For commercial off-the-shelf products, vendor roadmaps, update or upgrade timing, and expected costs are material planning inputs; for cloud-hosted products, organizations should engage providers about their quantum-readiness roadmaps and how PQC will be enabled through configuration or application changes.2

The NIST CSF 2.0 evidence provides a governance frame for this work. It calls for risk-management objectives, risk appetite and tolerance statements, strategic response options, communication across the organization, and a standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks. It also connects supplier and third-party risk to enterprise risk management. The implication for this review is that a migration benchmark should look for decision records and accountable escalation paths, not only technical proof-of-concept results.5

Software and component transparency can strengthen this evidence, but the cited OWASP passage should not be overstated. CycloneDX is identified as ECMA-424 and supports software, SaaS, hardware, machine-learning, cryptography, manufacturing, and operations bills of materials, as well as vulnerability disclosure reports, VEX, and attestations. That establishes a possible structured representation for supply-chain information. It does not, by itself, prove that a particular enterprise’s inventory is complete, that every vendor supplies usable data, or that a CycloneDX artifact contains all cryptographic dependencies required for PQC planning.5

Standards readiness without false precision

The evidence supports treating standards adoption and standards monitoring as separate benchmark dimensions. NIST’s 2024 project material identifies ML-KEM, ML-DSA, and SLH-DSA as the principal standards and says they can and should be put into use now. It also says NIST continues to evaluate additional algorithms, including ongoing work involving Falcon and HQC, and longer-term work on additional digital signature schemes. Therefore, a migration plan should document which approved or evaluated standards are relevant to each use case, while preserving a process for responding to future guidance and implementation changes.1

The cited source set also includes a NIST transition statement that quantum-vulnerable algorithms will be deprecated and ultimately removed from NIST standards by 2035 under the transition timeline in NIST IR 8547, with high-risk systems transitioning earlier. This date is reproduced as cited and should not be generalized into a universal enterprise deadline: the evidence does not provide a complete regulatory schedule for every organization, jurisdiction, product, or algorithm. It is best used as a planning signal that reinforces early prioritization and lifecycle decisions.4

NIST’s process is described as open and transparent, with international evaluation and attention to constrained devices such as smart cards, IoT devices, and microchips. That matters to enterprise benchmarking because performance and deployment feasibility may differ across servers, embedded devices, field equipment, and other constrained environments. The cited evidence does not provide performance measurements, interoperability test results, or a comparative recommendation among the standards; this review therefore avoids assigning one algorithm to every enterprise use case.1

A practical evidence-collection sequence

A defensible review can be conducted as a sequence of evidence requests. First, define the scope and assumptions: business units, data classes, IT and OT environments, services, suppliers, and systems included. Second, assemble the cryptographic and asset inventory, including algorithms, protocols, applications, libraries, hardware, firmware, certificates, versions, patch levels, dependencies, external access, and data criticality where available. Third, identify high-impact systems, ICSs, long-secrecy data, and custom-built or difficult-to-replace technologies. Fourth, map each priority item to a transition path, including coexistence, certificate and protocol dependencies, testing, rollback, retirement criteria, and residual risk.524

Fifth, test supplier evidence: product and cloud roadmaps, planned updates, implementation assumptions, support windows, expected costs, and ownership of unresolved dependencies. Sixth, test crypto agility by asking whether algorithm suites can be changed across relevant layers while preserving security and operations. Seventh, connect the plan to enterprise risk governance, risk appetite, communications, and executive decisions. Finally, record limitations: unknown assets, unavailable vendor information, unsupported legacy systems, untested protocol interactions, and uncertainties in standards or implementation readiness. This sequence is a synthesis of the cited guidance, not a prescribed certification method.425

The resulting benchmark output should be an evidence register rather than a single headline number. For each migration domain, record the observed condition, supporting artifact, accountable owner, dependency, priority rationale, target state, next action, and confidence or uncertainty. This format preserves the distinction between an organization’s documented capability and an analyst’s inference about readiness. It also makes later reviews comparable without pretending that the cited bundle contains a statistically comparable enterprise population.5

Missing data, uncertainty, and source boundaries

The source set is coherent on the need for early preparation, inventory, risk-based prioritization, staged migration, supplier engagement, and agility. It is not a complete implementation specification. It does not quantify the cost of migration, the number of affected systems in a typical enterprise, the time required for a particular environment, the percentage of vendors with PQC roadmaps, or the comparative security and performance of the named standards. It also does not establish that every organization must use the same transition pattern.5

The source set spans different purposes and dates. NIST CSF 2.0 is dated February 26, 2024; the NIST PQC overview is dated August 13, 2024; the joint CISA, NSA, and NIST fact sheet is dated August 17, 2023; the NCSC migration-timelines source is dated March 20, 2025; and NIST CSWP 39 Update 1 is listed as published December 19, 2025 and updated June 29, 2026. The cited AI RMF material is relevant to general risk-management context but does not provide a migration benchmark, so it is not used here to infer PQC adoption. The OWASP material describes a standard and ecosystem scope, not enterprise outcomes.12

One cited NIST AI RMF passage includes an April 7, 2026 concept-note date. Because that material concerns a critical-infrastructure AI profile rather than enterprise cryptographic migration, this review treats it as outside the core benchmark evidence. This boundary prevents adjacent framework material from being presented as evidence about PQC readiness.62

Conclusion

The cited primary sources support a practical enterprise migration benchmark built around evidence of visibility, prioritization, staged transition, crypto agility, supplier readiness, and governance. They do not support a league table, adoption percentage, average cost, or universal completion date. The most defensible conclusion is that migration readiness is demonstrated by the organization’s ability to connect cryptographic dependencies to business and operational impact, act on high-priority exposure, manage coexistence and lifecycle constraints, and revise implementation choices as standards and supplier capabilities evolve. Any stronger quantitative conclusion would exceed this cited source set.542