ASD ISM 2014 Ensure API client authentication and authorisation
What it says
Authentication and authorisation of clients is performed when clients call network APIs that facilitate access to data not authorised for release into the public domain but are not accessible over the internet.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishCheck and confirm who can use certain non-internet APIs to access restricted data.
This control is about making sure that only the right people and systems can access your business data through internal APIs, which are tools for letting different software programs talk to each other. If this isn't done properly, unauthorised users might gain access to sensitive data, leading to data breaches or leaks that could harm your business reputation and financial health.
Free. Save your status, tasks and notes.
Why it matters
Weak API client authentication/authorisation can allow unauthorised internal callers to access non-public data via network APIs, causing disclosure and compromise.
How to implement
IT team should set up authentication mechanisms: This means establishing a process that verifies the identity of each API user.
Use methods like unique usernames and passwords or digital certificates to confirm who is accessing your data through APIs.
Managers should collaborate with the IT team: Ensure that there are clear guidelines on who should have access to specific data via APIs.
This might involve creating a list of roles within the company that require access and sharing this with the IT team for implementation.
System administrators should regularly audit API access: Periodically review logs and access records to ensure only authorised users are accessing the APIs.
This involves checking for any unusual access patterns or failed login attempts which might indicate a security issue.
Business leaders should conduct awareness sessions: Educate staff about the importance of protecting data accessed via APIs, making sure they understand the need for secure password practices and how to report any suspicious activity related to API usage.
Procurement should ensure new software tools comply: When acquiring new software, check that it supports secure authentication and authorisation practices for API use.
This can involve checking that the vendor follows best practices outlined by the Australian Cyber Security Centre (ACSC).
Keep it running
Enforce strong client authentication (e.g., mTLS/OAuth), validate scopes/roles per API, and regularly review access logs for unauthorised internal API calls.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The API access policy document: Request to see the official company policy on how API access is managed.
Look at
Whether it details who can access what data and under what conditions.
Good evidence
Includes clearly defined roles, responsibilities, and a list of authorised APIs.
- Check 2 of 5What an auditor asks for
Ask for
Access logs from the API management tool: Examine the logs for entries that track who accessed the APIs and when.
Look at
Complete and detailed logs, showing only authorised accesses during expected times.
Good evidence
Is comprehensive logs with no irregular access patterns.
- Check 3 of 5What an auditor asks for
Ask for
Training records on API security: Request records of any training provided to staff about API use and security.
Look at
Whether training was conducted regularly and covered key security practices.
Good evidence
Is a schedule of past training sessions with attendee lists and feedback.
- Check 4 of 5What an auditor asks for
Ask for
User access reviews: Request reports or meeting notes from regular reviews of user access privileges for APIs.
Look at
The frequency of such reviews and whether any unauthorised accesses were found and corrected.
Good evidence
Is records of reviews with documented actions taken.
- Check 5 of 5What an auditor asks for
Ask for
Software acquisition checklists: Request to see documentation from recent software purchases that show API security compliance was considered.
Look at
Whether the checklist included the requirement for secure authentication and authorisation.
Good evidence
Shows the checklist was actively used with all items reviewed.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.5.15.
ISM-2014 focuses on enforcing client authentication and authorisation when internal network APIs are called to access non-public data. ISO/IEC 27001:2022 Annex A 5.15 requires establishing and implementing rules for logical (and physical) access control, which would typically include API access rules and identity/authorisation mechanisms. Annex A 5.15 is broader policy/procedure coverage across all access scenarios, while ISM-2014 is a concrete requirement for API client access decisions.
This control partially meets A.8.3.
ISM-2014 requires organisations to authenticate and authorise clients calling internal network APIs that expose non-public data. ISO/IEC 27001:2022 Annex A 8.3 requires restricting access to information and associated assets in accordance with the access control policy, which includes controlling who can access data/services such as APIs. Annex A 8.3 is higher-level and broader (all assets and access methods), whereas ISM-2014 is a specific technical enforcement point for API calls.
This control partially meets A.8.5.
ISM-2014 requires authentication and authorisation of clients when they call internal (non-internet) network APIs that provide access to data not authorised for public release. ISO/IEC 27001:2022 Annex A 8.5 requires secure authentication technologies and procedures to be implemented based on access restrictions, which directly covers the authentication aspect needed for API clients. Annex A 8.5 is broader (all authentication contexts), while ISM-2014 is a specific application to API client access and also explicitly includes authorisation checks.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.