Using Hedged Variant of ML-DSA for Digital Signatures
Use the more secure version of ML-DSA for digital signatures to minimise risks.
Plain language
This control is about using a safer version of a tool called ML-DSA, which stands for Module-Lattice-Based Digital Signature Algorithm, when signing digital documents. Digital signatures verify documents are authentic and haven’t been tampered with. If you don’t use the more secure variant, someone could potentially forge documents, leading to potential security breaches or reputation damage.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Nov 2024
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for cryptographyOfficial control statement
When using ML-DSA for digital signatures, the hedged variant is used whenever possible.
Why it matters
Without the hedged ML-DSA variant, forged documents could compromise critical decisions, leading to legal liabilities and reputational harm.
Operational notes
Regularly confirm ML-DSA signing uses the hedged variant where supported; monitor configuration changes and update procedures accordingly.
Implementation tips
- Managers should ensure that their IT team is aware of the requirement to use the hedged variant of ML-DSA for all digital signing processes. They can achieve this by scheduling a meeting to discuss the control and ensure the team has the necessary resources and understanding to implement it.
- The IT team should verify that any software or tools used for digital signatures are configured to use the hedged variant of ML-DSA. This can be done by checking the software settings and documentation to ensure compliance.
- Procurement should work with IT to make sure any new software purchases for digital signing explicitly support the hedged variant of ML-DSA. They should review product specifications before purchase and consult with vendors to confirm compatibility.
- System administrators need to regularly update and patch the software used for digital signatures to ensure it remains secure and supports the hedged variant of ML-DSA. They should plan scheduled maintenance to apply updates and document these actions.
- Internal auditing teams should periodically review the digital signing processes to ensure the hedged variant is being used consistently. They can do this by sampling signed documents and verifying the signature method employed.
Audit / evidence tips
-
Askthe list of digital signing tools currently in use: Request a report from the IT department detailing all software or tools used for digital signatures
Gooddocumentation showing all tools set to use the hedged variant of ML-DSA and confirmation from the IT team that these settings are enabled
-
Goodlogs showing the latest patches and updates, with notes highlighting the continued support for the hedged variant of ML-DSA
-
Askvendor confirmation letters: Request correspondence with vendors affirming that their products support the hedged variant of ML-DSA
Goodwritten confirmation from vendors that their products are compatible with the hedged variant
-
Goodprocurement records showing that the hedged variant of ML-DSA support was a specific requirement during purchases
-
Aska process review report: Request a recent report from internal auditors on the use of digital signatures within the organisation
Gooda report confirming that all digital signing processes are using the hedged variant and any deviations have been addressed
Cross-framework mappings
How ISM-1992 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| Annex A 8.24 | ISM-1992 requires that when ML-DSA is used for digital signatures, organisations use the hedged variant wherever possible to reduce crypt... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.