<p>Most organisations do not have a cryptography problem. They have a hardcoded cryptography problem. The distinction matters because the solution to the first is algorithm replacement, and the solution to the second is architecture redesign. Post-quantum migration forces both, but the architectural work is what takes years and what the PQC literature consistently underweights. These six principles are the structural foundation before a single line of migration code gets written.</p>

<h2>What crypto agility means, and why most systems do not have it</h2>

<p>Crypto agility is the property of a system or codebase that allows the cryptographic algorithms, key sizes, and parameters it uses to be updated without requiring changes to the surrounding application logic or infrastructure. A system with high agility swaps RSA-2048 for ML-KEM-768 by changing a configuration parameter or a library call. A system with low agility requires a code rewrite, a hardware refresh, or a protocol upgrade that cascades through dependent systems. IETF RFC 7696 ("Guidelines for Cryptographic Algorithm Agility," November 2015) defines four minimum properties an agile system must have: the ability to express algorithm identifiers in protocol messages; the ability to negotiate or select algorithms at runtime; the ability to add new algorithm identifiers without breaking existing implementations; and the ability to deprecate algorithms without requiring a flag day.</p>

<p>Most enterprise systems built between 2000 and 2020 fail all four. Algorithms are hardcoded in TLS configurations, embedded in library call signatures, baked into HSM firmware that cannot be updated, or implicit in protocol selections that predate algorithm negotiation as a concept. The previous comparable transition, DES to AES, stayed within the same symmetric/asymmetric framework without protocol-layer changes. RSA to ML-KEM is a different class of problem because it affects every public-key operation across the entire stack. NIST IR 8547 (November 2024) documents the scale of the transition.</p>

<p>NSA CNSA 2.0 (CNSSP 15, September 2022) makes agility an explicit requirement for national security system operators: systems must support migration to new algorithms as part of the CNSA 2.0 transition. Enterprises in the NSS supply chain face this as a contractual obligation. Everyone else faces it as the architectural precondition for meeting any migration deadline that arrives between now and 2035.</p>

<h2>Principle 1: Algorithm abstraction layer</h2>

<p>Application code should call a cryptographic API that accepts an algorithm identifier parameter, not a hardcoded call to <code>RSA.encrypt()</code> or <code>ECDSA.sign()</code>. The algorithm identifier is resolved to a concrete implementation by an abstraction layer that can be updated independently of the application. This is the principle stated in IETF RFC 7696 Section 4 and elaborated in NIST NCCoE SP 1800-38B migration patterns.</p>

<p>In practice: OpenSSL 3.x's provider architecture loads post-quantum algorithm implementations (including OQS-OpenSSL from the Open Quantum Safe project) as providers without application-layer changes. Java applications should use the JCA provider interface with a PQC-capable provider such as Bouncy Castle FIPS 1.0.2+, which includes ML-KEM and ML-DSA. For .NET, System.Security.Cryptography's abstraction layer is the correct insertion point for PQC-capable implementations.</p>

<p>The same principle applies to key storage. A key stored as "RSA-2048, key material: [bytes]" cannot be migrated without replacing the key material and updating all references. A key stored with algorithm metadata separate from the key material, following KMIP v2.1 or PKCS#11 v3.1 key metadata standards, can be migrated by updating the algorithm field and rotating the key. That is a configuration change rather than a code change. The difference, at scale, is months of migration time.</p>

<h2>Principle 2: Key wrap and algorithm-independent key identifiers</h2>

<p>Key wrapping, the encryption of a key for storage or transport using another key, creates a migration dependency that is easy to miss until it becomes critical. If the unwrap operation is performed using RSA-OAEP and RSA is subsequently deprecated, all wrapped keys in an HSM become inaccessible unless the unwrap operation is migrated first. Crypto-agile key management requires three properties: the key wrap algorithm must be stored alongside the wrapped key; re-wrapping capability must exist to unwrap under the current algorithm and rewrap under the new one without exposing the plaintext key in an unprotected state; and HSM firmware must support multiple wrap algorithms simultaneously during the transition period. NIST SP 800-57 Part 1 Rev 5 covers the key management requirements; PKCS#11 v3.1 specifies the wrapping mechanism interface.</p>

<p>KMIP v2.1 (OASIS Standard, 2021) supports algorithm-agnostic key management through its cryptographic algorithm attribute field. HSM and KMS solutions that implement KMIP v2.1 can manage keys with different algorithm attributes within the same key store. For enterprises migrating from RSA to ML-KEM, KMIP v2.1 compliant key management infrastructure is the prerequisite for managing the parallel operation period, where classical and post-quantum keys must co-exist without mutual interference.</p>

<h2>Principle 3: Parameter rotation design</h2>

<p>Parameter rotation is the ability to change cryptographic parameters on a schedule or in response to a deprecation event without service disruption. Systems designed for rotation have key versioning, so every key carries a version identifier that determines the algorithm and parameters used to generate it; negotiated parameter selection, following the TLS model where client and server agree on parameters at connection time rather than hardcoding them; and forward-compatible message formats, where encrypted data carries sufficient metadata to identify the algorithm needed for decryption, so archives remain readable under future implementations. IETF RFC 7696 Section 5 and NIST NCCoE SP 1800-38B both address this design pattern.</p>

<p>TLS 1.3 (IETF RFC 8446) is the reference implementation for parameter rotation in network protocols. Adding ML-KEM-768 to the supported key exchange list on both client and server allows hybrid deployment via IETF draft-ietf-tls-hybrid-design, combining X25519 with ML-KEM-768 in a single handshake and deriving the session key from both shared secrets via a KDF. The session key is secure if either component is secure. For internet-facing services, this is why hybrid TLS is the recommended first step: it provides parameter rotation capability for the key exchange component with minimal disruption to existing clients.</p>

<p>For stored data, parameter rotation requires a re-encryption pipeline that processes old archives incrementally during a parallel-operation window. The pipeline must be idempotent, meaning a record re-encrypted twice produces the same result as re-encrypting once, and must update algorithm metadata on each record atomically. At petabyte scale, this is an infrastructure project in its own right.</p>

<h2>Principle 4: Hybrid operation as a first-class architectural state</h2>

<p>Hybrid operation is the period during which a system simultaneously serves classical-only clients with RSA or ECDH and post-quantum-capable clients with ML-KEM hybrid. Most migration planning treats this as a temporary workaround. That framing is incorrect about the duration. NSA CNSA 2.0 specifies migration milestones from 2026 (firmware and operating systems) through 2030 (most software) to 2033 (network equipment and hardware cryptography). Those timelines imply a minimum seven-year hybrid operation period for complex infrastructure. Architects who design hybrid operation as a short-lived transition build technical debt that materialises in 2028 to 2030 when migration pressure intensifies.</p>

<p>Key design decisions during hybrid operation: generate both an RSA keypair and an ML-KEM keypair for services where clients may present either, stored under the same key identifier with algorithm differentiation in the version field; use the KDF concatenation approach from IETF draft-ietf-tls-hybrid-design for session key derivation so the session key is secure if either the classical or quantum-resistant component holds; and consider dual-certificate deployments or composite signature schemes, as specified in IETF draft-ounsworth-pq-composite-sigs, for PKI where both classical and ML-DSA certificates are presented simultaneously during the transition.</p>

<h2>Principle 5: Discovery before redesign</h2>

<p>None of the preceding four principles can be applied without knowing what exists. The prerequisite for all architecture work is a cryptographic bill of materials: a structured inventory of every cryptographic algorithm, key size, protocol, certificate, and library in the system scope, mapped to the component using it. NIST NCCoE SP 1800-38B provides the CBOM methodology. IBM Research's cbomkit automates CBOM generation for compiled binaries and container images. SCA tooling with cryptographic function detection handles source code repositories.</p>

<p>The CBOM reveals the actual cryptographic surface area, which is consistently larger than system owners expect. Typical findings include hardcoded algorithm strings in application configuration files; TLS cipher suite overrides in load balancer configurations that are inconsistent with the intended standard; cryptographic library calls that bypass the intended abstraction layer; and embedded cryptographic libraries in third-party dependencies that are outside the organisation's standard update process. Each of these is a crypto agility gap. None of them shows up in a TLS certificate scan.</p>

<p>For the methodology to build and maintain a cryptographic asset register alongside the CBOM, see our guide at <a href="/insights/cryptographic-asset-register-build-guide/">how to build a cryptographic asset register</a>.</p>

<h2>Principle 6: Sequence migration by layer, not by business unit</h2>

<p>Not all cryptography is equally complex to migrate. The stack has a natural sequence:</p>

<p><strong>Protocol layer (6 to 18 months):</strong> TLS 1.3 hybrid key exchange, IPsec IKEv2 with IETF RFC 9370 multiple key exchange support, SSH hybrid key exchange. Controlled at the infrastructure layer with no application code changes required. The lowest-risk starting point.</p>

<p><strong>Library layer (12 to 36 months per application):</strong> Applications calling OpenSSL, BoringSSL, Bouncy Castle, or NSS. Migration complexity depends on whether calls use an algorithm identifier parameter (agile) or a hardcoded algorithm function (not agile). Codebase age and test coverage are the two primary timeline drivers.</p>

<p><strong>Protocol and format layer (24 to 60+ months):</strong> Systems where the cryptographic algorithm is embedded in a data format standard: CMS/PKCS#7, S/MIME, PDF digital signatures, code signing formats, JWS/JWT. Format evolution may require changes to inter-organisation protocols. The timeline depends on the adoption velocity of partner systems.</p>

<p><strong>Hardware layer (typically 5+ years for installed base):</strong> HSMs, smart cards, TPMs with algorithm support in firmware or silicon. Migration depends on vendor roadmap and hardware refresh cycles. This layer must be planned now because it cannot be rushed.</p>

<p>Start with the protocol layer, where migration is fastest and risk is lowest. New traffic on internet-facing services is protected from HNDL immediately. The library and format layers require longer lead times and should be sequenced based on data confidentiality lifetime from the CBOM. The hardware layer must be planned in advance: engage HSM and smart card vendors on PQC firmware support timelines now, not when the 2030 deadline is visible on the horizon.</p>

<h2>ML-KEM and ML-DSA parameter selection: the numbers architects need</h2>

<p>NIST FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) define three parameter sets each. The selection for enterprise deployment:</p>

<table>
  <thead>
    <tr>
      <th>Algorithm</th>
      <th>Parameter Set</th>
      <th>Public Key</th>
      <th>Ciphertext / Signature</th>
      <th>Use Case</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>ML-KEM (FIPS 203)</td>
      <td>ML-KEM-768</td>
      <td>1,184 bytes</td>
      <td>1,088 bytes</td>
      <td>General-purpose TLS and application key exchange</td>
    </tr>
    <tr>
      <td>ML-KEM (FIPS 203)</td>
      <td>ML-KEM-1024</td>
      <td>1,568 bytes</td>
      <td>1,568 bytes</td>
      <td>National security systems (CNSA 2.0 requirement)</td>
    </tr>
    <tr>
      <td>ML-DSA (FIPS 204)</td>
      <td>ML-DSA-65</td>
      <td>1,952 bytes</td>
      <td>3,309 bytes</td>
      <td>General-purpose digital signatures</td>
    </tr>
    <tr>
      <td>ML-DSA (FIPS 204)</td>
      <td>ML-DSA-87</td>
      <td>2,592 bytes</td>
      <td>4,627 bytes</td>
      <td>High-sensitivity and NSS (CNSA 2.0)</td>
    </tr>
    <tr>
      <td>SLH-DSA (FIPS 205)</td>
      <td>SHA2-128s</td>
      <td>32 bytes</td>
      <td>7,856 bytes</td>
      <td>Long-lived signatures (code signing, CA certificates)</td>
    </tr>
    <tr>
      <td>FN-DSA (FIPS 206)</td>
      <td>FN-DSA-512</td>
      <td>897 bytes</td>
      <td>690 bytes</td>
      <td>Bandwidth-constrained environments; complex implementation</td>
    </tr>
  </tbody>
</table>

<p>Performance planning numbers, indicative and hardware-dependent: ML-KEM-768 TLS key exchange adds approximately 1 to 2ms to TLS handshake time compared to X25519, dominated by larger key and ciphertext sizes (approximately 2KB bandwidth overhead per handshake). Hybrid key exchange with X25519+ML-KEM-768 adds approximately 2 to 3ms and 3KB overhead. ML-DSA-65 signatures are 3,309 bytes versus 64 bytes for ECDSA P-256 (raw IEEE P1363 format; DER-encoded ASN.1 form is 70-72 bytes in TLS/X.509), a 52x size increase that matters for certificate chain depth, JWT payload budgets, and code signing manifests. Benchmark against actual deployment hardware; published figures from the Open Quantum Safe project give the directional reference.</p>

<h2>Starting in 2026: five concrete actions in order</h2>

<p>For an architect beginning this work now, the sequence:</p>

<p>First: run a CBOM scan to identify the actual cryptographic surface. Use IBM Research cbomkit for binaries and container images, SCA tooling for source repositories. The findings will surprise you.</p>

<p>Second: deploy hybrid TLS on internet-facing services, specifically X25519+ML-KEM-768 per IETF draft-ietf-tls-hybrid-design. Target timeline: six months. This is the only action that provides HNDL protection for new traffic today.</p>

<p>Third: confirm the key management layer uses KMIP v2.1 or equivalent algorithm-agnostic storage. If it does not, key wrap migration planning starts now.</p>

<p>Fourth: review library calls in the two highest-criticality application codebases. Identify hardcoded algorithm calls and map them to the abstraction layer redesign backlog.</p>

<p>Fifth: engage the HSM vendor on PQC firmware roadmap. Get a written response. Document the timeline in the migration programme plan. Hardware is the dependency no amount of engineering velocity can shorten.</p>

<p>The programme management layer above these five architecture actions, including milestone sequencing, risk register maintenance, and executive reporting, is covered in our roadmap guide at <a href="/insights/pqc-migration-strategy-roadmap-cybersecurity-leaders/">PQC migration strategy roadmap for cybersecurity leaders</a>.</p>