CRYSTALS-Dilithium migration plan.

Why we are doing this now.

Two reasons, neither of them panic. First: the artifacts we sign today will be verified by regulators and customers for 25–30 years. A flight-qualified aerospace part signed in 2026 is going to be reviewed under audit in 2046 or later; in that window, large-scale quantum attacks on classical elliptic-curve signatures are a non-trivial probability. Migrating later means re-signing the long tail; migrating now means new signatures land in the right scheme from the start.

Second: customers in our regulated sectors are starting to write the question into procurement. Two of our aerospace customers asked specifically what our post-quantum roadmap looks like during 2025 contract renewals. We would rather show a roadmap with shadow signatures already live than describe a future intention.

What we are not doing: replacing Ed25519 with Dilithium. The plan is hybrid — both signatures, both verifiable, for the full migration window. A pure Dilithium scheme has properties (signature size, verification cost) that we want to validate at scale before depending on it alone.

The scheme.

Hybrid signing means each artifact carries two signatures concatenated — one Ed25519, one Dilithium-3 — over the same canonical-form payload. Verifiers accept the artifact if both signatures verify under their respective public keys.

This adds approximately 2.4 KB to each bundle (Dilithium-3 signatures are ~3.3 KB vs Ed25519's 64 bytes). For a typical Vault3D bundle of 1.2 MB G-code envelope, the overhead is in the rounding error. For high-frequency posture publishes, where every byte matters, the overhead is non-trivial but acceptable.

Verification cost adds approximately 2.1 ms per signature on commodity hardware (verified on Intel Xeon 8375C, AMD EPYC 7763, Apple M2). At the daemon's typical signing rate the additional verification is dominated by the HSM round-trip and is not user-visible.

Phased migration.

Phase 0 — shadow signatures (live since 2026 Q1).

Every artifact signed by the production fleet now carries a Dilithium-3 signature alongside the Ed25519 one, but the Dilithium signature is informational — verifiers do not require it. This lets us measure HSM round-trip latency, bundle overhead, and edge-case failures at production scale without any verifier impact. We have run 2.41 M signed prints in shadow mode; no edge cases observed.

Phase 1 — hybrid co-signing (2026 Q4).

Verifiers begin requiring both signatures to be valid on newly-issued artifacts. Existing Ed25519-only artifacts continue to verify under their original scheme. Customer firmware updates under RB-25; the verifier-CLI gains hybrid-required mode. We expect approximately 90 minutes of fleet operator time per customer for the rollout window, scheduled at the customer's convenience.

Phase 2 — Dilithium-only signing (2028 Q1 target).

New artifacts sign with Dilithium only; verifiers accept hybrid and Dilithium-only. Ed25519-only artifacts continue to verify under their original scheme; we do not retroactively invalidate. This phase fires only when we are confident that the field has matured (e.g. HSM vendor support across our certified vendor list, no NIST parameter-set deprecation in the interim).

Phase 3 — ceremony root rotation to Dilithium-only (2030).

The ceremony root is rotated to a Dilithium-only key. The 2024 Ed25519 root remains valid for verifying historical artifacts forever; the new root anchors the post-quantum-only era. Coincides with the natural 36-month rotation cycle.

What gets migrated where.

HSM-side considerations.

The hardest part of this migration is not the cryptography — that is well-trodden — but the HSM ecosystem. The HSMs we deploy at printer sites must support Dilithium signing primitives natively (we are not interested in software-only Dilithium with an HSM-signed-software-stack pretense; that defeats the hardware-rooted property).

Status across our certified vendor list:

• Vendor 1 — native Dilithium support in production firmware. Most of our production fleet is on this vendor.
• Vendor 2 — native Dilithium in beta firmware, expected GA 2026 Q3. Phase-1 rollout for customers on this vendor will follow the GA timing.
• Vendor 3 — native Dilithium scoped for 2026 Q4. A small customer cohort uses this vendor; we will coordinate with them on phase-1 timing.

For customers using bring-your-own HSM (Thales, Utimaco), Dilithium support varies by model and firmware version. We will publish a per-model compatibility table closer to phase-1 GA.

Verifier-CLI behaviour across phases.

# phase 0 (today): verifier checks Ed25519, ignores Dilithium
$ 3dc verify bundle bd-2026-05-19-7a3f
ok    bundle verified against printer key BAY-A4-PRINTER-07
note  this artifact also carries a Dilithium-3 shadow signature (informational).

# phase 1 (2026 Q4): verifier requires both for new artifacts
$ 3dc verify bundle bd-2026-10-04-ab12
ok    bundle verified against printer key BAY-A4-PRINTER-07 (Ed25519 + Dilithium-3)

# phase 1, an old bundle (still Ed25519-only): still verifies fine
$ 3dc verify bundle bd-2024-11-02-c701
ok    bundle verified against printer key BAY-A4-PRINTER-07 (Ed25519, pre-hybrid)

# phase 2 (2028 Q1): verifier accepts Dilithium-only and hybrid
$ 3dc verify bundle bd-2028-02-19-d930
ok    bundle verified against printer key BAY-A4-PRINTER-07 (Dilithium-3)

At no point does an artifact that was valid at issue become invalid. The verifier's acceptance set monotonically grows over the phase transitions.

Risks we are watching.

The plan is not zero-risk. The risks we have identified:

• NIST parameter-set change. NIST could revise Dilithium parameters before our phase-2 lands. We will follow NIST publication and adjust; phase-2 fires only when the parameter set is stable.
• HSM vendor lag. One of our certified vendors slips Dilithium GA. Phase-1 for that vendor's cohort slips with them; we will not push a software-only Dilithium implementation to compensate.
• Bundle size at scale. The ~3.4 KB Dilithium signature is fine for individual bundles; for posture publishes (one per minute per printer) the cumulative overhead is non-trivial. We are evaluating Dilithium-2 for the posture-publish channel separately.
• Quantum cryptanalysis revisions. The post-quantum field is still settling. We treat this plan as live, not as a one-time write; the published version is rev 2026.05 and will gain revisions as the field matures.

What customers need to do.

Phase 0 (now): nothing. Your bundles already carry shadow signatures; your verifiers ignore them. Posture is published on the manifest; you can verify the shadow signatures yourself if you want to validate the rollout.

Phase 1 (2026 Q4): a routine firmware update under RB-25. We will reach out individually with timing. Plan for approximately 90 minutes of operator time per site for the rollout window.

Phase 2 onwards: routine. The migration becomes invisible.

If your audit process or notified body requires a position statement on post-quantum cryptography, the published plan (this document) is signed and citable. You may include it in your audit package; we have done so for customers who asked.