Crypto-agility: engineering defense systems to swap algorithms

Most defense systems do not break because their cryptography was weak when they were fielded. They break because the cryptography stayed the same while the world moved on. An algorithm that was sound at deployment becomes deprecated, then discouraged, then forbidden – and the system that hard-coded it now needs a multi-year, multi-supplier engineering program to change a single primitive. Crypto-agility is the discipline of building systems so that swapping an algorithm is a configuration and deployment task, not a redesign. With the migration to post-quantum cryptography now a fixed requirement for long-lived defense data, agility is no longer a refinement – it is the precondition for surviving the next transition without re-fielding the system.

What crypto-agility actually means

Crypto-agility is the property of a system that lets it change algorithms, key sizes, and protocols without re-architecting the application that depends on them. The test is simple: how long, and how many lines of code, does it take to replace one algorithm with another? In a non-agile system the answer is "we re-open the design," because the algorithm name, key length, and parameter set are scattered through application logic, serialization formats, certificate templates, and protocol handlers. In an agile system the answer is "we change a policy," because every one of those decisions was externalized to configuration the moment the system was built.

Agility is not the same as having a good crypto library. A program can link the best-reviewed library available and still be completely rigid, because the application calls a specific function – RSA_sign, a named curve, a fixed digest – directly from business code. The library being swappable does not help if the call sites are not. Agility is an architectural property of the whole system, not a feature of one dependency.

Why defense systems need it now

Two timelines collide in defense procurement. The first is the service life of the platform. A combat vehicle, a radio family, or a command-and-control suite is expected to operate for twenty to forty years. Across that span, cryptographic standards will turn over several times – the transition from SHA-1, the deprecation of 1024-bit RSA, and the move to authenticated encryption all happened within a single platform generation. Any algorithm baked into a system today will be obsolete long before the hardware is retired.

The second timeline is the quantum threat. A cryptographically relevant quantum computer would break RSA and elliptic-curve cryptography outright, and the "harvest now, decrypt later" strategy means adversaries can capture today's encrypted traffic and store it until that machine exists. Defense data with decades-long confidentiality requirements is therefore already at risk, even though the quantum computer is not here yet. The standards response – CNSA 2.0 and the NIST post-quantum suite – sets firm migration deadlines. A system without agility cannot meet those deadlines without a re-engineering effort that the schedule does not allow. For the threat model and timeline behind this, see our analysis of the quantum computing threat to defense communications.

Start with a cryptographic inventory

You cannot migrate what you cannot see, and you cannot make agile what you have not located. The first deliverable of any crypto-agility program is a cryptographic inventory – increasingly formalized as a cryptographic bill of materials, or CBOM. It is a complete catalogue of every place the system uses cryptography: each algorithm and mode, each key length, every certificate and its issuer, the protocol versions negotiated on every interface, the libraries that implement the primitives, and – critically – the data each instance protects and how long that data must stay confidential.

The inventory is almost always more surprising than the program expects. Cryptography hides in firmware that no one has the source for, in third-party binaries whose algorithm choices are undocumented, in hardware security modules with fixed capabilities, and in protocol defaults negotiated at runtime rather than chosen at design time. A useful inventory records discovery confidence and ownership for each entry, distinguishing "we read this in source" from "we observed this on the wire" from "the vendor told us." It must be a living artifact regenerated by the build pipeline, not a one-time audit that is stale the day after it ships.

From inventory to risk priority

The inventory is not just a map – it is the input to prioritization. Two attributes drive migration order: the confidentiality lifetime of the protected data, and the exposure of the channel. Data that must stay secret for thirty years and crosses an external link is the first thing to migrate, because it is exactly what "harvest now, decrypt later" targets. Short-lived data on an internal, physically protected segment can wait. Without the inventory, this triage is impossible and the program either migrates everything at once (which is unaffordable) or migrates the easy things first (which leaves the highest-risk data exposed longest).

The algorithm abstraction layer

The structural core of an agile system is an algorithm abstraction layer – a cryptographic provider or service interface that sits between application code and the concrete implementations. Application code never names an algorithm. Instead it expresses intent: "sign this message," "establish a session key with this peer," "encrypt this record at rest." Alongside the intent it references a named policy – for example signing.c2-link.v3 – and the abstraction layer resolves that policy to a concrete algorithm, key length, and parameter set at runtime.

The payoff is that an algorithm swap becomes a policy edit. Changing signing.c2-link.v3 from an elliptic-curve signature to a post-quantum signature is a configuration change rolled out per environment, with no edit to the calling code and no recompilation of the application that issues the sign request. The same indirection lets a program run different algorithms in different theaters or for different classification levels from a single binary, and lets it stage a migration – old policy in production, new policy in test – without forking the codebase.

Designing the interface correctly matters. It should be coarse enough that application developers cannot accidentally reach around it (no "give me a raw AES key" escape hatch that re-hard-codes the choice), and it should expose algorithm metadata so callers can record which policy was applied. The HSM, key vault, and rotation machinery live behind this layer too; for the operational side of that, see our guide to secrets management in defense CI/CD pipelines.

Versioning protocols, certificates, and stored data

Agility at the call site is necessary but not sufficient. Cryptographic artifacts outlive the moment they are created – a record encrypted today may be decrypted in fifteen years, a certificate issued now is verified by peers for its whole validity period, and a protocol session is negotiated between two systems on different upgrade schedules. Each of these must carry enough metadata to survive an algorithm change.

Protocols. On-the-wire formats must include explicit algorithm identifiers and version fields so two peers can negotiate a common algorithm rather than assume one. A protocol that hard-codes "the signature is ECDSA-P384" cannot be upgraded without breaking every deployed peer simultaneously – a flag day that is operationally impossible across a fielded force. A protocol that negotiates "I support these algorithm suites, you support those, we agree on the strongest common one" upgrades gracefully as endpoints migrate at their own pace.

Certificates. Certificate profiles must accommodate new signature and key-encapsulation algorithm identifiers, and the validation path must not reject an unknown-but-policy-approved algorithm. The public-key infrastructure itself needs an agile root: if the certificate authority can only issue one algorithm, the PKI becomes the bottleneck regardless of how agile the endpoints are.

Stored data. Every encrypted record or signed object must record which algorithm and key protected it. Without that tag, a future system cannot decrypt or verify legacy data after the active algorithm changes – the data becomes unreadable not because the key was lost but because the system forgot which scheme it used. This metadata is what makes a migration reversible and what lets old and new ciphertext coexist during the transition.

A phased migration plan

With the inventory, the abstraction layer, and versioned artifacts in place, the migration itself becomes a controlled, reversible sequence rather than a flag day. A workable plan runs in five phases.

Phase 1 – inventory. Build and automate the CBOM, and triage entries by confidentiality lifetime and exposure. This phase produces the migration backlog and exposes the dependencies that would otherwise cause field failures.

Phase 2 – abstraction. Introduce the algorithm abstraction layer and route every existing cryptographic call through it. No application logic should invoke an algorithm directly. At the end of this phase the system is no more secure than before, but it is now changeable – the precondition for everything that follows.

Phase 3 – hybrid modes. Configure the layer to run a classical and a post-quantum algorithm together – for example a hybrid key establishment that combines an elliptic-curve exchange with a lattice-based key-encapsulation mechanism. The combined construction stays secure if either component is later broken, which hedges against both a quantum break of the classical algorithm and an unforeseen weakness in the newer post-quantum one. Roll hybrid modes out per environment behind policy, validating interoperability with allied and STANAG-governed systems before changing any default.

Phase 4 – prioritized migration. Using the inventory's risk ordering, migrate long-confidentiality and externally exposed data first, then work down to short-lived internal data. Measure coverage against the CBOM at each step so the program can report exactly what fraction of high-risk data is protected by post-quantum cryptography. The detailed compliance sequencing for this phase is laid out in the CNSA 2.0 migration roadmap.

Phase 5 – retirement. Only remove a classical-only algorithm once every dependent peer and every stored-data path has been re-encrypted or re-keyed under the new policy – which the inventory and stored-data tags let you verify rather than assume. Retirement is the last step precisely because it is the only irreversible one; everything before it can be rolled back if interoperability or performance regresses.

Common failure modes

Three mistakes recur across programs. The first is treating agility as a library swap – linking a post-quantum-capable library while leaving direct algorithm calls in application code, which produces a system that is no more agile than before. The second is migrating before inventorying, which guarantees missed dependencies that surface as field failures when an un-catalogued peer or firmware component cannot negotiate the new algorithm. The third is deleting the old algorithm too early, before every stored record and every peer has migrated, which renders legacy data unverifiable or unreadable. Each of these is avoided by the same discipline: inventory first, abstract before you migrate, and retire last.

What this means for procurement

Crypto-agility is cheapest when it is a requirement at contract award and most expensive when it is retrofitted into a fielded system. Programs specifying new defense software should require an algorithm abstraction layer, a maintained cryptographic bill of materials, and versioned cryptographic artifacts as acceptance criteria – not as a future enhancement. The systems being designed today will live through the post-quantum transition and at least one transition after it. Building them to swap algorithms cheaply is the difference between a configuration change and a re-fielding program.