Large-scale Cryptographic Migration

1. Treat the migration as an estate-wide operating programme

Large-scale migration is best understood as a mass technology change spanning IT and OT systems. The effort can extend across multiple leadership cycles, and its cost includes both preparatory work and the implementation itself. That scale changes the delivery model: the programme needs a durable backlog, named system owners, engineering capacity, procurement involvement, service-management integration, and a mechanism for revising plans as standards, products, and dependencies evolve. It should not be run as a narrow cryptography project detached from infrastructure, application, manufacturing, or operational teams.1

The immediate execution objective is continuity with controlled reduction of quantum-vulnerable exposure. Existing public-key cryptography is used in products, protocols, and services, including mechanisms for authentication, signatures, key exchange, software updates, and firmware updates. Some data may retain its sensitivity for many years, creating a rationale for beginning preparation before every implementation detail or product delivery is settled. The programme should therefore separate decisions that can be made now—discovery, ownership, dependency mapping, testing, procurement, and risk prioritisation—from decisions that depend on final implementation or interoperability details.23

Create a migration control function that maintains the estate view, the prioritisation model, wave approvals, exceptions, test evidence, rollback decisions, and unresolved dependencies. This function should connect cybersecurity and privacy risk managers with IT and OT procurement experts, application and infrastructure owners, supply-chain managers, and operational teams. The purpose is not to centralise every technical decision; it is to ensure that local migrations add up to a coherent sequence and that a blocked dependency is visible before it becomes an outage.2

2. Build the inventory before designing the waves

Discovery is the foundation of execution. Build an inventory that shows where cryptography is used across network protocols; end-user systems and servers; applications and their libraries; software; hardware; firmware; infrastructure; and services. Include mechanisms used to create or validate digital signatures, because signing and validation can affect application releases, software updates, firmware updates, trust chains, and operational processes. Record the data protected, its criticality and secrecy lifetime, the current algorithm or protocol role, the owner, the environment, the supplier, and the route by which the component can be updated or replaced.2

Inventory quality matters more than the appearance of completeness. Organisations are often unaware of the breadth of application and functional dependencies on public-key cryptography in deployed products, applications, and services. Discovery should combine cryptographic discovery tools with owner interviews, configuration and code review, network and certificate analysis, procurement records, supplier engagement, and operational knowledge. Mark each record with confidence and an evidence path so that an apparently low-risk item does not silently become a late discovery during rollout.2

Dependency mapping should describe both direction and consequence. For every cryptographic component, identify upstream prerequisites and downstream consumers: certificate authorities and trust stores, identity services, applications, databases, APIs, network peers, update systems, key-management services, hardware security functions, cloud services, monitoring, backup, disaster recovery, and external partners. Capture whether a change can be made independently, requires coordinated deployment, or depends on a supplier or industry ecosystem. Record version, configuration, compatibility assumptions, maintenance window, replacement cycle, and rollback mechanism.1

Give special treatment to decentralised and long-lived dependencies. WebPKI involves trusted roots, certificate authorities, certificate-transparency log providers, and certificate-revocation-list providers; agreement on post-quantum signatures and compatibility with traditional components may be difficult, so sequencing cannot be assumed to be under one organisation’s control. Industrial-control protocols may include legacy designs that have not been brought to modern cryptographic standards; replacing them may require architectural changes for modern key management, not merely insertion of a new algorithm.1

The inventory should become a living migration register. At minimum, each record should support a decision about priority, treatment, owner, wave, required supplier action, test status, operational constraints, and residual risk. Reconcile the register against asset-management and service-management data regularly. A migration cannot be declared complete merely because a new library was installed: the dependent service, trust material, key lifecycle, backup, recovery, monitoring, and external interfaces must be accounted for.12

3. Prioritise by exposure, value, dependency, and changeability

Prioritisation should combine the criticality of the protected data with the difficulty and consequence of changing the system. Give early attention to services processing valuable or long-lived data, systems with quantum-vulnerable public-key cryptography, assets exposed through outside access, and systems whose data could be targeted now and decrypted when a cryptographically relevant quantum computer becomes available. Also elevate services whose migration lead time is long because of bespoke code, hardware, certification, procurement, supplier dependence, or infrequent replacement cycles.21

A practical priority record can use four lenses: impact if confidentiality or authenticity fails; urgency based on data secrecy lifetime and exposure; delivery complexity based on dependencies and change constraints; and readiness based on tested technology, owner commitment, supplier support, and rollback capability. Do not use a single numerical score as a substitute for judgement. A lower-impact system may be a useful pilot if it exercises a difficult shared dependency, while a high-impact system may require preparatory work before it is safe to change.21

Design waves around services and dependency boundaries rather than around isolated algorithms. A wave may contain a service, its protocol peers, certificates, libraries, keys, deployment pipeline, monitoring, backup and recovery processes, and the suppliers required to support it. Where a shared platform serves many applications, migrate the platform and its consumers through explicitly coordinated sub-waves. Where dependencies cannot be moved together, define an interoperability period, document the permitted legacy use, and set an owner and retirement condition.13

For each wave, define entry criteria, a change design, test evidence, an implementation window, decision authority, communications, operational staffing, success measures, and exit criteria. The plan may include researching technology options, procurement, commissioning, testing, data backup and migration, and rollout. Include time for supplier delivery and for resolving defects; a calendar date without these prerequisites is not an executable plan.1

4. Make continuity and rollback part of the design

Migration plans must state how much outage each business or operational service can tolerate. That tolerance determines whether a change is performed in place, staged, blue-green, failover-based, or during a planned maintenance period. It also determines how much parallel support, traffic control, compatibility testing, and operational staffing are required. For OT and extensive physical infrastructure, account for constraints imposed by infrequent replacement cycles; a migration path that assumes rapid hardware refresh is not credible for such environments.13

Testing should cover more than successful cryptographic operations. Test authentication, signature creation and validation, key exchange, certificate and trust-chain processing, update and recovery paths, protocol negotiation, interoperability with unchanged peers, performance, resource consumption, logging, alerting, failover, backup restoration, and operational procedures. Applications may need code refactoring, updated libraries and protocols, adaptation to changed key sizes or algorithm performance, and in some cases interface redesign.3

Define rollback before implementation. The rollback design should identify the trigger, decision owner, maximum decision time, last safe state, retained configuration and key material, traffic or device transition method, communications, and validation after reversal. Test the rollback path under realistic failure conditions, including partial deployment and loss of a dependency. A rollback plan is not permission to continue indefinite legacy use: it is a bounded recovery mechanism, with the conditions for retry, remediation, or escalation recorded in the wave decision.13

Use gradual exposure where the service permits it. Start with a representative but bounded population, observe compatibility and operational indicators, then expand only when the evidence meets the wave criteria. For tightly coupled systems, the bounded unit may be an entire dependency set rather than a percentage of users. Capture lessons and update the inventory, test cases, supplier assumptions, and future wave templates after every implementation.13

5. Migrate the key lifecycle with the service

Cryptographic migration changes key-management operations as well as algorithms. Protect key material during installation into software, hardware, systems, applications, cryptographic modules, and devices. Installation may occur during initial setup, replacement, rekeying, or key derivation, and the process must protect the material while it is entered or transferred. Treat installation as a security-critical change procedure with controlled personnel, tooling, records, and verification.6

Map each key’s lifecycle and required availability. Operational key information may need normal storage and backup storage; information retained after the end of a cryptoperiod may require archive storage. Backup supports recovery of key information that is lost from normal storage, while archive supports later operations or recovery according to the key’s retention need. Not every key necessarily requires backup, so the decision should be made in the context of the application and documented with the service’s recovery requirements.6

Record state transitions in audit logs and key metadata. Operational or backed-up keys may move among states such as pre-activation, active, deactivated, suspended, compromised, or destroyed, depending on the system. The applicable states and transitions should be defined for the service, and events should be recorded where the design requires them. During a migration, confirm that new and retained keys have coherent status, ownership, recovery, destruction, and audit treatment; otherwise a technically successful cutover can create an operational or compliance failure.2

Include recovery exercises in wave acceptance. Restore the relevant key information from backup or archive in a controlled environment, validate that the migrated service can use it as intended, and verify that access controls and audit records remain correct. The purpose is not to retain every historical key indefinitely, but to ensure that retention, availability, sanitisation, and recovery decisions match the application and the data’s required lifetime.6

6. Coordinate suppliers, cloud providers, and external ecosystems

Supplier engagement is a delivery dependency, not a procurement afterthought. Ask each commercial off-the-shelf vendor, cloud service provider, hardware manufacturer, software supplier, and managed service provider for its quantum-readiness roadmap, expected update or upgrade timing, supported configurations, compatibility constraints, testing responsibilities, and migration cost. For cloud-hosted products, clarify which changes are provider-controlled and which require customer configuration or application updates. Record commitments in the migration register and link them to affected services and waves.2

Require evidence rather than general assurances. Useful evidence includes supported protocol and algorithm profiles, product or firmware versions, implementation and performance test results, interoperability results, key and certificate handling, deployment and rollback procedures, support arrangements, and the status of relevant validation or standards work. The cited evidence notes that implementation specifics may remain incomplete while standards mature; therefore, record the status and uncertainty explicitly rather than treating a draft roadmap as a guaranteed delivery date.2

Some migrations require coordination beyond the organisation. WebPKI sequencing involves multiple ecosystem participants, and OT protocols may require architecture changes. Establish an escalation route through industry or regulator forums where appropriate, share practical migration experience, and identify decisions that cannot be resolved by one system owner. The organisation should maintain flexible plans for these cases, with interim controls and a review date rather than a false assumption that all participants will change simultaneously.1

Coordinate operations through a shared change calendar and dependency-aware communications plan. Notify service desks, incident response, network operations, application support, facilities or plant operators, suppliers, and affected business owners. Define who can stop a rollout, who owns an interoperability incident, how evidence is collected, and how the decision to proceed or reverse is communicated. This is especially important where a cryptographic change appears as a certificate, identity, firmware, network, or application incident rather than as a recognisable cryptography fault.2

7. Measure progress by risk retired, not equipment touched

A useful migration dashboard measures whether risk and dependency uncertainty are decreasing. Track inventory coverage and confidence; the proportion of high-priority services with owners and target waves; unresolved external dependencies; supplier commitments and missed dates; test and rollback readiness; migrated service groups; remaining controlled legacy use; key-recovery test results; and incidents or exceptions after rollout. Report both counts and service impact so that a large number of low-value changes does not obscure an unaddressed critical service.1

Use stage gates that reflect operational evidence. A service should not enter implementation until its dependencies, outage tolerance, test design, supplier responsibilities, key-handling plan, and rollback path are understood. It should not exit until monitoring is stable, recovery evidence is available, records are updated, residual legacy use is controlled, and the owner accepts the remaining risk. Where the evidence is incomplete because a standard or supplier implementation is still evolving, the gate should create a named action and review date rather than silently converting uncertainty into acceptance.1

Plan for several periods of transition rather than a single finish line. NCSC guidance describes indicative milestones, including defining migration goals, completing discovery, and building an initial plan by 2028, while NIST IR 8547 is an initial public draft and describes a broader strategy involving adoption, controlled legacy use, and eventual removal. These dates and document statuses are not interchangeable mandates for every organisation. Use them as planning context, preserve the stated uncertainty, and set estate-specific targets based on risk, dependencies, and applicable requirements.1

Finally, keep the programme adaptable. Migration technologies, product support, interoperability arrangements, and implementation details can change. A living inventory, modular wave design, crypto-agile interfaces, explicit supplier commitments, tested rollback, and disciplined key management allow the organisation to respond without restarting the entire programme.4

Conclusion

Large-scale cryptographic migration succeeds when it is executed as dependency-aware service transformation. Discover cryptographic use across IT and OT, connect it to data value and operational constraints, and make suppliers and external ecosystems visible in the plan. Deliver through bounded waves with tested interoperability, continuity limits, key-lifecycle controls, observable acceptance criteria, and a rehearsed rollback path. Maintain crypto agility and a living register so that evolving standards or product capabilities can be absorbed without losing operational control. The result is not merely a changed algorithm; it is a managed estate with clearer dependencies, recoverable services, and a credible path away from quantum-vulnerable cryptography.1436