Validate Digital Signature Certificates Securely
Software checks digital signatures against trusted certificates and ensures they haven't been revoked.
Plain language
Digital signature certificates are like ID cards for software, proving they are legitimate and from a trusted source. If these certificates aren't checked properly, malicious software could slip through, posing risks like data theft or system compromise.
Framework
ASD Information Security Manual (ISM)
Control effect
Detective
Classifications
NC, OS, P, S, TS
ISM last updated
May 2025
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
When digital signatures are processed by software, they are validated against a certificate trust chain and checked for revocation using a Certificate Revocation List or with the Online Certificate Status Protocol.
Why it matters
If certificate chains and revocation (CRL/OCSP) aren’t validated, attackers can use forged or revoked signing certs to deliver trusted-looking malware.
Operational notes
Regularly update the certificate trust store and automate checks for revocation using CRLs or OCSP to ensure constant validation.
Implementation tips
- IT team should regularly update the list of trusted certificates: This involves keeping software libraries up-to-date with recent trusted digital certificates to avoid using expired or revoked ones. Use a trusted provider or service to obtain these updates.
- System owners should verify the authenticity of software: When installing new software, check if its digital signature matches a trusted certificate. This is done by viewing the certificate details provided in the installation prompt.
- Security personnel must monitor certificate validity: set up the system to automatically check if certificates are revoked or expired, using protocols like the Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP). This ensures only valid certificates are used.
- Procurement teams should ensure vendors provide valid certificates: When purchasing software, require vendors to provide proof that their digital signatures are backed by valid and current certificates. Request accompanying documentation with any software purchases.
- IT managers should train staff on recognising valid certificates: Training should include how to spot warning signs that a certificate might be invalid or revoked, and how to report it. Use practical examples during training sessions to illustrate potential risks of ignoring certificate validation.
Audit / evidence tips
-
Askthe list of trusted certificates: Request the comprehensive list of certificates that the IT team maintains for software validation
Goodis an up-to-date list showing the latest trusted certificates sourced from a reliable authority
-
Asksoftware verification logs: Request logs showing digital signature validation for installed software on organisational systems
Goodis detailed logs showing consistent checks against trusted certificates
-
Aska policy document: Request the organisation’s digital signature verification policy document
Goodis a detailed document outlining the steps to verify digital signatures, including revocation check methods
-
Askvendor compliance documentation: Request to see the documentation vendors provide regarding their software's digital signatures
Goodcontains vendor-submitted documentation with visible certificate details and expiry dates
-
Asktraining records: Request evidence of training sessions conducted on digital signature validation
Goodincludes records of recent training sessions with clear focus on certificate validation and practical examples discussed
Cross-framework mappings
How ISM-2050 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-2050 requires software to validate digital signatures using certificate trust chains and revocation checking (CRL/OCSP) | |
E8
| Control | Notes | Details |
|---|---|---|
| handshake Supports (2) expand_less | ||
| E8-RM-ML3.1 | E8-RM-ML3.1 requires macros to execute only when digitally signed by a trusted publisher (or from a Trusted Location/sandbox) | |
| E8-RM-ML3.2 | E8-RM-ML3.2 requires macros to be checked for malicious code before being digitally signed or placed in Trusted Locations | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.