Measuring Migration Progress

What measuring migration progress means

For this article, migration progress is the demonstrable movement from unknown or quantum-vulnerable cryptographic dependencies toward appropriately protected, tested, and operationally supported systems. The scope includes cryptography used for digital signatures, key establishment, encryption, authentication, software and firmware updates, network protocols, applications, libraries, hardware, infrastructure, and public key infrastructure (PKI). It also includes the people, suppliers, operating processes, and assurance activities needed to keep the migration secure and operational.124

A progress measure should therefore answer five questions: what has been found; what matters most; what has changed; whether the change works as intended; and what remains blocked or exposed. A count of upgraded servers can be useful, but it can mislead if high-impact systems, long-lived data, industrial-control devices, certificates, or supplier dependencies are excluded. The measurement boundary should be documented and kept stable enough to compare reporting periods.25

Why measurement matters

Organizations need to begin preparation before a cryptographically relevant quantum computer exists because cryptographic migration is complex and can take a long time. NIST IR 8547 IPD, published in November 2024 as an initial public draft, states that past cryptographic migrations have taken over a decade and that this more complex migration will likely take at least that long. Its discussion of Mosca’s theorem relates the protection lifetime of data and the migration time to the anticipated time for a cryptographically relevant quantum computer. These are planning considerations, not a prediction of when such a computer will exist.4

Measurement turns that urgency into management information. It can show whether discovery is expanding, whether high-impact systems are receiving attention, whether suppliers have a credible delivery path, whether controls operate in practice, and whether residual exposure is declining. It also supports decisions about sequencing and investment. The CISA, NSA, and NIST fact sheet recommends a quantum-readiness roadmap beginning with a project-management team and cryptographic discovery, while emphasizing prioritization of high-impact systems, industrial control systems, and systems with long-term confidentiality or secrecy needs.2

A useful metric is therefore actionable rather than merely impressive. For example, “80% migrated” is incomplete unless the denominator is defined, the percentage is risk-weighted or segmented, excluded assets are known, and the organization can show that the new configuration is actually in use. Metrics should expose uncertainty and exceptions rather than hide them.13

A practical measurement model

Use a sequence of measurable states. The states may overlap operationally, but each should have an owner, evidence requirement, date, and status. A system should not be reported as complete merely because a code change or product update exists; the relevant protocol, certificate, key, application behavior, or device configuration should be validated in its operating environment.13

1. Discover: identify cryptographic use in network protocols, end-user systems, servers, applications, libraries, firmware, devices, PKI, and other infrastructure.
2. Classify: record the protected data or function, business and operational impact, confidentiality or integrity needs, data security life, system owner, supplier, and technical constraints.
3. Prioritize: rank work using impact, long-term confidentiality or secrecy, industrial-control relevance, external exposure, and feasibility or urgency of remediation.
4. Plan: assign a target state, dependencies, responsible owner, supplier commitment where applicable, milestones, test approach, rollback or coexistence approach, and exception process.
5. Implement: update protocols, libraries, applications, certificates, keys, hardware, firmware, or services as appropriate; account for changed key sizes, algorithm performance, and compatibility.
6. Assure: test security and operational behavior, verify the intended algorithms are being used, detect unwanted fallback, and record results.
7. Operate and retire: monitor the deployed state, manage remaining traditional support, address failures and exceptions, and define evidence for removing legacy algorithms or pathways.

This model separates activity from outcome. “Migration work started” is an activity. “The prioritized service uses the intended PQC-capable configuration in production, passed relevant tests, has an owner, and has no unresolved blocking exception” is outcome-oriented evidence. Both may be reported, but they should not be conflated.13

Useful measures and how to interpret them

The following measures provide a balanced dashboard. They should be segmented by system criticality, IT or OT environment, cryptographic function, supplier, and migration state where the underlying inventory supports those distinctions. Percentages should always include their denominator and reporting date.25

• Inventory coverage: identified in-scope systems, protocols, applications, devices, certificates, keys, and suppliers divided by the estimated in-scope population. Report unknowns separately.
• Risk assessment coverage: inventoried items with documented data or function criticality, security life, exposure, owner, and migration disposition.
• Priority completion: high-impact or otherwise prioritized items that have reached the defined validated target state divided by all prioritized items.
• PQC adoption: applicable clients, services, endpoints, certificates, or protocol sessions demonstrably using the intended PQC or approved transition configuration. Keep “capable,” “configured,” and “observed in use” separate.
• Traditional dependency: systems, flows, certificates, or suppliers that still require traditional algorithms, including the reason and planned treatment.
• Assurance pass rate: migrations that passed defined security, interoperability, performance, and operational tests; record failed, deferred, and not-yet-tested populations separately.
• Vendor readiness: suppliers with a documented roadmap, delivery milestone, supported product or service scope, and testing evidence. A roadmap alone is not deployment evidence.
• Exception age and concentration: open migration exceptions by criticality, owner, reason, compensating action, and age; highlight repeated concentration in one supplier, platform, or environment.
• Retirement readiness: systems for which use of traditional algorithms can be turned off without unacceptable compatibility or service impact, supported by testing and an approved decision.

A particularly important measure is observed use. The UK National Cyber Security Centre advises additional testing to check that cryptography is performing as expected; for standardized PQC cipher suites in TLS, systems should be checked to confirm that they use the suites rather than falling back to traditional cryptography. It specifically gives quantifying software clients using PQC, and identifying those that do not, as an example of a migration-success metric. This makes adoption measurement a verification problem, not just a configuration-reporting problem.1

Build evidence that supports the metrics

The foundation is a cryptographic inventory with enough context to support prioritization and repeatable measurement. The joint CISA, NSA, and NIST guidance says the inventory should provide visibility into how the organization uses cryptography across IT and OT systems and should identify quantum-vulnerable technology and the criticality of associated data. Discovery should cover network protocols, assets on end-user systems and servers, applications, and associated libraries; the source set also identifies signatures, software and firmware updates, and supplier technologies as relevant areas.2

At minimum, each inventory record should preserve the system or component identity, owner, environment, cryptographic function, algorithm and key or parameter details where known, protocol or application dependency, protected data or function, security life, business impact, supplier, upgrade path, current state, target state, test evidence, exception, and last verification date. Do not treat an absent value as proof that no cryptography is present. Track unknown and not assessed as distinct states.251

Key-management evidence matters because key metadata supports applications in selecting appropriate keys and is crucial to application and protocol implementation. NIST SP 800-57 Part 1 Rev. 5 describes four key-management phases—preoperational, operational, post-operational, and destroyed—and notes that metadata can include the identity of an associated person or system and the information that person is authorized to access. Migration reporting should therefore distinguish a planned replacement from an operationally active key or certificate and from material that has been retired or destroyed.3

Evidence should be time-bound. Capture discovery results, configuration observations, test reports, deployment records, supplier statements, exception approvals, and retirement decisions with dates and responsible owners. This enables trend reporting while preserving the limitations of point-in-time scans and incomplete supplier information.12

Architecture and operating workflow considerations

Migration affects more than a cryptographic library. NIST IR 8547 IPD identifies network protocol and security technology standards, software cryptographic libraries, cryptographic hardware, PKI and other infrastructure components, and IT applications and services as migration areas. Applications may need changes for encryption, digital signatures, and key exchange, including code refactoring, testing, protocol and library compatibility work, and accommodation of changed key sizes and algorithm performance.4

PKI deserves a separate progress view. The NCSC describes enterprise PKI migration as requiring a new PQC root of trust and new PQC certificates for network entities. A parallel PKI may operate alongside the traditional PKI during a staged migration; a controlled environment may instead move in one step. The choice affects certificate issuance, protocol negotiation, device reachability, test coverage, and the duration of coexistence. Report these dependencies explicitly rather than counting PKI as a single completed asset.1

Crypto agility is an architectural enabler for this workflow. NIST CSWP 39 Update 1, whose cited source metadata identifies it as final with updates as of June 29, 2026, defines crypto agility as the capability to replace and adapt algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations. Because the source has a publication date of December 19, 2025 and an update date of June 29, 2026, teams should preserve those document-status details when citing or governing against it.6

In practice, measure whether change mechanisms are repeatable: can an owner identify affected dependencies, select an approved configuration, test it, deploy it, observe it, and reverse or remediate a failed change? This is a workflow capability, not a claim that every component is already crypto-agile.36

Risks, limitations, and interpretation rules

A migration dashboard can create false confidence if it counts only modern, centrally managed systems. Industrial-control and industrial-IoT environments may include resource-constrained or non-upgradeable devices, difficult service locations, embedded components, proprietary protocols, and products not yet compatible with PQC. Wireless field OT devices may have especially important integrity requirements even where confidentiality is less demanding, because faulty sensor readings or commands can contribute to control-system failures.1

Legacy systems and custom-built products may require substantial effort. The joint fact sheet says custom-built technologies with quantum-vulnerable cryptography should be assessed for the risk to dependent data or functions; organizations may migrate them or develop security upgrades that mitigate continued use. For commercial off-the-shelf products, vendor engagement is critical, and the roadmap should include when and how updates or upgrades will enable PQC and their expected cost. Cloud-hosted products require equivalent engagement with cloud service providers.21

Do not infer that a standard or product roadmap guarantees a secure implementation. The cited CISA, NSA, and NIST passage notes that final implementation specifics for draft PQC standards were incomplete in the context of its guidance to vendors. NIST SP 800-57 also cautions that strong cryptography can be poorly implemented and calls for preimplementation evaluation, testing, and training when new procedures are introduced. Report implementation maturity and test evidence separately from standards availability.35

Finally, avoid treating every traditional algorithm as equally urgent or every PQC transition as identical. NIST SP 800-131A Rev. 2 distinguishes acceptable, deprecated, and disallowed status terms, with status depending on algorithm, key length, parameters, and manner of use. It also emphasizes that security strength and data security life affect transition decisions. Apply the governing standard and application context; do not invent a universal deadline from a single metric.5

A practical reporting and improvement cycle

Start by appointing a cross-functional migration team with IT, OT where relevant, procurement, security architecture, application, infrastructure, risk, and supplier-management representation. Establish the inventory boundary, definitions, migration states, evidence requirements, reporting cadence, and exception authority. The roadmap should identify dependencies and prioritize systems whose compromise would have high impact or expose data requiring long-term confidentiality or secrecy.2

1. Baseline the current state. Publish counts and percentages with denominators, dates, unknowns, and confidence or evidence status.
2. Prioritize the backlog. Use criticality, data or function security life, external exposure, OT consequences, supplier constraints, and migration complexity.
3. Set measurable target states. Define what “PQC capable,” “configured,” “observed in use,” “tested,” “operational,” and “legacy retired” mean for each technology class.
4. Run pilots and tests. Include interoperability, performance, key and certificate handling, application behavior, rollback, monitoring, and fallback detection where applicable.
5. Review suppliers. Obtain product and cloud-provider roadmaps, supported versions, delivery dates, costs, and testing responsibilities; record missing or uncertain commitments as risk.
6. Report exceptions. Give every exception an owner, rationale, compensating measure where available, review date, and planned resolution or accepted residual risk.
7. Rebaseline continuously. Compare the latest evidence with the prior period, investigate regressions, and retire metrics that no longer support decisions.

A useful executive view has three layers: overall coverage and trend; risk-weighted status of prioritized systems; and a blocked-work register. A useful engineering view adds component-level dependencies, observed protocol behavior, failed tests, certificate and key states, supplier milestones, and remaining traditional paths. Both views should reconcile to the same inventory and reporting date.213

Conclusion

Measuring migration progress is an evidence and decision discipline. Build a living cryptographic inventory, connect each dependency to impact and data or function lifetime, prioritize high-consequence work, and distinguish capability from deployed and observed use. Validate protocol behavior, supplier delivery, application and device compatibility, key and certificate states, and exceptions. Report denominators, unknowns, dates, and limitations. A credible program demonstrates not only that migration work is happening, but that quantum-vulnerable exposure is being reduced safely and that the organization knows what remains before legacy support can be retired.213