Crypto-Agility & the PQC Migration

Executive summary

Crypto-agility — cryptographic agility — is the ability of a system to change the cryptographic algorithms and parameters it relies on without re-architecting the system around them. It is the property that turns a cryptographic migration from a multi-year rebuild into a controlled, repeatable operation. And it has moved, quietly but decisively, from a best practice to a requirement.

The reason is the post-quantum transition. In 2024 the U.S. National Institute of Standards and Technology (NIST) finalized the first standards for post-quantum cryptography (PQC): ML-KEM in FIPS 203, ML-DSA in FIPS 204, and SLH-DSA in FIPS 205. These algorithms are designed to resist attacks from a future large-scale quantum computer that would break the classical public-key cryptography protecting most of the internet today. Migrating to them is not a one-time event; it is the first of what will be several algorithm transitions over the coming decades. Organizations that hard-code their cryptography will pay for each transition in full. Organizations that build crypto-agility pay once to become agile, then absorb every future change at the margin.

This guide is written for the people who own that decision: CISOs, heads of platform and infrastructure, security architects, and the risk and compliance leaders who have to defend the program to auditors and boards. It explains what crypto-agility actually is, why the quantum horizon makes it urgent, and — the bulk of the document — a practical six-step program to get there: discover and inventory your cryptography as a Cryptographic Bill of Materials, prioritize by data shelf-life and exposure, abstract cryptography behind interfaces, adopt hybrid classical-plus-PQC schemes, test and roll out, and then monitor and maintain agility for the long run. It closes with governance and standards, and the pitfalls that most commonly derail these programs.

What cryptographic agility actually is

Most systems in production today treat their cryptography as a fixed decision. An algorithm was chosen when the system was designed — RSA-2048 for a key exchange here, ECDSA for a signature there, a specific TLS cipher suite pinned in a config file — and that choice was woven into the code, the data formats, the protocols, and the operational assumptions of everything around it. It works, and for years there is no reason to touch it. The problem surfaces only when the algorithm has to change. At that moment the organization discovers that "the algorithm" was never a single decision it could revise; it was hundreds of coupled decisions scattered across the estate.

Crypto-agility is the discipline of designing so that the algorithm is a variable, not a constant. In an agile system, the choice of algorithm and its parameters is expressed through configuration and referenced through an abstraction, so that introducing a new algorithm — say, replacing an RSA key exchange with a hybrid ML-KEM-1024 exchange — is an operational change rather than an architectural one. The system does not need to be rebuilt; it needs to be reconfigured, tested, and rolled out.

Concretely, an agile design exhibits a handful of recognizable properties:

• Algorithm independence. Application code calls a cryptographic capability — "encrypt this," "establish a shared key," "sign this artifact" — without naming the specific algorithm that satisfies it. The algorithm is selected by a provider or a policy layer beneath the call.
• Negotiation and identification. Where two parties interact, the protocol carries an explicit identifier of the algorithm in use, so peers can negotiate a common choice and so stored ciphertext records which scheme produced it. You cannot rotate what you cannot name.
• Parameterization. Key sizes, security levels, and mode selections are configuration values, not literals compiled into the binary. Moving from one security level to another is a settings change.
• Versioned formats. Data at rest carries a version or algorithm tag so that a mixed population of old and new ciphertext can coexist during a migration, and so old data can be identified for re-encryption.
• Centralized policy. The set of permitted algorithms is defined in one governed place rather than rediscovered in every repository, so a decision to deprecate an algorithm can be enforced consistently.

It is worth being precise about what crypto-agility is not. It is not the same as simply supporting many algorithms; a system can offer a long menu of ciphers and still be rigid if switching between them requires code changes and redeployment. Nor is it "roll your own crypto" — agility is about how you integrate vetted, standardized algorithms, never about inventing them. And it is not a promise that migrations become free. Agility lowers the cost and risk of each change; it does not eliminate the work of testing, validating, and rolling out. The goal is modest and powerful at the same time: make the next cryptographic change tractable.

Why crypto-agility is essential now

Cryptographic agility has been recommended by standards bodies for years, usually as a matter of good hygiene. What has changed is the arrival of a concrete, dated, unavoidable transition that turns the recommendation into an operational necessity. That transition is the move to post-quantum cryptography.

The quantum threat to classical public-key cryptography

The public-key algorithms that secure the modern internet — RSA, Diffie-Hellman, and elliptic-curve schemes — rest on mathematical problems that are hard for classical computers: factoring large integers and computing discrete logarithms. Shor's algorithm, running on a sufficiently large and fault-tolerant quantum computer, solves both efficiently. Such a machine does not exist today, and credible estimates of when it might arrive vary widely. But the direction of travel is not in dispute, and the consequence is stark: when a cryptanalytically relevant quantum computer exists, data protected only by classical public-key cryptography becomes readable, and classical digital signatures become forgeable.

Symmetric cryptography is affected differently and far less severely. Grover's algorithm offers a quadratic speedup against symmetric ciphers, which is addressed by using adequate key lengths; AES-256 retains a comfortable security margin against known quantum attacks. The urgent problem is therefore concentrated in the public-key layer — key establishment and signatures — which is precisely where the new NIST standards apply.

Harvest now, decrypt later

The reason this cannot wait for the quantum computer to actually arrive is a strategy known as harvest now, decrypt later (HNDL). An adversary does not need to break your encryption today to benefit from your data today; it can capture encrypted traffic and stored ciphertext now, retain it cheaply, and decrypt it years later once the capability exists. Any data whose confidentiality must outlive the arrival of quantum computers is therefore already exposed if it is protected only by classical key exchange. This reframes the timeline entirely: the deadline for protecting long-lived data is not the day quantum computers appear, but today. We treat this threat model in depth in our companion analysis of harvest now, decrypt later, and the algorithms themselves in our guide to post-quantum cryptography.

Migration is not a single event

Here is the argument that makes agility, rather than a one-off swap, the correct response. The post-quantum standards are new. As with any cryptography, confidence in them will grow with scrutiny, and it is prudent to assume that parameters may be revised, that a scheme could be deprecated if a weakness is found, and that additional algorithms will be standardized over time. NIST's own program has continued to evaluate further candidates beyond the first three standards. An organization that migrates by hard-coding ML-KEM in place of RSA has solved this transition and pre-committed to paying the same migration cost again at the next one. An organization that migrates by building agility has converted a recurring capital expense into a manageable operational one. The post-quantum move is best understood not as the destination but as the forcing function — the event that finally justifies building the muscle you will use repeatedly.

The risk of hard-coded, sprawling, and hidden crypto

Before describing the migration program, it is worth naming precisely what makes cryptographic change hard in a typical enterprise. The difficulty is rarely the new algorithm. It is the accumulated state of the old one. Three patterns account for most of the pain.

Hard-coded cryptography

Cryptographic choices are frequently embedded directly in source code: an algorithm named in a constant, a key size passed as a literal, a cipher suite pinned in a deployment manifest, a certificate's signature algorithm assumed by a parser. Each of these is invisible until it has to change, and then each is a code change requiring a developer, a review, a test cycle, and a release. When the same choice is hard-coded in dozens of services written by different teams in different languages, a single algorithm transition fans out into dozens of independent projects with no shared finish line. Hard-coding is what converts "change the algorithm" into "change every system that used it."

Cryptographic sprawl

Over time, an organization accumulates cryptography from many sources: multiple TLS-terminating layers, several languages each with its own crypto library, cloud key-management services, hardware security modules, message-queue encryption, database-level encryption, application-level field encryption, code-signing pipelines, and a long tail of certificates. No single team owns all of it, and no single inventory describes it. This sprawl means that even a well-intentioned migration cannot state confidently that it is complete, because no one can enumerate the full set of places cryptography lives. Sprawl is the enemy of provable coverage.

Hidden and inherited cryptography

The most dangerous category is the cryptography you do not know you have. It arrives through dependencies — a library that negotiates TLS on your behalf, a vendor SDK that signs requests, a SaaS integration whose key exchange you never see. It hides in firmware, in embedded devices, in build and CI systems that sign artifacts, and in protocols you treat as opaque. It persists in old data formats and archived backups encrypted years ago under schemes no one remembers choosing. Hidden cryptography is why discovery, not implementation, is the hardest part of a migration: you cannot protect, prioritize, or replace what you cannot see. Our broader treatment of the estate-wide picture is in the guide to the enterprise encryption stack.

These three patterns compound. Hard-coding makes each instance expensive to change; sprawl multiplies the instances; hidden crypto ensures you cannot even count them. The migration program that follows is designed specifically to attack this trio in order — first make the crypto visible, then make it prioritizable, then make it agile — so that the transition itself becomes the easy part.

A practical crypto-agility migration program

The program below is a sequence of six phases. They are presented in order because each depends on the ones before it — you cannot prioritize what you have not discovered, and you cannot abstract what you have not prioritized — but in practice they overlap, and mature organizations run several in parallel across different parts of the estate. The through-line is that agility is built into the migration, not bolted on afterward: the same work that moves you to post-quantum algorithms is the work that leaves you able to move again.

Deflected delivers this program as a scoped engagement through Quantum-Safe Migration, but the phases are described here in vendor-neutral terms so that any organization can follow them. The specifications you are migrating toward are consistent throughout:

Step 1 — Discover and inventory: the Cryptographic Bill of Materials

Every credible migration begins with discovery, because the dominant risk is not the algorithm you will adopt but the cryptography you cannot see. The deliverable of this phase is a Cryptographic Bill of Materials (CBOM): a structured, maintained inventory of every place cryptography is used across the organization, and what each instance protects.

A useful CBOM records, for each cryptographic use, a consistent set of attributes:

• Algorithm and parameters — the specific scheme and its key size or security level (for example, RSA-2048 key exchange, ECDSA P-256 signatures, AES-256-GCM at rest).
• Purpose — key establishment, digital signature, symmetric encryption, hashing, or authentication, since the quantum exposure differs sharply by purpose.
• Location and owner — the system, service, or device where it lives, and the team accountable for it.
• Protocol and library — the TLS version or protocol, and the concrete library and version implementing it, which is where hidden dependencies surface.
• Certificates and keys — issuers, expiries, key lifetimes, and where key material is stored (HSM, cloud KMS, filesystem).
• Protected data and exposure — what data or system the cryptography defends, its sensitivity, and whether it is exposed externally, so the next phase can prioritize.

Building the CBOM draws on several complementary methods, because no single technique finds everything. Static analysis and dependency scanning surface cryptographic calls and libraries in source and build artifacts. Network and traffic inspection reveals negotiated protocols and cipher suites in live systems. Certificate and key-management inventories enumerate the PKI. Configuration review covers the pinned choices in manifests and infrastructure-as-code. And structured interviews with system owners capture the vendor integrations and inherited cryptography that automated tools miss. The CBOM should be treated as a living asset stored in a governed system of record, not a one-time spreadsheet, because the estate changes continuously and the next transition will begin from wherever this inventory has reached.

Step 2 — Prioritize by data shelf-life and exposure

A complete CBOM will list far more cryptographic instances than any organization can migrate at once, and treating them as equally urgent guarantees that the truly urgent items wait behind trivial ones. The second phase imposes an order of operations grounded in the actual threat, and for the post-quantum transition that threat is defined by two dimensions: how long the data must stay secret, and how exposed it is to harvesting.

Data shelf-life and Mosca's inequality

The governing intuition is often expressed as Mosca's inequality: if the length of time your data must remain confidential, plus the time it will take you to migrate, exceeds the time until a quantum computer can break your cryptography, then you are already too late and must act now. You cannot know the last term precisely, but you can reason clearly about the first two. Data with a long shelf-life — records that must stay confidential for a decade or more, such as personal and health data, financial records, trade secrets, government and legal material, and long-lived credentials and root keys — is exactly the data that harvest-now-decrypt-later targets, because its value survives until decryption becomes possible. This data goes to the front of the queue.

Exposure to harvesting

The second dimension is how reachable the data is to an adversary who wants to capture it now. Cryptography protecting data that crosses public or untrusted networks, that terminates at externally exposed endpoints, or that transits third parties is more exposed than cryptography confined to an isolated internal segment. Long-lived, highly exposed data — long shelf-life crossing untrusted links — is the highest priority; short-lived, internal data is the lowest.

Signatures warrant a distinct prioritization from encryption. The harvest-now-decrypt-later threat is about confidentiality, so it drives the urgency of key establishment. Signature migration is driven instead by the lifetime over which a signature must remain trustworthy: firmware and code-signing keys, long-validity certificates, and anything whose authenticity must be verifiable years from now should move to post-quantum signatures on a timeline set by that verification horizon. The output of this phase is a ranked migration backlog — a sequenced plan tying each CBOM entry to a priority tier — that turns an overwhelming inventory into a defensible order of work.

Step 3 — Abstract cryptography behind interfaces and providers

The first two phases produce knowledge and a plan; this phase is where agility is actually engineered. The objective is to reach a state in which changing an algorithm is a configuration and deployment action rather than a code change, and the mechanism is abstraction: application code should depend on a cryptographic interface, and the concrete algorithm should be supplied by a provider behind that interface.

In practice this means introducing a thin internal cryptographic service or library layer that exposes intent-level operations — establish a shared key, encrypt a payload, sign an artifact, verify a signature — and hides the algorithm choice behind them. Several design commitments make that layer genuinely agile:

• Provider selection by policy. The algorithm a given operation uses is chosen by a central, governed policy, not by the caller. Changing the policy changes the algorithm everywhere the interface is used.
• Algorithm identifiers everywhere. Every ciphertext, signature, and negotiated session records which algorithm produced it, so systems can interpret mixed-algorithm data and negotiate compatible choices with peers.
• Versioned, self-describing data formats. Encrypted records carry a header identifying the scheme and parameters, allowing old and new ciphertext to coexist and enabling systematic re-encryption of the backlog.
• Graceful negotiation and fallback. Where two parties must agree, the protocol negotiates the strongest mutually supported algorithm and degrades safely, never failing closed in a way that breaks the application and never silently downgrading below policy.
• Centralized key management. Keys are issued, stored, and rotated through a managed service or HSM rather than handled ad hoc, so that adopting new algorithms does not fracture key handling.

Two cautions matter here. First, abstraction must not become a home-grown reimplementation of cryptography; the provider layer wires together vetted, standardized implementations and adds no novel cryptographic logic of its own. Second, the abstraction should be deep enough to swap algorithms but not so ambitious that it tries to hide every difference between them — post-quantum keys and signatures are larger than their classical counterparts, and formats, buffers, and protocols must accommodate that reality rather than pretend it away. Done well, this phase is the durable payoff of the whole program: once cryptography sits behind a governed interface, the post-quantum migration and every migration after it become changes to policy and configuration.

Step 4 — Adopt hybrid classical-plus-PQC schemes

With an agile foundation in place, the migration adopts post-quantum algorithms — and the recommended way to do so during the transition is hybrid. A hybrid scheme runs a proven classical algorithm and a post-quantum algorithm together and combines their outputs, so the result is secure as long as either component remains unbroken.

Why hybrid, and how it works

Hybrid key establishment addresses the central uncertainty of an early transition: the classical algorithms have decades of cryptanalysis behind them but are known to be quantum-vulnerable, while the post-quantum algorithms are quantum-resistant by design but comparatively young. Running both — for example, a hybrid X25519 + ML-KEM-1024 key exchange that derives a single shared secret from both — means an attacker must break both to recover the key. You gain quantum resistance immediately without discarding the assurance accumulated in the classical scheme. This belt-and-suspenders posture is why hybrid key establishment is widely recommended for the migration period, and it is the posture Deflected uses by default across its platform.

The target algorithms

The concrete choices map to the NIST standards by purpose:

• Key establishment — ML-KEM-1024 (FIPS 203), the highest parameter set of the standardized key-encapsulation mechanism, deployed in hybrid with a classical exchange such as X25519.
• General-purpose signatures — ML-DSA-87 (FIPS 204), the highest parameter set of the lattice-based signature scheme, for signatures that are produced and verified at scale.
• High-assurance and long-lived signatures — SLH-DSA (FIPS 205), a stateless hash-based signature scheme whose security rests on well-understood hash assumptions, valuable where conservative, long-horizon trust matters, such as firmware and root signing, and as a diversifying alternative to the lattice family.
• Symmetric encryption — AES-256 remains the workhorse for data at rest and in transit; it is not quantum-broken at 256-bit keys and does not need replacing, only correct integration behind the agile interface.

A practical note on cost: post-quantum keys, ciphertexts, and signatures are larger than their classical equivalents, and hybrid schemes carry both. That has real implications for packet sizes, handshake latency, storage, and any protocol with tight field limits. The agile abstraction from the previous phase is what makes these effects manageable, because it localizes the changes to the provider layer and the data formats rather than scattering them across every application.

Step 5 — Test and roll out

Adopting new cryptography is a change to the most safety-critical part of a system, and it is rolled out the way any high-risk change should be: incrementally, reversibly, and with evidence at every step. The agile foundation makes this possible, because algorithm identifiers, versioned formats, and negotiation allow old and new to coexist rather than forcing a synchronized cutover.

An effective rollout sequence typically proceeds through stages:

1. Validate implementations. Confirm that the libraries and providers are correct, standards-conformant, and — where required — running in validated cryptographic modules. Interoperability testing against known-good implementations catches subtle format and negotiation errors before they reach production.
2. Test in non-production. Exercise the new schemes under realistic load and data, measuring the performance and size effects on handshakes, storage, and latency, and verifying that fallback and negotiation behave correctly at the boundaries.
3. Enable in hybrid mode behind negotiation. Turn on the post-quantum algorithms for a limited, high-priority slice of traffic or data, with the classical algorithm still present, so that any failure degrades safely rather than breaking the service.
4. Expand progressively. Widen the rollout tier by tier according to the priority backlog, monitoring for interoperability failures, latency regressions, and negotiation downgrades as coverage grows.
5. Re-encrypt the backlog. Systematically re-encrypt long-lived data at rest that was protected under the old schemes, using the version tags in the data format to identify what still needs to move. This is what actually closes the harvest-now-decrypt-later window for stored data.

Throughout, the ability to roll back matters as much as the ability to roll forward. Because the interface negotiates algorithms and the formats are self-describing, an unexpected problem can be contained by reverting policy to the classical algorithm without a code change or a data-format break. That reversibility is a direct dividend of having built agility first, and it is what lets a security-critical migration proceed at a confident pace.

Step 6 — Monitor and maintain agility

The final phase is the one that distinguishes a genuine crypto-agility program from a one-time post-quantum project. Having done the hard work of becoming agile, an organization must keep the property alive, because agility decays: new systems arrive with hard-coded choices, dependencies introduce fresh cryptography, and the standards themselves will continue to evolve. The objective of this phase is to make the estate's cryptographic posture continuously observable and governed.

Maintaining agility rests on a few ongoing practices:

• Keep the CBOM current. The inventory is wired into CI/CD and asset management so that new cryptographic uses are discovered as they are introduced, not rediscovered in the next emergency. The CBOM is the standing source of truth for the next transition.
• Monitor for policy drift. Continuous checks flag deprecated algorithms, weak parameters, expiring certificates, and any cryptography introduced outside the governed interface, so drift is caught early rather than accumulating into new sprawl.
• Govern the permitted-algorithm policy. A single owned policy defines which algorithms are allowed for which purposes, with a defined process for adding, deprecating, and retiring schemes as guidance changes. Enforcing that policy through the abstraction layer is what makes a future change a configuration update.
• Rehearse the next migration. Because further transitions are expected, periodically exercise the ability to introduce and roll out a new algorithm, treating agility as a capability that must be practiced to stay real.

Handled this way, the sixth phase turns the entire program into a durable operating capability. The post-quantum migration becomes the first exercise of a muscle the organization now maintains, and the next transition — whether a parameter revision, a new standardized algorithm, or the deprecation of a scheme — is absorbed as routine operations rather than a fresh crisis.

Governance and standards

A cryptographic migration is as much a governance program as a technical one, because its hardest questions — what counts as done, who is accountable, how completeness is proven — are organizational. Anchoring the program to recognized standards gives it both technical direction and defensibility.

The NIST post-quantum standards

The technical foundation is the set of standards NIST finalized in 2024, which define the algorithms this program migrates toward:

• FIPS 203 — ML-KEM (derived from CRYSTALS-Kyber), the module-lattice key-encapsulation mechanism used for key establishment; Deflected targets ML-KEM-1024.
• FIPS 204 — ML-DSA (derived from CRYSTALS-Dilithium), the module-lattice digital-signature algorithm; Deflected targets ML-DSA-87.
• FIPS 205 — SLH-DSA (derived from SPHINCS+), the stateless hash-based signature scheme, providing algorithmic diversity from the lattice family.

These sit alongside broader guidance on migration planning and the definition of cryptographic-agility properties from national standards bodies and cybersecurity agencies, which converge on the same core recommendations: inventory first, prioritize by shelf-life and exposure, adopt hybrid schemes during the transition, and build agility for the transitions to come.

Program governance and audit-readiness

Beyond the algorithms, the program needs the governance apparatus that lets an organization demonstrate — to auditors, regulators, boards, and enterprise customers — that its cryptographic posture is managed rather than assumed. That means clear ownership of the CBOM and the algorithm policy, a documented prioritization rationale, evidence of the rollout and re-encryption work, and reporting that ties the whole effort back to risk. For organizations aligning this with a wider compliance posture, our engagement in Quantum-Safe Migration produces exactly these artifacts, and the platform's overall approach to trust and evidence is described on our security page. Governed this way, the migration is not only secure but demonstrably so.

Common pitfalls

Cryptographic migrations fail in recognizable ways. Naming the common pitfalls in advance is the cheapest form of risk reduction available to the program.

• Skipping discovery. The most frequent and most damaging mistake is treating the migration as an implementation problem and rushing to deploy new algorithms before the CBOM is complete. What follows is a migration that cannot prove its own coverage and leaves hidden cryptography untouched.
• Rolling your own agility. Building bespoke cryptographic abstractions that inadvertently reimplement or misuse primitives introduces new vulnerabilities in the name of flexibility. The abstraction layer must integrate vetted, standardized implementations and add no novel cryptographic logic.
• Treating PQC as a one-time swap. Hard-coding ML-KEM in place of RSA solves this transition and rebuilds none of the agility needed for the next. The point of the program is the capability, not just the algorithm.
• Ignoring size and performance. Post-quantum and hybrid schemes produce larger keys, ciphertexts, and signatures. Programs that fail to test the effect on handshake latency, packet sizes, storage, and constrained protocols discover the problem in production.
• Abandoning classical too early. Dropping the classical algorithm before the post-quantum scheme has earned sufficient operational confidence forfeits the very protection hybrid mode is designed to provide. Hybrid exists precisely so you do not have to make that bet.
• Forgetting signatures and long-lived keys. Focusing only on key establishment because of the harvest-now-decrypt-later headline leaves firmware signing, code signing, and long-validity certificates on borrowed time. Signature migration has its own horizon and its own deadline.
• Letting agility decay. Achieving agility once and then failing to maintain the CBOM, monitor for drift, and govern the algorithm policy allows sprawl and hard-coding to creep back, so the next transition starts from zero again.

Each of these pitfalls maps to a phase of the program, and the sequence exists in large part to avoid them: discovery before implementation, abstraction with vetted primitives, hybrid before decommissioning, and maintenance as a standing capability rather than a closed project.

Frequently asked questions