ASD Essentials IT.PRO-16.1 Verify Integrity, Authenticity and Provenance of Software, Components and Updates Before Use
What it says
Assess the integrity and authenticity of software, components and updates before use, and verify provenance where suitable supplier evidence is available.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishConfirms software, components and updates are genuine and unchanged before use, and checks where they came from when suppliers give proof.
Before any software, firmware, code library or update is installed, someone checks it is genuine and unchanged. For example, they confirm an update carries the publisher's digital signature. Where the supplier gives proof of where it came from, that is checked too. To meet this, every kind of item is checked and each result recorded. Anything that cannot be checked gets extra safeguards for a set time while a fix is arranged.
Free. Save your status, tasks and notes.
Where this action applies
What's in each domain?ASD orders the work by domain: apply this action to each ticked domain, phase by phase.
- Phase 3
Why it matters
Without these checks, tampered or fake software and updates install as if genuine. An unchecked server plugin can give attackers lasting access. Without records, nobody can tell which systems took in a bad item, so it takes longer to find and stop.
How to implement
The security lead should write a checking procedure for every kind of software, component and update, including firmware and third-party code libraries.
Make the check a required step when a product is accepted and before use.
IT operations should get items only from official sources or the approved software store.
Check each item's publisher signature or fingerprint (hash) from a trusted source, and turn on signature checks in update tools through central policy.
The team bringing in the software should check supplier proof of origin, such as a signed build record or software parts list.
Confirm it is genuine, matches the version received and shows third-party parts were built to a suitable standard.
The person doing each check should record the item, version, source, method, result, their name and the date before release.
Keep it in the change record or software register, and automate this where tools allow.
The system owner should log an exception for each item that cannot be checked, with extra safeguards such as isolated testing and closer monitoring.
The risk owner approves it with a fix plan and an end date.
Keep it running
Build the check into every route software comes in by: purchases and downloads, internal software stores, patch and firmware updates, and the libraries developers pull into their code. Hold back anything that fails and refer it to the security team. The common trap is automatic updates and developer libraries slipping past the check. Follow ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems and staff devices.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the checking procedure and the kinds of software and routes in that it covers.
Look at
Whether any kinds or routes are left out, such as firewall firmware or developer libraries.
Good evidence
Every kind of software, component and update is checked before use, in every ASD domain.
- Check 2 of 5What an auditor asks for
Ask for
Ask each team to show how it checks items from each kind of source.
Look at
Whether the check is reliable, or uses fingerprints from unofficial pages or accepts any signature.
Good evidence
Each source is checked in a way suited to it, such as the expected publisher's signature.
- Check 3 of 5What an auditor asks for
Ask for
Request the proof of origin held for products whose suppliers provide it, and the check records.
Look at
Whether supplier proof of origin is compared with the product received, or just filed unread.
Good evidence
Where suppliers give suitable proof of origin, it is checked and the result recorded.
- Check 4 of 5What an auditor asks for
Ask for
Request check records for a sample of recent software, firmware and updates from several ASD domains.
Look at
Whether every item has a record made before use, or only some teams and item types keep them.
Good evidence
Each item has a record of the method, result, checker and date, made before use.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the register of items that cannot be checked, with approvals and fix plans.
Look at
Whether such items run with no extra safeguards, or exceptions lack approval or an end date.
Good evidence
Every such item has approved extra safeguards, an end date and a tracked fix plan.
ASD indicators of good practice (11)
The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".
Not effective(3)
- NE-1No verification of software, component or update integrity or authenticity is performed before introduction into systems.
- NE-2Verification outcomes are not recorded or available for review.
- NE-3Where verification cannot be performed, no compensating control or remediation paths are documented.
Partially effective(4)
- PE-1Verification is performed for some categories of software but not consistently across operating systems, applications, firmware and dependencies.
- PE-2Integrity or provenance checks are performed, but they do not provide sufficient assurance for all software, components or updates.
- PE-3Verification outcomes are recorded for some software, components or updates prior to being introduced into systems, but not consistently.
- PE-4Compensating controls exist for some unverifiable components but are not formally approved or time-bound.
Fully effective(4)
- FE-1Verification of integrity and provenance is performed for software, components and updates across all relevant categories, and provenance is verified where suitable supplier evidence is available.
- FE-2Verification uses one or more mechanisms appropriate to the software, component, update and source to provide reliable assurance of integrity and provenance.
- FE-3Verification outcomes are recorded and available for review.
- FE-4Where verification cannot be performed, compensating controls are applied, exceptions are time-bound and remediation paths are documented.
Mappings
Closest match in ISO/IEC 27001: A.5.21, Managing Information Security in the ICT Supply Chain, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.5.21.
IT.PRO-16.1 requires the integrity and authenticity of software, components and updates to be assessed before use, with provenance verified where suitable supplier evidence is available. This is a specific safeguard within the processes ISO/IEC 27001 Annex A 5.21 requires to manage information security risks associated with the ICT products and services supply chain. Annex A 5.21 covers the broader supply chain risk process, while IT.PRO-16.1 targets software integrity and provenance.
This control partially overlaps A.8.19.
IT.PRO-16.1 requires the integrity and authenticity of software, components and updates to be assessed before use, with provenance verified where suitable supplier evidence is available. Verifying software before it is installed contributes directly to the secure management of software installation on operational systems required by ISO/IEC 27001 Annex A 8.19. Annex A 8.19 also covers how installation itself is controlled, while IT.PRO-16.1 extends to components and provenance checks beyond installation on operational systems.
ASD Information Security Manual: 5 mappings
This control partially overlaps ISM-1790.
IT.PRO-16.1 requires the integrity and authenticity of software, components and updates to be assessed before use; ISM-1790 overlaps on integrity, requiring operating systems, applications, IT and OT equipment and services to be delivered in a manner that maintains their integrity.
This control partially overlaps ISM-1791.
IT.PRO-16.1 requires the integrity and authenticity of software, components and updates to be assessed before use; ISM-1791 covers the integrity part, assessing the integrity of operating systems, applications, IT and OT equipment and services as part of acceptance.
This control partially overlaps ISM-1792.
IT.PRO-16.1 requires the integrity and authenticity of software, components and updates to be assessed before use; ISM-1792 covers the authenticity part, assessing the authenticity of operating systems, applications, IT and OT equipment and services as part of acceptance.
This control partially overlaps ISM-2027.
IT.PRO-16.1 requires the integrity and authenticity of software and updates to be assessed before use; ISM-2027 specifies a method, verifying all software artefacts by digital signature or a secure hash provided over a secure channel before import into the authoritative source for software.
This control partially overlaps ISM-2055.
IT.PRO-16.1 requires software integrity and authenticity to be assessed before use, verifying provenance where supplier evidence exists; ISM-2055 overlaps on provenance, using available build provenance for imported third-party components to ensure they are built to an appropriate standard.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.