ASD ISM 1796 Digitally sign executable software for security
What it says
Files containing executable content are digitally signed by a certificate with a verifiable chain of trust as part of software development.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishExecutable files must have a digital signature verified by a trusted certificate to ensure security.
This control is about ensuring that when software is developed, any files that have the ability to be executed on a computer are digitally signed. This digital signing process provides a way to confirm that the software comes from a trusted source and hasn't been tampered with. Without this, you risk running untrusted software that could harm your computers or steal sensitive information.
Free. Save your status, tasks and notes.
Why it matters
Without code signing, attackers can tamper with executable files to add malware, bypass trust checks, and gain unauthorised access or steal data.
How to implement
Software developers should integrate digital signing into their development process.
This means ensuring that as each piece of software is being finalised, it is signed with a digital certificate that is recognised by trusted authorities. Developers can use tools like code signing software to automate this step.
IT managers should ensure that the digital certificates used for signing are obtained from reputable Certificate Authorities (CAs).
They should research and acquire certificates that are widely accepted and ensure that these certificates are kept secure and up-to-date.
Procurement officers need to include digital signature requirements in contracts with software vendors.
When purchasing software, officers should specify that all executable files must be digitally signed, and verify compliance during the procurement process.
System administrators should regularly check that all installed software is properly signed.
This can be done by using software tools to verify the digital signatures of executables and ensure that they are still valid and come from a trusted source.
Organisation leaders should promote awareness about the importance of using digitally signed software among staff.
This can be achieved through regular training sessions and by incorporating it into the organisation's cyber security policies.
Keep it running
Use trusted code-signing certificates with a verifiable chain of trust; regularly validate certificate status/expiry and automate enforcement so only signed executables are built and deployed.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A list of all digital certificates used for software signing: Review the list to ensure certificates are from reputable Certificate Authorities and are still valid.
Good evidence
Includes certificates with valid expiry dates and clear ties to trusted CAs.
- Check 2 of 5What an auditor asks for
Ask for
To see a sample of signed software: Request a demonstration of the digital signature verification process for a random executable file. Look to see if the signature shows as valid and trusted when checked.
Good evidence
Shows a signature that is recognised by the system and indicates the correct issuer.
- Check 3 of 5What an auditor asks for
Ask for
The procurement policy document: Verify the inclusion of digital signing requirements in contracts with software vendors. Check for clauses specifying digitally signed executables.
Good evidence
Contains explicit references to digital signing and compliance checks.
- Check 4 of 5What an auditor asks for
Ask for
Records of staff cyber awareness training related to software signing: Review the training materials or attendance records to ensure the topic is covered.
Good evidence
Includes specific sessions on the importance of digital signatures and recorded completion rates.
- Check 5 of 5What an auditor asks for
Ask for
Recent audit logs or reports verifying software signatures: Look through the logs for signs of regular checks and any issues that were discovered and addressed.
Good evidence
Contains evidence of routine checks with no unsigned executables, or documented resolutions of such findings.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.8.25.
ISM-1796 requires organisations to digitally sign files containing executable content with certificates that have a verifiable chain of trust as part of software development. ISO/IEC 27001:2022 Annex A 8.25 requires secure development rules to be established and applied across the software and systems lifecycle. ISM-1796 is a specific secure development rule focused on code signing and trust chains, making it a subset of the broader secure SDLC requirements in Annex A 8.25.
This control depends on A.8.19.
ISM-1796 requires executable files to be digitally signed with a verifiable chain of trust, enabling recipients to validate software authenticity and integrity. ISO/IEC 27001:2022 Annex A 8.19 requires secure software installation procedures for operational systems. ISM-1796 supports Annex A 8.19 by enabling installation processes to verify signed executables prior to deployment, but Annex A 8.19 covers broader installation governance (authorisation, source validation, rollback, and procedural controls) beyond code signing.
This control depends on A.8.24.
ISM-1796 requires digitally signing executable content using a certificate with a verifiable chain of trust, which inherently relies on sound cryptographic key handling. ISO/IEC 27001:2022 Annex A 8.24 requires rules for effective use of cryptography and cryptographic key management to be defined and implemented. ISM-1796 is dependent on Annex A 8.24 because code-signing certificates and private keys must be generated, protected, rotated, and revoked appropriately for the signing and trust-chain verification to remain credible.
ASD Essential Eight: 1 mapping
- E8-RM-ML3.2Check Microsoft Office macros for malicious code before signing or trustingPartially overlaps
This control partially overlaps E8-RM-ML3.2.
ISM-1796 requires executable files to be digitally signed using a certificate with a verifiable chain of trust as part of software development. E8-RM-ML3.2 relates by requiring Microsoft Office macros (a form of executable content) to be checked for malicious code before they are digitally signed or trusted. The overlap is on signing as an integrity/authenticity control, but E8-RM-ML3.2 is specific to macro safety checks and trust decisions, while ISM-1796 is broader and focuses on trusted signing for executable software generally (not malware review).
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.