Key Management / Transition

Cryptographic Agility & PQC Operations

Cryptographic agility is the ability to replace or adapt cryptography across protocols, applications, hardware, firmware, and infrastructure while preserving security and operations. It is an inventory, architecture, deployment, and recovery capability—not a runtime switch that accepts any algorithm.

Agility starts with dependency discovery

NIST CSWP 39upd1, updated June 29, 2026, defines crypto agility in terms of replacing and adapting algorithms while preserving security and ongoing operations. The prerequisite is a maintained view of:

• applications, protocols, libraries, firmware, hardware, and provider services that perform cryptography;
• algorithms, modes, parameter sets, certificates, key types, and data formats in use;
• keys, versions, owners, data sensitivity, secrecy lifetime, and dependency scope;
• hard-coded identifiers, negotiation rules, pins, trust stores, and provider defaults;
• performance, message-size, storage, network, and device constraints; and
• external parties and vendors needed for a coordinated transition.

The key inventory identifies managed keys; the agility inventory extends to cryptography embedded outside the KMS.

Put algorithm choice behind policy, not arbitrary input

An agile design centralizes approved suites and transition state while preventing callers or attackers from selecting weak algorithms.

• Use versioned envelope, certificate, signature, and protocol formats with explicit algorithm identifiers.
• Bind identifiers and negotiation results to authentication so an attacker cannot downgrade them.
• Keep a narrow allowlist that distinguishes create/protect operations from legacy read/verify operations.
• Isolate provider-specific APIs behind tested service boundaries where that does not hide security-relevant behavior.
• Preserve exact historical parameters needed to decrypt or verify old material.
• Fail closed on unknown algorithms and formats; do not guess from key length or ciphertext shape.

Agility means controlled change. Supporting more algorithms at once also increases code, configuration, and attack surface.

Treat post-quantum migration as a system migration

The algorithms and standards are covered in Post-Quantum Cryptography. Key management also has to handle the operational differences:

NIST standardized ML-KEM, ML-DSA, and SLH-DSA in FIPS 203, FIPS 204, and FIPS 205. NIST currently lists potential errata for FIPS 203 and FIPS 204, so implementations should check the current publication pages and errata. A standard’s publication does not prove that a particular protocol profile, product, validation, or deployment is ready.

Stateful signatures make recovery state security-critical

NIST SP 800-208 approves the stateful hash-based signature schemes LMS and XMSS for specific applications. Unlike stateless ML-DSA and SLH-DSA, an LMS or XMSS signer must never reuse a one-time signature key. Reuse can make signature forgery computationally feasible.

The signing index is therefore protected cryptographic state, not disposable operational metadata:

• Advance and durably store the private-key state before releasing the corresponding signature.
• Prevent two active signers, cloned virtual machines, restored snapshots, or ordinary backup copies from allocating the same one-time signing state.
• Do not treat rollback to an older private-key backup as recovery. Use a design permitted by the selected profile, such as independent accepted keys or a distributed multi-tree construction defined by SP 800-208.
• Test power loss, process crash, storage failure, restore, failover, and concurrent signing for state reuse—not only whether the service resumes.
• Record remaining signing capacity, exhaustion thresholds, state transitions, and the replacement public-key distribution path in the inventory.

A successful post-crash signature does not prove safe recovery. The evidence must show that no previously allocated one-time state became available again.

Use coexistence and hybrid designs only with a defined construction

A transition may use parallel certificates, dual signatures, classical and PQC key establishment, or a protocol-defined hybrid combiner. “Use both” is not a complete design. Specify:

• whether success requires both components or either one;
• how shared secrets or authentication results are combined and context-bound;
• how downgrade and stripping attacks are detected;
• how failures are logged without silently falling back;
• how algorithm identifiers and public keys are authenticated; and
• when the classical component can be removed.

Hybrid security depends on the complete protocol and combiner. It should not be claimed merely because two algorithms appear in a handshake.

Migrate in measured, reversible stages

1. Discover: reconcile cryptographic dependencies and data secrecy lifetimes.
2. Prioritize: rank systems by risk, exposure, replacement lead time, and interoperability constraints.
3. Prepare: update policies, formats, interfaces, inventories, test vectors, capacity, and vendor commitments.
4. Pilot: deploy to a bounded population with telemetry for negotiation, failure, performance, and compatibility.
5. Coexist: make the new suite preferred for new protection while preserving a deliberately constrained old-data path.
6. Migrate: rotate keys and certificates, rewrap or re-encrypt data where needed, and update external trust relationships.
7. Retire: disable old protective use, observe, then remove algorithms, keys, code paths, and exceptions when dependencies are cleared.

Rollback should restore a known-good configuration without creating new weakly protected data. Define the rollback window, allowed legacy operations, data written during the pilot, and the condition that stops the rollout.

Prove the transition at the boundaries

Test more than algorithm correctness:

• known-answer and negative cryptographic tests;
• certificate, protocol, and message-format interoperability;
• malformed, unknown, and downgrade inputs;
• HSM/KMS failover, quotas, latency, and recovery;
• mixed-version clients and historical decrypt or verify paths;
• inventory accuracy before and after migration; and
• disablement of the old protective path.

A successful laboratory handshake proves interoperability for those versions and parameters. It does not prove production capacity, ecosystem support, downgrade resistance in every path, or complete migration of stored data.

Primary references

• NIST CSWP 39upd1: Considerations for Achieving Crypto Agility — verified the current NIST definition, strategies, practices, challenges, and June 2026 update status.
• NIST NCCoE Migration to Post-Quantum Cryptography — verified the operational need for discovery, planning, interoperability, and performance evaluation.
• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard — verified the final ML-KEM standard and the current potential-errata notice.
• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard — verified the final ML-DSA standard and the current potential-errata notice.
• NIST FIPS 205: Stateless Hash-Based Digital Signature Standard — verified the final SLH-DSA standard.
• NIST SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes — verified LMS/XMSS state-management, one-time-key reuse, crash-safety, and distributed-signing constraints.