ASD ISM 1991 Implement ML-DSA for enhanced digital signature security
What it says
When using ML-DSA for digital signatures, ML-DSA-65 or ML-DSA-87 is used, preferably ML-DSA-87.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUse ML-DSA algorithms, preferring ML-DSA-87, for secure digital signatures.
This control is about using a specific kind of digital signature (called ML-DSA) to secure electronic documents or messages. It's like a super-safe way of proving a document is authentic and hasn't been tampered with. Without it, there's a risk that unsigned documents could be faked or altered, leading to data breaches or financial losses.
Free. Save your status, tasks and notes.
Why it matters
If ML-DSA-65/87 is not used, digital signatures may be forgeable (including by future quantum attacks), enabling tampered documents and fraud.
How to implement
IT team should prioritise implementing the ML-DSA algorithm.
This involves updating systems to use ML-DSA-87 for signing important documents. You can do this by working closely with your software vendor to ensure the most secure version is in place and configuring your systems to use it by default.
Security managers should verify existing digital signatures.
They need to review current practices to ensure ML-DSA-87 is being used wherever possible. This can be achieved by conducting a check of signature settings in document management systems and configurations.
Training departments should educate staff about ML-DSA usage.
Organise workshops to explain when and why to use digital signatures on documents. This can be reinforced with simple guides and step-by-step instructions for day-to-day use.
HR should ensure hiring practices include verification of expertise.
When recruiting IT staff, ensure candidates have experience with updating and maintaining digital signature systems. Assess this by discussing relevant past projects during interviews.
Keep it running
Prefer ML-DSA-87 (or ML-DSA-65 where needed), enforce approved parameter sets in signing services, and verify signatures to detect unauthorised changes.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The digital signature policy document: Request to see the organisation's policy that mandates the use of ML-DSA-87.
Look at
The policy's details to ensure it specifically mentions ML-DSA-87 as a requirement.
Good evidence
Policy will have clear instructions on implementation and usage.
- Check 2 of 5What an auditor asks for
Ask for
System configuration documentation showing ML-DSA settings: Request to review documents that outline current system configurations related to digital signatures.
Look at
Specific settings indicating ML-DSA-87 is used by default. Good documentation will clearly show system settings, including dates and approval.
- Check 3 of 5What an auditor asks for
Ask for
Training records for digital signature protocols: Request records of training sessions regarding the use of digital signatures.
Look at
The attendee lists and training material to confirm staff are educated on ML-DSA-87. Good evidence includes dated and detailed records of all sessions.
- Check 4 of 5What an auditor asks for
Ask for
Vendor communication logs: Request email or meeting notes showing discussions with vendors about digital signature capabilities. Review the logs to ensure vendors confirm support for ML-DSA-87.
Good evidence
Will include references to supplier guarantees or compliance statements.
- Check 5 of 5What an auditor asks for
Ask for
Audit trail logs for digital signature application: Request access to logs that document when and how digital signatures are applied in the organisation.
Look at
Entries that show the use of ML-DSA-87 over older algorithms. Good logs will provide a clear trail of usage with timestamps.
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-1991 requires organisations that use ML-DSA for digital signatures to select specific approved parameter sets (ML-DSA-65 or ML-DSA-87, preferably ML-DSA-87). This is a concrete instance of Annex A 8.24, which requires organisations to define and implement rules for the effective use of cryptography and cryptographic key management, including selecting approved algorithms/parameters for given use cases (such as digital signatures). Annex A 8.24 is broader because it covers all cryptographic applications and associated key lifecycle management, whereas ISM-1991 is a specific algorithm/parameter selection rule for one cryptographic use case.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.