Preparing AI Infrastructure for Post-Quantum Cryptography

AI infrastructure is built to last. Accelerators are amortised over years, model weights and training data are valuable for longer, and the identities of machines, operators and agents need to outlive any single deployment. That makes post-quantum cryptography an infrastructure question now, not a future one. Data captured today can be decrypted once a capable quantum computer exists, and a signature scheme that is broken in 2035 will have signed a decade of records before then.

The standards and dates are now settled enough to plan against. This post sets them out, proposes a migration order for AI systems, and describes how Tenzro applies hybrid post-quantum keys today.

The standards

In August 2024 NIST published three final standards:

• ML-KEM (FIPS 203), a lattice-based key-encapsulation mechanism, the general-purpose replacement for elliptic-curve and RSA key exchange.
• ML-DSA (FIPS 204), a lattice-based signature scheme, the general-purpose replacement for ECDSA, EdDSA and RSA signatures.
• SLH-DSA (FIPS 205), a stateless hash-based signature scheme. Its signatures are much larger and slower, but its security rests only on hash functions, which makes it a conservative choice for long-lived roots such as firmware signing.

In March 2025 NIST selected HQC, a code-based KEM, as a backup to ML-KEM that does not depend on lattices.

For transport, the IETF published RFC 10024 in August 2026, defining hybrid key agreement for TLS 1.3 that combines ML-KEM with classical ECDHE, including X25519MLKEM768. A hybrid holds as long as either component holds.

The dates

NIST's transition draft, IR 8547, proposes deprecating quantum-vulnerable algorithms at 112 bits of security after 2030 and disallowing ECDSA, EdDSA, RSA and the classical key-establishment schemes after 2035. It is an initial public draft, but it is the clearest statement of NIST's intended timeline.

In Europe, the NIS Cooperation Group's coordinated implementation roadmap asks Member States to start first steps by the end of 2026, transition high-risk use cases no later than the end of 2030, and complete the transition for as many systems as feasible by 2035.

For a data centre or AI factory commissioned today, 2030 and 2035 fall well inside the hardware's life.

Where AI infrastructure is exposed

Not every use of cryptography is equally urgent. A useful ordering for AI systems:

1. Key exchange on links carrying sensitive data. Prompts, documents, model weights in transit and KV caches crossing sites are exposed to capture now and decryption later. This is the most urgent item, and hybrid TLS makes it the easiest.
2. Long-lived identities. Machine identities, operator keys, signing keys for model manifests and release artefacts. A signature must stay unforgeable for as long as anyone relies on what it signed.
3. Records that must stay verifiable. Inference receipts, audit trails, finality certificates and evidence packs are evidence only if their signatures remain unforgeable for the retention period.
4. Hardware roots. TPMs, secure enclaves and passkey authenticators sign with P-256 today. They are the slowest part to change, because the change is in silicon and firmware.
5. Symmetric primitives. AES-256 and SHA-2 or SHA-3 at adequate sizes are not on the deprecation schedule. Check key lengths, then move on.

Migration principles

• Inventory first. You cannot migrate what you have not found. Include keys in configuration, firmware and third-party agents.
• Go hybrid. Combine a classical and a post-quantum algorithm so that a flaw in a young algorithm does not become a regression. Both RFC 10024 and composite signatures follow this pattern.
• Design for agility. Carry algorithm identifiers and allow key rotation without re-registering identities.
• Be honest about the hardware gap. If your authenticators cannot hold a post-quantum key, derive or enrol one alongside and require it once enrolled, rather than waiting for new silicon.

How Tenzro applies hybrid post-quantum keys

Tenzro uses hybrids throughout, and states plainly where a classical component remains.

• Transport. Every node endpoint offers X25519MLKEM768 first, so two nodes always agree on it. Validator channels use their own handshake combining X25519 and ML-KEM-768. A validator's network endpoint is disclosed only to committee members, sealed with both key exchanges and AES-256-GCM.
• Consensus. A validator's consensus key is a composite of ECDSA P-256 and ML-DSA-65. The P-256 half lives in a TPM or Secure Enclave. Because those chips cannot hold an ML-DSA key, the ML-DSA-65 half is derived from the machine's hardware root for each signature and wiped afterwards. Checkpoint certificates, which make finality portable, are signed by that composite through hardware-certified session keys.
• Transactions. Native transactions carry an Ed25519 signature and an ML-DSA-65 signature, and the verifier requires both, so breaking one algorithm does not forge a transaction.
• Passkeys. WebAuthn authenticators sign only with P-256. An account can enrol an ML-DSA-65 key for a passkey in chain state; from then on, every signature by that passkey must carry the ML-DSA-65 leg, so the P-256 leg alone cannot pass.
• Trust documents and receipts. Serving nodes' receipt keys carry an ML-DSA-65 leg where the hardware root provides one, bound to the operator by a composite signature.

The remaining classical component is worth naming. To let other chains verify Tenzro finality cheaply, finality is also published as a Groth16 proof over BN254, which relies on pairing-based cryptography that a quantum computer would break. That proof is a convenience for verifiers on those chains; the certificates themselves carry the post-quantum signatures, and anyone who can check ML-DSA-65 can verify them directly.

What this means for infrastructure leaders and policy makers

Treat 2030 as the planning date for high-risk systems, which in AI means anything carrying regulated data or anchoring identity. Turn on hybrid key exchange now; it is standardised and widely deployed. Put post-quantum signatures on anything that must remain evidence for years, starting with identities, receipts and release artefacts. Ask hardware suppliers when TPMs and authenticators will hold post-quantum keys natively, and in the meantime use designs that derive or enrol a post-quantum key alongside the hardware key.

Where Tenzro fits

Built: X25519MLKEM768 on every node endpoint, X25519 plus ML-KEM-768 validator channels and sealed endpoint disclosure, composite ML-DSA-65 and P-256 consensus keys with the classical half in hardware, hybrid Ed25519 and ML-DSA-65 transaction signatures, and enrolled ML-DSA-65 legs for passkeys. Classical by design today: Groth16 finality proofs for verification on other chains. SLH-DSA and HQC are not used. The network is live in preview; governance decides the steps to testnet and mainnet.