Craton HSM

Post-quantum migration

Craton HSM ships the three NIST-standardised post-quantum primitives — ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) — along with hybrid constructions that pair them with classical counterparts. This guide is about phasing them into an existing PKCS#11 deployment without breaking classical clients, and about the external constraints (crate stability, FIPS validation, CNSA 2.0 timelines) that shape when to move.

For the algorithm reference — parameter sets, mechanism numbers, key sizes, standards — see Post-quantum algorithms.

The target posture

For most deployments the migration destination is not "replace classical" — it is "add PQ in parallel, prefer hybrids":

Key establishment. Move from pure X25519 / ECDH P-256 to hybrid X25519 + ML-KEM-768. The derived secret is a KDF over both component shared secrets, so the construction is secure as long as either component is secure. This is the posture the IETF TLS working group has adopted for X25519MLKEM768.
Signatures. Add ML-DSA-65 (NIST Level 3, comparable to ECDSA P-384) as the default for long-lived signatures — certificates, firmware, software bills of materials. For Craton HSM use cases that require the smallest stable signing scheme, SLH-DSA-SHA2-128s is the hash-based stateless alternative.
Keep classical running for the subset of consumers that cannot yet consume PQ mechanisms. Classical and PQ keys coexist on the same token.

Current status and constraints

Before planning dates, understand what is stable and what is not.

PQC crate versions are release candidates. Craton HSM depends on ml-kem 0.3.0-rc.0, ml-dsa 0.1.0-rc.7, and slh-dsa 0.2.0-rc.4. The PKCS#11 serialisation for PQC keys is stable on the wire, but key formats may change when these crates reach 1.0 — plan to re-generate PQ keys across that upgrade. The plan is tracked in the project's future-work notes; watch the RustCrypto KEM and signature repositories for stable releases.
FIPS status. ML-KEM, ML-DSA, and SLH-DSA are standardised in FIPS 203 / 204 / 205, but the AWS-LC module validated today does not include them in its approved-services list. Craton HSM's fips_approved_only = true therefore blocks PQ mechanisms. You have three options:
1. Run PQ outside FIPS mode on a non-FIPS module.
2. Run two Craton HSM instances — one FIPS-approved-only for regulated signatures, one with PQ enabled for experimental or hybrid workloads.
3. Wait for a CMVP-approved module that includes these algorithms.
CNSA 2.0 timeline. NSA's CNSA 2.0 calls for PQ-only for software / firmware signing by 2025, and for all new systems to use CNSA 2.0 exclusively by 2030 (with earlier milestones for hardware and browsers). If your programme is governed by CNSA 2.0, signing keys should already be ML-DSA, and key establishment should already be moving to hybrid. For everyone else, NIST's guidance is to begin migration now and complete it by 2030.

Interop realities

Two sources of friction in practice:

Non-Craton clients may not register PQ mechanisms. An application loading Craton HSM through C_GetFunctionList and enumerating C_GetMechanismList will see ML-KEM / ML-DSA / SLH-DSA and the hybrid mechanisms. An application hard-coded to CKM_ECDSA or CKM_RSA_PKCS_PSS will simply not use them — no error, no data, no migration. Walk your consumers' call sites.
Mechanism numbers for PQ are vendor-defined. OASIS has not yet published official PKCS#11 numbers for ML-KEM / ML-DSA / SLH-DSA in a released v3.x, so Craton HSM assigns them in the 0x80000000 vendor range. Clients that parse mechanism lists against a hard-coded OASIS map will not recognise the vendor numbers and must be updated. The mapping is stable across Craton HSM minor versions; consult Post-quantum algorithms for the exact values.
Wire-format interop with other HSMs is limited. SoftHSMv2 does not implement PQ. Cloud KMS products are beginning to ship ML-DSA but via proprietary APIs, not PKCS#11. If your workload demands cross-vendor interop, stick to hybrids for key establishment (where the classical half is universally understood) and to ML-DSA for signatures (where the verifier only needs the public key format).

Step 1: Enable PQ on Craton HSM

PQ is on by default in the non-FIPS build. Confirm the flag:

[algorithms]
crypto_backend = "rustcrypto"   # or "awslc" if you are not in FIPS-approved mode
enable_pqc = true
fips_approved_only = false

The module will then register — in addition to the classical mechanisms:

CKM_ML_KEM_KEYPAIR_GEN, CKM_ML_KEM_ENCAPSULATE, CKM_ML_KEM_DECAPSULATE for the three parameter sets (512, 768, 1024).
CKM_ML_DSA_KEYPAIR_GEN, CKM_ML_DSA_SIGN, CKM_ML_DSA_VERIFY for ML-DSA-44, -65, -87.
CKM_SLH_DSA_* for SLH-DSA-SHA2-128s and -256s.
Hybrid mechanisms — for example CKM_HYBRID_X25519_ML_KEM_768_DERIVE for the key-establishment target above, and CKM_HYBRID_ECDSA_ML_DSA_SIGN for dual-algorithm signatures where regulation or contractual language requires both.

Verify:

pkcs11-tool --module ./libcraton_hsm.so --list-mechanisms | grep -Ei 'ML_|SLH_|HYBRID_'

Step 2: Begin with signatures

Signatures are easier to migrate than key establishment: the signer and the verifier rotate independently as long as the verifier learns the new public key in time.

Typical sequence:

Generate an ML-DSA-65 key pair on Craton HSM with CKA_LABEL and CKA_ID parallel to the classical key — for example LABEL=firmware-signer-v2, ID=0x02.
Sign an artefact with both the classical and the PQ key. The signing pipeline now produces two detached signatures.
Deploy the PQ verifier to every relying party. Until every relying party is on the new verifier, the classical signature remains the one that is actually checked.
Once the rollout is complete, flip the verification policy to require the PQ signature. The classical side becomes vestigial.
Retire the classical key on the next key-rotation boundary.

ML-DSA-65 signs in approximately 563 us and verifies in 270 us on the reference platform (see Benchmarks for the full table). Signature sizes are larger than ECDSA — budget for the bytes in any artefact, certificate, or transcript that carries them.

Step 3: Key establishment via hybrid X25519 + ML-KEM-768

For TLS-style KEM workloads, use the hybrid mechanism:

Generate a hybrid key pair with CKM_HYBRID_X25519_ML_KEM_768_KEYPAIR_GEN (or C_DeriveKey from components, per the mechanism reference).
Export the hybrid public key — a concatenation of the X25519 public point and the ML-KEM-768 encapsulation key — and publish it alongside the classical public key in whatever directory, certificate, or configuration your protocol uses.
On the initiator side, call C_DeriveKey with the hybrid mechanism. Craton HSM performs both X25519 key agreement and ML-KEM-768 encapsulation, feeds both secrets into HKDF, and returns the derived key. The resulting shared secret is as strong as the stronger of the two component secrets.
Retain a pure-X25519 (or pure-ECDH) key in parallel for initiators that do not understand the hybrid mechanism. Responders can advertise both.

The hybrid construction is the pragmatic path because you do not have to trust ML-KEM alone yet. If ML-KEM is later broken, the X25519 component still protects the session. If X25519 is broken by a CRQC, the ML-KEM component does.

Step 4: Operate side by side

The two most common operational questions:

Backup and restore. PQ keys are encrypted and persisted like classical keys; craton-admin backup captures them. Remember that PQ public keys are larger, so an encrypted backup with a mixed classical / PQ portfolio grows noticeably compared to a classical-only token.
Audit algorithm indicators. Audit log entries for PQ operations carry "fips_approved": false today (because the module's FIPS-approved set does not yet list them). Filter on this field when reporting on approved-only workloads; do not filter on mechanism name alone.

Step 5: Plan for the stable-crate upgrade

When the RustCrypto PQ crates reach non-RC versions, Craton HSM will publish a minor release that takes them. The upgrade steps are captured in the project's migration guide; the short form is:

Before upgrading, back up the token with craton-admin backup and export or re-wrap any exportable PQ keys.
Upgrade Craton HSM.
Re-generate PQ keys. Stable-crate serialisation may differ from the RC format; restoring an RC-era PQ key into a stable build is not guaranteed to round-trip.
Re-issue the certificates or publish the new hybrid public keys that reference the re-generated keys.
Run the full test suite (cargo test -- --test-threads=1) before releasing to production.

Timeline suggestion

Concrete dates depend on your regulatory environment, but a defensible sequence for a large deployment looks like:

Now. Inventory every classical key, its consumers, and its rotation cadence. Stand up a non-production Craton HSM with PQ enabled and prove out the hybrid KEM and ML-DSA paths against your two or three hardest consumers (TLS terminator, artefact signer, identity provider).
Next 6 months. Generate ML-DSA-65 signing keys in parallel with classical; dual-sign artefacts; roll out PQ-capable verifiers. Add hybrid X25519+ML-KEM-768 to key-establishment handshakes as an offered group.
Next 12-18 months. Track stable-crate releases; plan the PQ key re-generation cycle across that boundary. Begin requiring the PQ signature on new artefacts once every relying party can verify it.
Through 2030. Retire classical-only signing on the natural key-rotation cadence. Keep hybrid KEM in place until pure-PQ KEMs are broadly supported and you no longer need the classical fallback.