ASD ISM 0415 Strictly controlling shared accounts and identifying their users
What it says
The use of shared user accounts is strictly controlled, and users of such accounts are uniquely identifiable.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishShared accounts are allowed only under tight control, and every action taken through one must be traceable to a named person.
A shared user account is one login used by more than one person, such as a generic administrator account, a ward or reception PC login, or a service desk mailbox. The control says two things. First, the use of these accounts must be strictly controlled: they should exist only where there is a genuine need, be formally approved, be limited to the people and tasks they are for, and be reviewed and removed when no longer required. Second, whoever is using a shared account at any moment must be uniquely identifiable, so that an action taken through the account can be tied back to an individual. This matters because accountability is the foundation of most other security controls. If five people know the password to one account, an investigator cannot tell who deleted the file, changed the configuration or exported the data. Nobody can be held responsible, disciplinary or legal action becomes difficult, and a malicious insider has a ready-made way to act anonymously. Shared credentials also tend to be weak, rarely changed, and passed on informally, so they outlive the people who first needed them and become a quiet path for unauthorised access. Keeping shared accounts rare, well governed and always attributable to a person closes that gap.
Free. Save your status, tasks and notes.
Why it matters
Without strict control and unique identification, actions taken through shared accounts cannot be attributed to any individual, so misuse, error or insider activity may go undetected and unpunished, investigations stall, and credentials known to many people persist as an easy route for unauthorised access.
How to implement
The IT security manager compiles a register of all shared user accounts across systems by exporting account lists and flagging any credential used by more than one person, then assigns a named owner and written justification to each and decommissions those with no owner or need.
The identity or access management team routes every shared account credential through a password vault or privileged access management tool, so a person must authenticate with their own individual account to check out or launch the shared account and the checkout is logged against their name.
The system owner restricts each shared account to a defined list of approved users and to the specific tasks it exists for, configuring least-privilege permissions on the account and documenting the approved user list alongside the register entry.
The system owner reviews each shared account at a set interval, re-confirming the business need, trimming the approved user list to current staff who still need it, removing vault or launch permissions for anyone who has left or changed roles, and retiring accounts that are no longer justified (changing the shared credential itself on departure is covered by a related ISM control).
The security operations team configures logging so that shared account activity can be joined to the individual who was using it, for example by correlating vault checkout times, workstation logons or session recordings with the shared account's actions, and tests the lookup quarterly.
Keep it running
Day to day, this control lives in three places: the account register, the access path, and the logs.
The account register lists every shared account, its owner, its business justification, who is permitted to use it, and when it was last reviewed. Creating a new shared account should be an exception that needs the owner's approval and a recorded reason, and each account should be re-justified at a set interval or retired.
The access path is how a person gets to the account. Approaches that keep users uniquely identifiable include checking the credential out of a privileged access management (PAM) or password vault under the person's own login, or requiring an individual login before the shared session is launched. A paper sign-in sheet or booking record for a shared physical workstation is not a substitute for these technical measures; at most it is a last-resort supplement where no technical option exists, and an assessor is unlikely to accept it on its own. Passwords for shared accounts should be changed when a permitted user leaves or the credential is exposed.
The logs are what close the loop. Vault checkouts, session recordings, terminal or workstation logon records and application logs together need to show which person was behind the shared account at a given time. Service desk and security teams should know how to run that lookup, and periodic spot checks confirm the trail actually works before an incident forces the question.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the register of shared user accounts, including owner, justification, approved users and last review date.
Look at
Check that every shared account found on the systems appears in the register and that each entry has a current owner, a documented reason and a recent review.
Good evidence
The register is complete, every account is justified and owned, and accounts without a need have been removed rather than left dormant.
- Check 2 of 5What an auditor asks for
Ask for
Ask how a person obtains and uses a shared account credential, and request evidence such as vault or PAM configuration.
Look at
Look for a step that requires the individual to authenticate as themselves before the shared credential is released or the session is started.
Good evidence
No one can use a shared account without first identifying as an individual, and the release or launch is recorded against that person.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the logs for a sample shared account over a chosen period and request that a specific action be attributed to a person.
Look at
Check whether vault checkouts, session records or logon data can be joined to the shared account's activity for that time window.
Good evidence
Staff can name the individual behind a given shared account action within minutes, using retained logs rather than memory.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the approved user list for a sample of shared accounts and for evidence of how that list is kept current when staff leave or change roles.
Look at
Compare the approved list against HR records and check whether users who left or changed roles were removed from the list and from any vault or launch permissions for the account.
Good evidence
Approved lists contain only current staff with a need, and departed or moved users have no remaining path to the shared account (credential changes on departure are assessed under the related ISM control).
- Check 5 of 5What an auditor asks for
Ask for
Ask for records of the periodic review of shared accounts and any tests of the attribution process.
Look at
Look for dated review sign-offs by account owners and results of spot checks that traced shared account actions to individuals.
Good evidence
Reviews happen on schedule, owners actively confirm or remove accounts, and spot checks show the traceability works in practice.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 4 mappings
This control partially meets A.5.15.
ISM-0415 requires governance over shared accounts and ensures actions performed using them are uniquely attributable to a specific user. ISO/IEC 27001:2022 Annex A 5.15 establishes access control rules, policies and procedures, which supports ISM-0415 by providing the policy foundation to restrict when shared accounts can exist and under what conditions they may be used. Annex A 5.15 is higher-level and does not explicitly mandate traceability of shared-account usage to named individuals.
This control partially meets A.5.16.
ISM-0415 requires shared user accounts to be strictly controlled and used in a way that makes each individual user uniquely identifiable. ISO/IEC 27001:2022 Annex A 5.16 covers managing identities across their full life cycle (creation, changes, and removal), which includes governing the use and constraints of non-personal identities such as shared or generic accounts. ISM-0415 is a specific, higher-assurance requirement focused on shared-account control and attribution, while Annex A 5.16 is broader and less prescriptive about how attribution is achieved.
This control partially overlaps A.5.18.
ISM-0415 requires strict control of shared accounts and unique identification of the individuals who use them. ISO/IEC 27001:2022 Annex A 5.18 requires provisioning, reviewing, modifying and removing access rights, which overlaps with ISM-0415 where shared accounts (if permitted) must be carefully provisioned and reviewed to ensure use remains justified and controlled. Annex A 5.18 focuses on access-rights lifecycle management generally and does not specifically require per-use attribution mechanisms for shared credentials.
This control partially overlaps A.8.2.
ISM-0415 requires strict governance over shared user accounts and unique identification of each person who uses them to maintain accountability. ISO/IEC 27001:2022 Annex A 8.2 restricts and manages privileged access rights, which often includes constraining the use of shared administrative accounts and ensuring their use is controlled. The overlap is strongest where shared accounts are privileged, but ISM-0415 applies to shared accounts generally (privileged or not) and is specifically about user attribution, whereas Annex A 8.2 is primarily about privileged-right allocation and use controls.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.