ASD ISM 1992 Using hedged variant of ML-DSA for digital signatures
What it says
When using ML-DSA for digital signatures, the hedged variant is used whenever possible.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUse the more secure version of ML-DSA for digital signatures to minimise risks.
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.
Free. Save your status, tasks and notes.
Why it matters
Without the hedged ML-DSA variant, forged documents could compromise critical decisions, leading to legal liabilities and reputational harm.
How to implement
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.
Keep it running
Regularly confirm ML-DSA signing uses the hedged variant where supported; monitor configuration changes and update procedures accordingly.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The list of digital signing tools currently in use: Request a report from the IT department detailing all software or tools used for digital signatures.
Look at
The version and settings of each tool.
Good evidence
Documentation showing all tools set to use the hedged variant of ML-DSA and confirmation from the IT team that these settings are enabled.
- Check 2 of 5What an auditor asks for
Look at
Records showing updates specifically aimed to maintain or enhance security.
Good evidence
Logs showing the latest patches and updates, with notes highlighting the continued support for the hedged variant of ML-DSA.
- Check 3 of 5What an auditor asks for
Ask for
Vendor confirmation letters: Request correspondence with vendors affirming that their products support the hedged variant of ML-DSA.
Look at
The vendor's statements or product documentation.
Good evidence
Written confirmation from vendors that their products are compatible with the hedged variant.
- Check 4 of 5What an auditor asks for
Look at
The specifications and requirements outlined during the purchasing process.
Good evidence
Procurement records showing that the hedged variant of ML-DSA support was a specific requirement during purchases.
- Check 5 of 5What an auditor asks for
Ask for
A process review report: Request a recent report from internal auditors on the use of digital signatures within the organisation.
Look at
The findings and recommendations.
Good evidence
A report confirming that all digital signing processes are using the hedged variant and any deviations have been addressed.
Mappings
Closest match in ISO/IEC 27001: A.8.24, Effective use of cryptography and key management, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.24.
ISM-1992 requires that when ML-DSA is used for digital signatures, organisations use the hedged variant wherever possible to reduce cryptographic risk. This maps to Annex A 8.24 because it is a specific rule for the effective use of cryptography (choice of safer signature mode) within a broader cryptography and key-management policy framework. Annex A 8.24 covers many additional topics (e.g. algorithm selection principles, key lifecycle management, governance), while ISM-1992 is narrowly focused on one post-quantum signature scheme configuration.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.