Ensure Client Authentication for Internal Network APIs
Make sure apps inside your network check who accesses them and what they can do, before allowing data changes.
Plain language
This control requires you to make sure that anyone accessing apps within your company's internal network is verified and granted the right level of access before they can change any data. This is important because if unauthorised people can make changes, it could lead to data breaches or loss that could harm your business operations and reputation.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Feb 2025
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
Authentication and authorisation of clients is performed when clients call network APIs that facilitate modification of data but are not accessible over the internet.
Why it matters
Unauthorised calls to internal network APIs could allow data modification, leading to fraud, service disruption, and reputational damage.
Operational notes
Require client authentication/authorisation (e.g., mTLS or signed tokens) for internal write APIs; review service accounts/keys and alert on failed auth attempts.
Implementation tips
- System owners should identify all internal network APIs that allow data modification within their applications. To do this, review application documentation or consult with developers to list each API and its purpose, ensuring a comprehensive understanding of what each API does.
- The IT team should set up an authentication system to verify the identity of clients accessing each internal API. This can be done using existing systems, like Active Directory, or by setting up a basic username and password check tailored for each API use-case.
- Hire or task a developer or IT specialist with implementing authorisation checks for each API to ensure clients can only perform actions they are permitted to do. This involves setting up rules within the API that evaluate what data or functions a user is allowed to access based on their role or identity.
- Managers should work with the IT team to establish a regular review process for the authentication and authorisation systems. Schedule meetings every quarter to review current systems, discuss any incidents, and determine if updates or changes are needed.
- Information technology staff should draft a procedure document explaining how to handle and report any issues or breaches related to API access. This includes clearly defined steps for identifying an incident, who to notify, and how to restore secure operations.
Audit / evidence tips
- AskThe list of internal network APIs: Request documentation or listings that identify all APIs within the organisation GoodContains a detailed list of APIs, their functions, and associated user-access controls
- AskRecords of authentication logs: Request logs that show who accessed each API and when GoodIs a log showing consistent access by verified users only
- AskAccess control policies related to internal network APIs: Request to see written policies that outline how access is granted and who is responsible for overseeing access GoodIs a policy document that clearly details these expectations
- AskAny incident reports related to unauthorised API access: Request past reports that document any breaches or attempts at unauthorised access GoodDetails actions taken swiftly to resolve any issues and measures implemented to prevent recurrences
- AskTo see the staff training logs on API security procedures: Request records showing when staff were trained on API access and security checks GoodShows regular training sessions with comprehensive content covered and attendance records
Cross-framework mappings
How ISM-2013 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| handshake Supports (3) expand_less | ||
| Annex A 5.16 | ISM-2013 focuses on enforcement of client authentication and authorisation at the time of internal API calls | |
| Annex A 5.17 | ISM-2013 requires authentication and authorisation for internal APIs, while Annex A 5.17 supports it by ensuring the secure management of... | |
| Annex A 5.18 | ISM-2013 mandates internal APIs to authenticate and authorise clients before data modifications, supported by Annex A 5.18's requirement ... | |
| link Related (1) expand_less | ||
| Annex A 8.5 | Annex A 8.5 mandates secure authentication mechanisms to enforce access control | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.