ASD ISM 2083 Provide a cryptographic bill of materials to software users
What it says
A cryptographic bill of materials is produced and made available to consumers of software.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSoftware producers must give users a list of all cryptographic components used in the software.
Think of this control like an ingredients list but for your software. Software producers need to give you a list of all the cryptographic bits and pieces used in their software. This is important because if you don't know what security measures are used, you can't properly protect your data or fix issues when something goes wrong.
Free. Save your status, tasks and notes.
Why it matters
Without a cryptographic bill of materials (CBOM), users may unknowingly rely on weak or vulnerable algorithms/libraries, increasing breach risk.
How to implement
The IT team should create a comprehensive list of all cryptographic components used in the software.
Begin by reviewing the software's documentation and source code for any mention of encryption or security protocols, and compile this into a document or spreadsheet.
Software developers need to regularly update the cryptographic bill of materials.
They should ensure that each time there's a software update or patch, any changes to cryptographic tools are noted and the bill of materials is refreshed to reflect current usage.
The software development manager should provide this list to end-users.
They can do this by including it as part of the software documentation, or making it available on a user portal where customers can easily access it.
The procurement team needs to request this document from vendors as part of the purchasing process.
They should include it as a requirement in contracts and confirm it's provided before finalising any software purchase.
An IT supervisor should review the list for completeness and accuracy quarterly.
They can compare the company's inventory of software against the provided bills of materials to ensure all necessary documents are accounted for and up-to-date.
Keep it running
Publish a CBOM per release listing crypto libraries, versions, algorithms/modes and key sizes, and update it when components change or CVEs emerge.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The cryptographic bill of materials document: Ensure the document is available for each piece of software your organisation uses.
Look at
Whether this document lists all the cryptographic components and any recent updates.
Good evidence
Is a comprehensive, dated list detailing cryptographic elements for each software piece your organisation uses.
- Check 2 of 5What an auditor asks for
Look at
Whether updates have been consistently made following software changes.
Good evidence
Is a version-controlled document showing regular updates, especially after new software releases or patches.
- Check 3 of 5What an auditor asks for
Ask for
Evidence of communication with users: This for example could be an email or notice regarding updates to the cryptographic bill of materials.
Look at
Whether these communications are part of regular updates users receive.
Good evidence
Clear, consistent communications scheduled to provide users with crucial security information.
- Check 4 of 5What an auditor asks for
Ask for
Procurement documentation: Ensure that all new software purchases have a requirement for a cryptographic bill of materials included in the procurement process.
Look at
Whether purchase contracts specify this requirement.
Good evidence
Is a set of procurement documents showing the requirement prominently and confirming receipt.
- Check 5 of 5What an auditor asks for
Look at
The dates and the scope of the review.
Good evidence
Is a regularly updated log with dates, reviewer names, and any changes or findings noted.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which partially overlaps with this control.
ISO/IEC 27001: 2 mappings
This control partially overlaps A.8.25.
ISM-2083 requires software producers to provide software users with a CBOM of cryptographic components. Annex A 8.25 requires secure development lifecycle rules to be established and applied, which commonly includes maintaining component inventories and producing security artefacts for consumers. Annex A 8.25 is broader across the whole SDLC, while ISM-2083 is a specific deliverable focused only on cryptographic components and their disclosure to users.
This control supports A.5.21.
ISM-2083 requires software producers to provide a CBOM to software users to increase transparency of cryptographic components. Annex A 5.21 requires processes to manage ICT supply chain information security risks, and a CBOM supports this by improving visibility into third-party cryptographic dependencies and enabling risk assessment of algorithms and libraries. Annex A 5.21 is about supply chain risk management generally, while ISM-2083 is a specific requirement for cryptographic component disclosure.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.