Adopt ML-DSA with signature lifecycle and interoperability evidence

Bottom line: a signature algorithm is one element of a trust system. Before adopting ML-DSA, identify who signs, how that identity is established, where the private key lives, what exact object and context are signed, who verifies it, how long verification must work, and how keys and algorithms are changed.

Source fact: what FIPS 204 specifies

FIPS 204 specifies ML-DSA, a module-lattice-based set of algorithms for generating and verifying digital signatures. NIST describes digital signatures as mechanisms used to detect unauthorized modification and authenticate the claimed signatory, with potential evidentiary use by a recipient. The standard states that ML-DSA is believed to be secure against an adversary with a large-scale quantum computer.

The NIST page included a July 31, 2026 planning note pointing to several minor issues in an errata spreadsheet for correction in a future update or revision. Implementers should review the current errata rather than relying only on the original publication file.

What the source does not establish

FIPS 204 does not bind a public key to a person, organization, device, software publisher, or business authority. It does not protect a private key from theft, define every file or protocol format, preserve a signature and its validation data forever, or certify a product implementation.

A verified signature proves only what the validation process and trusted context support. It does not prove that signed content is accurate, safe, authorized for use, or free of malicious behavior.

Applicability questions

• What object, canonical representation, metadata, and context are covered by the signature?
• How is the signatory’s public key bound to an identity and authority trusted by each verifier?
• Which implementations, parameter sets, formats, certificates, protocols, and relying systems must interoperate?
• How are signing keys generated, protected, rotated, recovered if applicable, revoked, and destroyed?
• What evidence must remain available years later to validate the signature under the policy in force at signing?

DSE recommendation: design the relying workflow

The following steps are DSE recommendations based on the cited source.

1. Inventory signature use cases, signers, relying parties, objects, formats, trust anchors, retention periods, legal or contractual needs, and current algorithms.
2. Select only a current supported profile and implementation. Review FIPS 204, current errata, applicable protocol specifications, and product documentation before approval.
3. Define key custody and signing authorization separately. Constrain which identity and process can request a signature and which content is presented for approval.
4. Test exact artifact formats and every required verifier, including error handling, altered data, wrong keys, revoked or retired identities, and mixed-algorithm transition states.
5. Preserve verification context appropriate to the use case without asserting indefinite validity. Document time, policy, trust material, software versions, and archival dependencies.
6. Maintain algorithm agility, rollback, and re-signing or migration decisions for long-lived assets.

Verification and evidence

Retain the use-case and trust model, standards and errata review, supported profile, implementation versions, key-ceremony or service evidence, authorization tests, cross-platform verification matrix, negative tests, performance results, archival validation test, approval, and transition plan.

Official references

• FIPS 204 — Module-Lattice-Based Digital Signature Standard — National Institute of Standards and Technology; published August 13, 2024; review current errata
• NIST FAQ for Post-Quantum Cryptography FIPS — National Institute of Standards and Technology; living guidance