Crypto-agile migration: an action plan for the post-quantum era

July 30, 2026

Post-quantum cryptography already has standards. What most organisations still lack is an operational roadmap. This is yours.

In August 2024, NIST published the first final post-quantum cryptography standards. ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) ceased to be proposals and became formal standards. The starting point for migration is no longer "when standards are available". The starting point is now.

However, in most organisations, the gap between “standards exist” and “we have a plan” remains enormous. Security teams understand the urgency conceptually but do not know where to begin. Budgets have not shifted because there is no concrete proposal. And technology providers are sending conflicting messages about timelines and compatibility.

Let us move on to an action guide. Not an introduction to quantum mechanics or a summary of standards. A plan structured into phases, with specific deliverables, key decisions and indicators of progress that a CISO can take to their company next week.

Crypto-agility makes it possible to meet any future cryptographic objective without redesigning an architecture from scratch.

What it really means to be crypto-agile

The term crypto-agility is used frequently but is rarely defined precisely. In practice, a crypto-agile organisation has four specific capabilities:

Complete visibility of which cryptographic algorithms it uses, where they are used, in which systems and in which versions. Without an inventory, there is no agility; only obscurity.
The ability to replace one algorithm with another quickly, without disrupting the service or rewriting applications from scratch. This requires cryptography to be abstracted into layers that are separate from the business logic.
Simultaneous support for multiple algorithms during transition periods. Systems must be able to negotiate and operate with classical RSA and post-quantum ML-KEM in parallel until the migration is complete.
Active governance of the cryptographic lifecycle: who decides which algorithms are used, according to which criteria, how often they are reviewed and how the organisation responds to an emerging vulnerability.

■ Few organisations have all four capabilities today. Most do not have the first. The migration plan below is designed to build them in order, pragmatically and without attempting to solve everything at once.

Let us carry out the migration through a five-phase plan:

1. Cryptographic inventory START
A snapshot of the starting point · 0–6 months

You cannot migrate what you cannot see. The cryptographic inventory is step zero in any post-quantum transition programme, and it is also the step that most organisations skip because they consider it laborious. It is, but the alternatives are worse.

A complete cryptographic inventory answers four questions for every asset: which algorithm is used, in which system or application, who manages it and what its expected lifespan is. The analysis tools used may range from manually inspecting configurations to specialist crypto-discovery solutions that scan network traffic and code repositories.

Identify every system that uses PKI, TLS, SSH, digital signatures or encryption at rest.
Catalogue algorithms by type: asymmetric key (RSA, ECC), symmetric (AES), hash (SHA), signature (ECDSA, RSA-PSS).
Map dependencies: which applications depend on which certificates and which HSMs.
Identify systems with embedded or hard-coded cryptography (higher migration risk)
Classify cloud providers and SaaS services with access to encrypted data.
Document existing certificate and key renewal cycles

2. Risk-based prioritisation START
Not everything migrates at the same time · 3–9 months

Once you have the inventory, the next common mistake is trying to migrate everything at once. This makes neither technical nor financial sense. Proper prioritisation begins with HNDL risk: data that retains long-term value is at risk today, even if Q-Day is still a decade away.

The rule of thumb is simple: if data needs to remain confidential for longer than it will take for a quantum computer capable of breaking RSA-2048 to become available, estimated at between five and 15 years depending on the source, that data should be protected with post-quantum cryptography as soon as possible.

Classify data assets by their required confidentiality horizon (<5 years / 5–15 years / >15 years).
Prioritise communications containing trade secrets, intellectual property, health data or regulated information.
Identify long-lived keys: root certificates, HSM master keys and code-signing keys.
Assess communication systems involving regulated entities (banking, healthcare and critical infrastructure)
Build a prioritisation matrix: data criticality × lifespan × ease of migration

2. Crypto-agile architecture PLAN
Building the capacity for change · 6–18 months

This is the most technical and the most strategic phase. The objective is not to migrate a specific algorithm, but to redesign the way your organisation manages cryptography so that future changes are inexpensive and fast rather than disruptive.

Introduce a cryptographic abstraction layer that decouples algorithms from applications.
Require algorithm selection in new developments to be configurable rather than hard-coded.
Deploy a dual-stack PKI capable of issuing classical and post-quantum certificates in parallel.
Implement hybrid key exchange in TLS for highly critical systems (RSA/ECDH + ML-KEM).
Update secure development standards to include crypto-agility requirements.
Assess and select certified PQC libraries (liboqs, BouncyCastle PQC, OpenSSL 3.x with PQC support)

Progressive migration PLAN
Executing in waves, not through revolution · 12–36 months

With the crypto-agile architecture under way, the actual migration of algorithms can be carried out in a controlled manner. The three-wave model makes it possible to manage risk without disrupting operations and to adjust the pace according to the maturity of the provider and tooling ecosystem.

Wave 1 High-priority HNDL assets (months 12–18): external communications containing data that will remain sensitive over the long term, digital signatures for documents with long-term legal value and PKI master keys. These are the assets currently at greatest risk and, frequently, those with the best support from PQC tools.

Wave 2 Internal critical infrastructure (months 18–30): corporate VPNs, system authentication, encryption of critical databases and communications between internal microservices. These require greater coordination between infrastructure and development teams.

Wave 3 Legacy systems and the edge (months 24–36+): OT/ICS systems, legacy applications that are difficult to modify and IoT devices. These are frequently the most complex and may require specific strategies such as cryptographic translation gateways.

Define the entry and exit criteria for each wave.
Set up test and staging environments with PQC configurations before production.
Plan the renewal of root certificates (a high-impact operation requiring a maintenance window).
Coordinate with cloud providers to enable PQC options in contracted services.
Document each migration for regulatory compliance records.

Continuous cryptographic governance STRUCTURAL
The migration never ends · Ongoing

Post-quantum cryptography is not the final destination. It is the current standard. There will be new algorithms, new vulnerabilities and new regulatory requirements. A continuous cryptographic governance programme is what ensures that the organisation does not have to start from scratch again with every transition.

Review the cryptographic inventory at least annually.
Subscribe to NIST, ENISA and CCN-CERT alerts on cryptographic vulnerabilities.
Include crypto-agility criteria in system lifecycle management (SDLC, procurement).
Keep supplier contracts up to date with cryptographic update clauses.
Train the security team in PQC annually as the standards evolve.
Report to the Board on the status of the programme using clear progress metrics.

The most common mistakes and how to avoid them

X Migrating without a prior inventory
Starting to deploy PQC without knowing what is in production guarantees incomplete migrations and vulnerability blind spots.

✓ Inventory first, always
Devote the first few months exclusively to visibility. The inventory is the only basis from which rigorous prioritisation is possible.
X Treating PQC as a one-off project
Cryptography changes. A programme without continuous governance will become obsolete before it is fully deployed.

✓ Designing for change from the outset
Crypto-agile architecture is the investment that reduces the cost of every future migration, not just the current one.
X Ignoring PQC performance
Some PQC algorithms have larger signatures or keys than their classical equivalents. Failing to account for this causes performance degradation in production.

✓ Testing performance in staging
Validate the impact on latency and message size before production. ML-KEM has a good performance profile; SLH-DSA is more resource-intensive for frequent signing.
X Forgetting legacy and inherited systems
OT systems, IoT devices and older applications are difficult to migrate, but they frequently access sensitive data. Ignoring them creates permanent weak points.

✓ Planning translation gateways
For systems that cannot be migrated directly, PQC gateways make it possible to protect communications without modifying the internal system.

The metrics that matter

A crypto-agile migration programme without progress metrics will not survive budget review cycles. These are the four metrics that communicate progress in a way that a Board of Directors can understand:

Percentage of the cryptographic inventory using vulnerable algorithms, showing current exposure and how it decreases over time. This is the most direct risk metric.
Coverage of migrated high-priority HNDL assets, indicating progress on the most urgent front. A Board understands 70% of our most sensitive data is already protected with post-quantum cryptography.
Number of systems with a crypto-agile architecture, measuring the structural capacity to respond to future change. This is the programme's resilience metric.
Percentage of critical suppliers with quantum-readiness clauses. This extends the security posture beyond the organisation's own perimeter, which the Board should understand as a fiduciary responsibility.

Get our handbook on protecting data from the quantum threat

At Telefónica Tech we advocate for a cryptoagility-based strategy, enabling systems to adapt to new threats without disrupting operations.

■ We invite all organisations to access our complimentary handbook Strategic preparation for Post-Quantum Cryptography and take the first step towards a resilient cryptographic infrastructure ready for the quantum era.