Migration & Crypto-Agility

Prioritize by risk and lead time

Start with long-lived confidential data and critical trust dependencies. Consider how long procurement, hardware replacement, partner coordination, and client upgrades will take. An internet-facing connection is visible, but an offline signing system or long-lived device can be harder to change.

Define the pilot before changing production

• Choose a supported algorithm and protocol profile for a bounded application path.
• Record the baseline: reliability, latency, CPU, memory, packet sizes, and failure rates.
• Include old clients, proxies, inspection devices, certificate tooling, and disaster recovery.
• Test fallback, malformed inputs, negotiation failures, and loss of a dependency.
• Define success, rollback authority, and criteria for expanding deployment.

What crypto-agility actually requires

Crypto-agility is the ability to change cryptographic choices without redesigning the entire system. It needs versioned interfaces, an inventory, configurable policies, replaceable dependencies, automated tests, and owners who can operate the change. Adding an algorithm selector alone does not provide it.

Procurement questions

Ask suppliers for supported release dates, protocol profiles, key and certificate handling, hardware requirements, validation status, and end-of-support dates. Require evidence for the product configuration you will run, rather than accepting a broad “quantum-safe” label.

Measure completion

Report dependencies migrated and verified, exceptions with expiry dates, remaining unsupported components, and observed interoperability failures. Keep business owners informed about residual exposure. Migration is complete for a path only when its intended protection is demonstrably active.

Sources & further reading

• NCCoE migration program
• UK NCSC planning and migration targets