ASD ISM 1797 Ensure software updates are securely signed
What it says
Installers, patches and updates are digitally signed or provided with cryptographic checksums as part of software development.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishMake sure software updates and patches are securely signed to verify they are authentic and untampered.
Ensuring software updates are securely signed means making sure the updates you install are safe and come from a trusted source. This is important because if updates aren't verified for authenticity, hackers could take control of your systems by sneaking malicious software in through those updates.
Free. Save your status, tasks and notes.
Why it matters
Unchecked software updates can enable attackers to inject malicious code, compromising systems and causing data breaches.
How to implement
IT team should check current software update practices: Make sure every software update process includes a step to confirm that updates come with a digital signature.
This can be done by checking the update's signature before it's applied.
Software developers should integrate code-signing certificates into their development process: Ensure every piece of software released by your organisation includes a digital signature.
This involves obtaining trusted certificates from a reputable provider and using them to sign your software.
Procurement should verify vendor security practices: Whenever purchasing new software solutions, ask vendors how they handle software update authentication.
Only proceed with suppliers who can confirm they use secure update processes.
Managers should arrange training for staff on recognising authentic software updates: Hold workshops for your team to explain the signs of legitimate software updates and what to do if they think an update might be suspicious.
IT team should regularly review digital signatures and certificates: Schedule routine checks on the validity of certificates and replace them if they're close to expiry.
Use tools that automatically alert you when signatures or certificates are invalid.
Keep it running
Verify update signatures or cryptographic checksums before install; quarantine and report any unsigned or mismatched packages.
Evidence and audit
- Check 1 of 3What an auditor asks for
Ask for
A list of all software used by the organisation and their update procedures.
Look at
How each update source is verified and whether digital signatures are routinely checked. Good practice includes having documented procedures for all major software, with confirmations of signature checks.
- Check 2 of 3What an auditor asks for
Ask for
Records of staff training sessions on software update verification.
Look at
Details on content covered and employee attendance. Good records include dated training materials and signed attendance sheets.
- Check 3 of 3What an auditor asks for
Ask for
Vendor security assurances: Check vendor agreements and communications for clauses about software update security.
Good evidence
Includes explicit vendor commitments to secure update practices and evidence of regular audits or security reviews.
Mappings
Closest match in ISO/IEC 27001: A.8.19, Secure software installation procedures, which this control covers in full and more.
ISO/IEC 27001: 3 mappings
This control is broader than A.8.19.
ISM-1797 requires installers, patches and updates to be digitally signed or accompanied by cryptographic checksums so their authenticity and integrity can be verified. ISO/IEC 27001:2022 Annex A 8.19 requires secure software installation procedures, within which verifying vendor signatures/checksums is a common required measure. Annex A 8.19 is broader because it covers the end-to-end procedural and technical controls for secure installation beyond integrity verification.
This control partially meets A.8.25.
ISM-1797 requires software development outputs (installers, patches and updates) to be digitally signed or distributed with cryptographic checksums to assure integrity. ISO/IEC 27001:2022 Annex A 8.25 requires a secure development lifecycle, within which release integrity controls (code signing, checksum publication, release validation) are commonly mandated practices. Annex A 8.25 is broader, covering many SDLC security requirements beyond release artefact signing.
This control supports A.5.21.
ISM-1797 requires software updates to be digitally signed or provided with cryptographic checksums to reduce the risk of tampering and counterfeit updates. ISO/IEC 27001:2022 Annex A 5.21 addresses ICT supply chain security risk management, where verifying update authenticity via signing/checksums is a concrete control to mitigate supplier and distribution-channel compromise. Annex A 5.21 is broader and includes contractual, assurance and monitoring activities that go beyond update integrity verification.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.




