Crypto Agility Implementation: From Architecture Principle to Working System

The phrase "crypto agility" has become so widely used in vendor materials that it has lost most of its precision. Vendors use it to mean "our product supports multiple algorithms." That is not what NIST means, and the gap between the two definitions has concrete consequences for organisations that believe they have achieved agility when they have only achieved configurability.

The Mosca inequality establishes the stakes. If the sum of your data sensitivity lifetime and your migration time exceeds the expected time to a cryptographically relevant quantum computer, you are already in the risk window. A crypto-agile architecture is the mechanism that makes migration time controllable. Without it, algorithm updates require individual code changes across every system that invokes cryptography directly. The migration time expands. The risk window grows. A system that is genuinely crypto-agile can execute a fleet-wide algorithm update in hours, not months. That is the value. For context on how migration time feeds into the urgency calculation, see the Q-Day Timeline Calculator.

This article is an implementation guide, not a conceptual overview. The principle is covered in Crypto Agility: The Architecture Principle That Future-Proofs Your Stack. This article goes one level deeper: five independently maintainable implementation layers, specific enough that a working engineer can begin from the brief. Each layer has its own tooling, its own standards basis, and its own common failure mode. All five are required. Partial implementation creates migration gaps that are harder to find than no agility at all.

What Crypto Agility Actually Means (and What It Does Not)

A system is crypto-agile when algorithm selection is separated from algorithm invocation at every layer of the stack. That separation must hold at the network protocol layer, the application cryptography layer, the key management layer, and the certificate infrastructure layer simultaneously. A system that achieves separation at three of the four layers is not partially agile. It has three layers of agility and one binding constraint. The binding constraint is what the migration timeline is determined by.

Crypto agility is not:

• Configurable algorithm names in a settings file. That is configuration management. The file still requires per-system deployment to update.
• Simultaneous support for multiple algorithm versions. That is backward compatibility.
• A documented migration plan. That is governance.

NIST SP 800-131A Rev 2 (2019) established the acceptable, deprecated, and disallowed framework for algorithm transition. ETSI TS 119 312 addresses algorithm agility in electronic signatures and infrastructure. NIST IR 8547 IPD (November 2024) applies that same framework to the post-quantum transition, targeting deprecation of RSA, ECDH, ECDSA, and DSA from new systems by 2030 and disallowing all use by 2035. Crypto agility is the operational property that makes compliance with those deprecation timelines manageable rather than disruptive.

Layer 1: Cryptographic Abstraction

OpenSSL 3.0+ Provider Mode

OpenSSL 3.0 introduced the provider model as the mechanism for algorithm abstraction in C and C++ applications. In the provider model, algorithm implementations are decoupled from the OpenSSL core and loaded as provider modules at runtime. The application never invokes a named algorithm directly; it calls through the EVP (envelope) API, and the provider configuration determines which implementation is loaded.

The correct implementation requires every algorithm call to go through an EVP API call rather than a low-level, algorithm-specific function. The distinction matters. An application calling RSA_generate_key() directly is not using the provider model; it is hard-coding RSA at the function call site. An application calling EVP_PKEY_keygen() with the algorithm specified by configuration is using the provider model correctly. When the provider configuration changes from RSA to ML-KEM (FIPS 203), the application code does not change. Only the provider configuration does.

The Open Quantum Safe (OQS) Project provides an experimental OQS Provider for OpenSSL that implements ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). This is appropriate for development and testing. Production deployments in regulated sectors require FIPS 140-3 validated implementations. FIPS 140-3 validated PQC providers are a small and growing list as of mid-2026; verify current validation status against the NIST Cryptographic Module Validation Programme (CMVP) at csrc.nist.gov before committing to a production implementation path.

Java JCA/JCE Provider Chains

Java cryptographic abstraction uses the Java Cryptography Architecture (JCA) and Java Cryptography Extension (JCE) provider mechanism. Providers are registered in java.security and invoked by algorithm name string. The provider chain determines which implementation handles each algorithm request. Inserting a PQC provider ahead of the default providers routes ML-KEM, ML-DSA, and SLH-DSA requests to PQC implementations before the chain falls through to classical algorithms.

Bouncy Castle is the primary Java PQC library in production use, with support for FIPS 203, FIPS 204, and FIPS 205 algorithm families. Applications written against KeyPairGenerator.getInstance("ML-KEM") do not require code changes when the provider implementation is updated. The provider version increments; the application call site does not change. This is the abstraction property that makes the layer valuable.

The analogous abstraction failure mode in Java is calling algorithm-specific constructors directly, such as new RSAPublicKeySpec(), rather than going through the provider API. Those call sites are hard-coded algorithm dependencies that will each require individual code changes during migration. An agility audit of a Java codebase should enumerate direct algorithm constructor calls as the primary finding. For organisations that need to run discovery at scale before auditing manually, Automated Cryptographic Discovery Tools for PQC covers the tooling options.

Layer 2: Algorithm Policy Server

An algorithm policy server is a centralised service that maintains the authoritative list of permitted cryptographic algorithms for all consuming systems. Systems query the policy server at startup and on a configurable refresh interval. The policy server, not the application and not the individual system administrator, determines which algorithms are active across the fleet.

Without a central policy server, an algorithm update requires individual deployments to each consuming system. The per-system deployment is the bottleneck that makes algorithm updates slow and error-prone at enterprise scale. A policy server converts a fleet-wide algorithm change into a single policy update that propagates automatically. That is why this layer is independent of the abstraction layer: the abstraction layer makes algorithm switching possible per-system; the policy server makes it consistent across systems.

The minimum requirements for a policy server that is useful for PQC migration:

• A versioned algorithm catalogue keyed to NIST IR 8547 categories: Category 1 (permitted), Category 2 (deprecated for new systems after 2030, permitted for existing until 2035), Category 3 (disallowed after 2035)
• Policy push to consumers via webhook or polling on a defined interval
• Algorithm sets defined by deployment context: TLS endpoints require different algorithm sets from code signing pipelines, which differ from VPN gateways
• Audit log of all policy changes with timestamp and authoriser

The NIST IR 8547 IPD deprecation status maps directly to policy server rules. RSA in all key sizes: Category 2, permitted for existing systems until 2035, not permitted for new deployments after 2030. ML-KEM (FIPS 203): Category 1, permitted. AES-256-GCM: Category 1, permitted. AES-128-GCM: Category 1 but weaker than AES-256-GCM; flag for upgrade in the policy server independently of the quantum risk classification. Use AES-256-GCM.

The policy server pattern is not defined in a single published standard. It is an architectural pattern that several organisations implement as a feature of their secrets management platform (HashiCorp Vault) or their PKI management layer. The underlying logic follows from NIST guidance on fleet-wide algorithm management. A detailed treatment of how the inventory layer supports the policy server is in CBOM Foundation and PQC Readiness.

Layer 3: Negotiation Protocols With Hybrid Support

TLS 1.3 Hybrid Key Exchange

TLS 1.3 (RFC 8446, August 2018) is the correct transport protocol for hybrid key exchange during the migration period. Hybrid key exchange combines a classical algorithm with a post-quantum algorithm in a single handshake. The specific hybrid approach under IETF standardisation combines X25519 (a classical elliptic-curve Diffie-Hellman group) with ML-KEM-768 (the NIST FIPS 203 parameter set targeting 128-bit classical and 128-bit post-quantum security), or P-256 with ML-KEM-512 for environments where P-256 is required.

The hybrid design has a specific security property: the combined key inherits the security of the strongest algorithm in the pair. If a post-quantum algorithm is later found to have a weakness, the classical component maintains forward secrecy. If a CRQC becomes available and breaks the classical component, the post-quantum component provides the security. The hybrid approach is conservative by design during a period when post-quantum algorithm confidence is high but not yet confirmed at the operational scale required for classical algorithm retirement.

One important precision on implementation references: X25519Kyber768Draft00 is an IETF internet draft, not a published RFC. It should not be referenced as an RFC. The IETF TLS working group is progressing standardisation of ML-KEM hybrid groups for TLS 1.3 as of mid-2026; the specific draft number and status should be verified before referencing it in implementation documentation. The underlying technical approach (X25519 plus ML-KEM hybrid) may be cited without a specific RFC because the component standards (RFC 8446 for TLS 1.3; FIPS 203 for ML-KEM) are published. Similarly, RFC 9496 defines the ristretto255 and decaf448 elliptic curve groups; it is not a PQC standard and should not be conflated with PQC migration work.

IKEv2 RFC 9370 Multiple Key Exchanges

For VPN gateways and IPsec tunnels, RFC 9370 (Multiple Key Exchanges in IKEv2, published May 2023) is the standards basis for hybrid key exchange in IKEv2. This is a published RFC, not a draft. Its status should be cited accurately.

RFC 9370 allows IKEv2 to negotiate multiple key exchange algorithms and combine their outputs through a key derivation function (KDF). The combined key material inherits the security properties of the strongest algorithm negotiated. The practical implementation: configure IKEv2 with both a classical Diffie-Hellman group and an ML-KEM encapsulation group. IKEv2 daemons supporting RFC 9370 include strongSwan and Libreswan. The negotiated set must include both a classical algorithm for compatibility with peers that have not yet migrated, and an ML-KEM group for post-quantum security where both peers support it. Fallback to classical-only is acceptable during the transition period.

Layer 4: Key Rotation Orchestration

Key material must be rotatable independently of the algorithm that generated it. A crypto-agile system does not only support new algorithms at the protocol layer; it can re-key under new algorithms without service interruption. The key rotation layer is where algorithm agility intersects with operational continuity.

HashiCorp Vault transit backend. Vault's transit secrets engine provides a software abstraction over key operations: encrypt, decrypt, sign, verify, HMAC. Keys are versioned. The current version handles new operations; previous versions are retained for decryption of material encrypted under earlier key versions. Key rotation is triggered by API call and propagates without redeployment of consuming applications.

For PQC migration using Vault, the path is: introduce an ML-KEM or ML-DSA key type alongside the existing RSA or ECDH key; re-encrypt or re-sign material under the new key type as a background operation; deprecate the old key version after re-encryption is confirmed complete. This is a managed re-keying operation with no service interruption, rather than a migration project requiring application downtime. Vault's PQC algorithm support depends on the Go cryptography library and the Vault version in use; verify current support for FIPS 203 and FIPS 204 against current Vault documentation before committing to this path for production use.

AWS KMS multi-region key rotation. AWS KMS supports automatic key rotation for symmetric AES-256 keys and manual rotation for asymmetric key types. Multi-region keys replicate key material across regions for latency and availability. For PQC migration, verify current AWS KMS algorithm support against current AWS documentation. Do not assume ML-KEM key type support without explicit verification; the support status was evolving as of mid-2026 and should be confirmed before building it into a programme timeline.

The key rotation layer's failure mode is a mismatch between the key type that the policy server has permitted and the key type that the key rotation system supports. The policy server can push an ML-KEM-only policy; if the key management system cannot generate ML-KEM key material, the policy change produces a failure rather than a migration. The dependency must be sequenced: confirm key management support for the new algorithm type before the policy server enforces it.

Layer 5: Certificate Authority Rotation Cadence

90-Day Maximum for Hybrid Certificates

X.509 certificates bind a public key to an identity. Hybrid certificates contain two public keys: a classical key (ECDSA P-256 or P-384) and a post-quantum key (ML-DSA from FIPS 204). Both keys are signed by the issuing CA. The relying party verifies both signatures, providing classical security for peers that do not support post-quantum algorithms and post-quantum security for peers that do.

For hybrid certificates, a 90-day maximum validity period is the recommended rotation cadence. Three factors support this.

The browser industry has moved toward 90-day certificate lifetimes. Google's 2023 ballot in the CA/Browser Forum proposed 90-day maximum validity for all web TLS certificates. Apple has enforced 398-day limits since 2020. The direction is unambiguous and 90-day rotation will be an industry baseline within the current migration period. Building it in now avoids a forced cadence change later.

Short certificate validity limits the exposure window from a compromised certificate. It also reduces the risk that an algorithm deprecation takes effect mid-lifecycle on a long-lived certificate, requiring emergency replacement. A certificate issued today with a 3-year validity may expire after the NIST IR 8547 IPD 2030 deprecation milestone for new Category 2 deployments. A 90-day certificate issued today will never encounter that problem.

90-day rotation is only operationally practical with automation. Automated certificate lifecycle management is the prerequisite for making 90-day rotation sustainable at enterprise scale. RFC 8555, the Automatic Certificate Management Environment (ACME) protocol published March 2019, is the dominant mechanism for public TLS certificates. ACME automates certificate issuance and renewal through a standardised API; Let's Encrypt, Smallstep, and HashiCorp Vault's PKI secrets engine all support it. For enterprise PKI, alternative paths are equally valid: EST (RFC 7030, Enrolment over Secure Transport), SCEP (Simple Certificate Enrolment Protocol), and vendor-specific platforms such as Venafi, Microsoft ADCS, and Sectigo. The choice of mechanism depends on whether the certificate estate is predominantly public-facing or internal. Manual rotation at 90-day intervals across a large certificate estate is not operationally sustainable regardless of which automated mechanism is used.

Hybrid Certificate Format and Dual-Key Implications

A hybrid certificate doubles the key material and signature data relative to a classical-only certificate. Two public keys, two signatures from the issuing CA. This has implications for TLS handshake size that engineers should validate against their specific deployment constraints before assuming hybrid certificates are a drop-in replacement.

IETF standardisation work on composite signatures in X.509 certificates, specifically the draft-ounsworth-pq-composite-sigs family of drafts and related LAMPS working group work, was in active progress as of mid-2026. Production deployments should track IETF progress before committing to a specific hybrid certificate format. Do not reference a specific IETF draft number for composite signatures without verifying current status; draft numbers change as documents are revised. The published algorithm standard for the post-quantum component of a hybrid certificate is FIPS 204 (ML-DSA, August 2024).

Putting the Layers Together: Migration Sequence

The five layers have dependencies that determine the correct deployment sequence. Deploying them out of order creates either redundant work or broken dependencies.

Step 1: Deploy the abstraction layer. Update OpenSSL 3.x, Java JCA/JCE, and other cryptographic libraries to versions that support the provider and plugin model with PQC algorithm capability. This is the foundation. Without it, the policy server has nothing to push algorithm changes into, and the key rotation layer has no algorithm abstraction to route ML-KEM operations through.

Step 2: Build and configure the algorithm policy server. Encode the NIST IR 8547 IPD category taxonomy into the policy engine. Begin with Category 4 items: already-deprecated algorithms such as 3DES and RC4 that have no dependency on PQC standards and should be eliminated regardless. Then configure Category 2 deprecation timelines. The policy server is the control plane for the migration; it should be operational before the migration of any category begins.

Step 3: Configure hybrid negotiation protocols. Enable TLS 1.3 hybrid key exchange on all TLS-terminating endpoints using X25519 plus ML-KEM groups. Enable RFC 9370 on IKEv2 VPN gateways. This provides post-quantum security for data in transit while maintaining classical compatibility for peers that have not yet migrated. No existing security is degraded. The hybrid configuration adds post-quantum security without removing classical security.

Step 4: Deploy key rotation orchestration. Configure Vault or KMS with versioned key rotation. Introduce ML-KEM and ML-DSA key types alongside existing RSA and ECDH key types. Begin re-keying non-urgent material under new algorithms. This step can proceed in parallel with Step 3 and Step 5 because the dependencies are on the abstraction layer (Step 1), not on each other.

Step 5: Shorten certificate validity and migrate the CA. Move to 90-day certificate lifetimes using ACME automation. Issue hybrid certificates where both peers support them; issue classical certificates for legacy peers during the transition period. Plan for CA root rotation to a hybrid or post-quantum root within the programme timeline, tracking IETF progress on composite certificate formats before committing to a specific hybrid certificate specification.

The migration sequence preserves classical security throughout every step. At no point does the system's existing security degrade. Each deployed layer adds post-quantum security without removing what was there before. That property is the practical definition of a conservative migration path. For programme budgeting across these five layers, see PQC Migration Cost Benchmarks for Enterprise.

Common Misconceptions

A config file with algorithm names is crypto agility. Configuration management is not agility. The config file must be updated per-system and redeployed. A policy server propagates algorithm changes across the fleet without per-system deployment. The difference matters at 50 systems; it matters critically at 5,000.

TLS 1.3 already provides post-quantum security. TLS 1.3 (RFC 8446) provides the negotiation framework and the cipher suite abstraction. Post-quantum security requires specific configuration of hybrid key exchange groups (X25519 plus ML-KEM). Default TLS 1.3 deployments use ECDH key exchange, which is Category 2 per NIST IR 8547 IPD. The framework is crypto-agile. The default configuration is not post-quantum.

RFC 9496 is relevant to PQC migration. RFC 9496 defines the ristretto255 and decaf448 elliptic curve groups. It is not a post-quantum cryptography standard. The relevant post-quantum RFCs and standards are: RFC 9370 for IKEv2 hybrid key exchange; FIPS 203, 204, 205 for ML-KEM, ML-DSA, and SLH-DSA respectively; and RFC 8446 for the TLS 1.3 framework.

Upgrading OpenSSL completes the migration. OpenSSL 3.0 with a PQC provider implements Layer 1: cryptographic abstraction. The algorithm policy server, hybrid protocol configuration, key rotation orchestration, and certificate cadence remain as independent layers, each with its own tooling and its own deployment requirements. OpenSSL alone is one layer of five.