Use Pre-Hashed ML-DSA Variants Only When Necessary
Only use alternate ML-DSA signatures if the standard version is too slow.
Plain language
This control is about using a special kind of digital signature called pre-hashed ML-DSA only when absolutely necessary. Imagine this like using a high-speed blender instead of a regular one only if you're in a rush, because the high-speed one uses more power. If you use it when you don't need to, you might waste resources or even compromise security.
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
Pre-hashed variants of ML-DSA-65 and ML-DSA-87 are only used when the performance of default variants is unacceptable.
Why it matters
Using pre-hashed ML-DSA-65/87 without need can add complexity and overhead, without addressing any unacceptable performance limits of default variants.
Operational notes
Benchmark default ML-DSA-65/87 in target workflows; only enable pre-hashed variants when measured latency or throughput is unacceptable and documented.
Implementation tips
- IT team should assess the performance of the standard ML-DSA signature: Check if the speed of the standard version causes any delays or bottlenecks in your systems. Use performance monitoring tools to determine if the system's responsiveness meets your requirements.
- System owner should evaluate necessity for pre-hashed variants: Assess if the regular digital signature method is inadequate for your needs. Consider if critical processes are slowed down and only switch to pre-hashed versions if these processes cannot otherwise run efficiently.
- Manager should oversee a cost-benefit analysis: Determine the trade-offs between using pre-hashed versions and the standard. Weigh the increased speed against potential risks such as security gaps or resource costs.
- Procurement team should ensure software compatibility: Verify that any software acquired supports the use of pre-hashed ML-DSA, should it be required. Examine technical specifications and consult with vendors during the procurement process.
- Security team should implement guidelines around use: Develop guidelines specifying when to use standard versus pre-hashed ML-DSA. Document scenarios justifying the use of pre-hashed variants to ensure consistent and justified application.
Audit / evidence tips
-
Aska report on signature algorithm usage: Request documentation that outlines which digital signatures are being used and when
Goodwill show clear justification when pre-hashed versions are in use
-
Asksystem performance logs: Request logs showing system performance before and after implementing pre-hashed versions. Look to see if there were significant performance improvements without compromising security
Goodwill show a noticeable improvement that justified the change
-
Askrisk assessment reports: Request the organisation's risk assessment associated with using pre-hashed ML-DSA. Look to see if potential risks, like security issues, have been accounted for
Goodwill include a detailed risk management plan
-
Askcost analysis documentation: Request documentation showing any cost-benefit analysis performed before switching to pre-hashed ML-DSA
Goodincludes a balanced analysis justifying the decision
-
Askvendor compatibility confirmations: Request records from vendors confirming compatibility with pre-hashed ML-DSA
Goodprovides clear confirmation from the vendor
Cross-framework mappings
How ISM-1993 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-1993 requires that pre-hashed ML-DSA-65/87 variants are only used when the performance of the default ML-DSA variants is unacceptable | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.