PKCS#11 3.2 ML-KEM HSM: what changes for your PKI?

PKCS#11 3.2 ML-KEM HSM support means a hardware security module can generate, store and use ML-KEM (FIPS 203) and ML-DSA (FIPS 204) keys through the standard OASIS PKCS#11 v3.2 interface. Applications such as certificate authorities, VPN gateways and remote access platforms can then keep post-quantum private keys inside protected hardware, the same way they already do for RSA and ECDSA keys.

For operators of OT and critical infrastructure, this is a practical question. Substations, water plants and production sites often sit behind VPN gateways that authenticate with certificates. The CA keys behind those certificates usually live in an HSM. Moving that trust chain to post-quantum algorithms depends on what the HSM’s PKCS#11 library can do, which key formats it accepts and whether its FIPS 140-3 validation covers the new algorithms.

Does PKCS#11 v3.2 support ML-KEM and ML-DSA?

Yes. OASIS PKCS#11 v3.2 is the first version of the standard to define ML-KEM and ML-DSA mechanisms, along with a new API for key encapsulation.

A presentation to the IETF LAMPS working group at IETF 123 summarised the scope of the v3.2 draft: it covers ML-KEM, ML-DSA, Hash-ML-DSA, SLH-DSA, Hash-SLH-DSA, with LMS/HSS already present since v3.1. Because a KEM does not work like RSA encryption or Diffie-Hellman, v3.2 adds 2 new functions for encapsulation, decapsulation. One of them is C_EncapsulateKey, which takes a public key handle and returns a ciphertext plus a new secret key object inside the token.

Two design decisions matter for PKI teams:

• Signature context: FIPS 204 lets the signer bind an optional context string to an ML-DSA signature. The PKCS#11 technical committee confirmed that context support will be there in v3.2, passed as a mechanism parameter.
• No external mu: PKCS#11 will not let an application calculate the ML-DSA message representative (mu) outside the token. The committee described this as a strong position, already discussed in OASIS. In practice, the whole message or a defined pre-hash variant goes to the HSM.

What is the difference between seed and expanded ML-KEM private keys?

A seed key is the 64-octet random value an ML-KEM key pair is generated from. An expanded key is the full decapsulation key derived from that seed. You can always compute the expanded key from the seed, but you can never get the seed back from the expanded key.

RFC 9935, published by the IETF LAMPS working group, explains that both the expanded private key and the public key can be deterministically derived from the seed using ML-KEM.KeyGen_internal(d,z) (algorithm 16) using the first 32 octets as d and the remaining 32 octets as z. The size difference is large:

Source: IETF RFC 9935 (2026), ASN.1 module and private key format sections.

The IETF position is clear. RFC 9935 states that the seed-only format is RECOMMENDED, as it is the most compact representation. The ASN.1 structure also allows a “both” option holding the seed and the expanded key together. If you use it, check on import that the two match, because a mismatched pair can make keys behave differently on different systems.

Storage size is a minor issue. Provenance is the real one. A seed lets any compliant implementation regenerate the exact same key pair, and checking that it reproduces the stored public key is a simple integrity test. An expanded key alone does not allow that check.

Can ML-KEM private keys be exported or backed up between HSMs?

Technically yes, using the usual PKCS#11 wrap and unwrap operations, provided the key was created as extractable. Whether the target HSM accepts the key depends on the format the source HSM kept, and the standards bodies have not fully agreed on that.

In PKCS#11, export rules are set by object attributes such as CKA_EXTRACTABLE and CKA_SENSITIVE, and keys leave the token only wrapped under another key. For seed-based transfer, the committee stated that v3.2 adds a new attribute (CKA_SEED) that will allow that, but it won’t be mandatory to support it. So two HSMs can both claim PKCS#11 v3.2 support and still be unable to exchange an ML-KEM key, if one keeps only the expanded form and the other expects a seed.

The disagreement was visible during the LAMPS last call on private key formats, when the PKCS#11 and KMIP technical committees wrote that the PKCS#11 and KMIP standards do not share this IETF assumption. A later individual Internet-Draft goes further and proposes that implementations MUST use the seed representation, unless the key is a legacy key whose seed has been discarded. That draft is not yet a standard, but it shows the direction of travel.

Which ML-KEM keys actually need a backup?

Fewer than most teams expect. NIST SP 800-227 separates ephemeral KEM key pairs, used for a single key establishment, from static encapsulation keys bound to an identity. Ephemeral keys should never be backed up. Tunnel protocols that generate a fresh key pair for each handshake create nothing that needs escrow. One example is Quantum Network’s QPN gateway, where the hybrid classical and ML-KEM key agreement is renewed every two minutes. In these designs, the keys to protect and back up are the long-lived signing keys that authenticate the endpoints.

Static ML-KEM keys do exist, for example in encrypted messaging under RFC 9936 (ML-KEM in CMS) or in KEM-based certificate schemes. For those keys:

• Generate them with the seed retained, and confirm the HSM exposes CKA_SEED or an equivalent.
• Run a full wrap, unwrap and decapsulate round trip between your actual source and target HSM models before production, not just between two units of the same model.
• Write down in your key management records which format each key was created in. A key that was only ever expanded cannot be upgraded to seed form later.

Do I need to replace my HSM to issue post-quantum certificates for VPN gateways?

Often not, but that depends on firmware support, FIPS 140-3 validation status and capacity, not on the PKCS#11 version string. A post-quantum gateway certificate needs ML-DSA signing at the CA. The gateway itself performs the ML-KEM key exchange.

Most current HSM platforms receive ML-DSA and ML-KEM through firmware and client library updates. The harder question is assurance. NIST stated in 2025 that its CAVP is already testing the new PQC algorithms for FIPS 140 validation. However, a validation certificate covers a specific firmware version. If your security policy requires FIPS 140-3 validated operation, the firmware that adds ML-DSA must itself appear on a validation certificate that lists the algorithm as approved.

Also check the gateways themselves. ML-DSA certificates and chains are much larger than ECDSA ones. On narrowband or high-latency OT links, IKEv2 message fragmentation (RFC 7383) and gateway buffer limits deserve a test before rollout.

How do HSMs protect CA keys for a post-quantum remote access PKI?

The HSM keeps the ML-DSA root and issuing CA private keys non-extractable, controls who may use them through role separation and quorum authentication, and records each signing operation. The principles are the same as for classical CAs. What changes is the time pressure, because post-quantum roots created now must stay trustworthy for decades.

The timeline drives the design. Under NIST IR 8547, quantum-vulnerable public-key algorithms are deprecated after 2030 and disallowed under NIST standards after 2035. The NIST Post-Quantum Cryptography project sums it up: “NIST will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035”, with high-risk systems moving earlier. For US federal systems, Executive Order 14412 accelerated this timeline, requiring federal high-value assets and high-impact systems to migrate by 2030 for key establishment and 2031 for digital signatures. A root CA with a 20-year lifetime created today with ECDSA would therefore outlive its own algorithm.

Practical controls for a post-quantum CA in an OT context

• Offline ML-DSA root: Generate the root key inside the HSM with CKA_EXTRACTABLE set to false where possible. If disaster recovery requires a copy, use the vendor’s HSM-to-HSM cloning or backup scheme under quorum control. Never use plaintext export.
• Constrained intermediates per zone: Issue separate intermediate CAs for remote access users, site gateways and cloud endpoints, each with name constraints. This limits what any one key can sign and makes it easier to give an air-gapped site its own issuing CA.
• Use signature context deliberately: If your PKI software supports ML-DSA context strings through PKCS#11 v3.2, agree on a convention before issuing the first certificate. Changing it afterwards breaks verification.
• Parallel hierarchies during transition: Remote access clients and older gateways will validate classical chains for years. A separate post-quantum root, run alongside the existing root, avoids a single disruptive cutover.
• Re-keying ceremonies on the calendar: Set certificate lifetimes so that gateway and user certificates come up for renewal well before 2030. Each renewal then becomes a natural point to move to ML-DSA.

For site-to-site links that do not rely on a PKI at all, the HSM question is smaller. Quantum Network’s QPN gateway, for example, combines a classical and an ML-KEM key agreement into one session key at each end of the connection, without software on the OT equipment behind it. Whatever the architecture, the sequence for an HSM-backed remote access PKI stays the same. Confirm what PKCS#11 v3.2 support your HSM actually provides, choose seed-based key formats, check the validation scope, and introduce an ML-DSA hierarchy before the 2030 deprecation deadline.