Skip to content
System access
ASD ISMISM-0414

ASD ISM 0414 Uniquely identifying every user granted system access

What it says

Users granted access to systems and their resources are uniquely identifiable.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

Every person given access to a system or its resources gets their own distinct identity, so actions can always be traced back to one accountable individual.

This control requires that each user who is granted access to a system, or to the resources within it (files, databases, applications, services), can be told apart from every other user. In practice this means one person, one identity. Shared logins, generic accounts such as "admin" or "reception" used by several people, and duplicate usernames all break this rule. Why it matters: almost every other access control depends on knowing who someone is. If two people share an identity, you cannot enforce the right permissions for each of them, cannot reliably remove one person's access when they leave, and cannot say with confidence who performed a given action. When something goes wrong, whether a mistake, a policy breach or a deliberate attack, investigators need to attribute activity to a specific individual. Unique identification is what makes that attribution possible and makes people accountable for what they do on the system.

Why it matters

Without unique identification, activity on systems and their resources cannot be attributed to a specific person. Investigations stall because logs point to a shared or ambiguous identity, individuals cannot be held accountable for their actions, and access cannot be granted or revoked precisely for one person. Shared credentials also tend to spread and outlive the people who originally needed them, leaving unauthorised parties with working access and undermining every access control layered on top.

How to implement

  1. Identity or IT administrators create a separate, individually named identity for each person granted access to a system or its resources, and refuse requests that would give one identity to multiple people.

  2. The security team locates existing shared, generic and group logins (for example common admin, helpdesk or front-desk accounts) and migrates each user of those accounts onto their own identity before the shared credential is retired.

  3. The identity administrator configures the directory or identity provider to reject duplicate usernames and user IDs, and applies the same uniqueness rule across all connected systems and federated directories.

  4. System owners ensure access to resources within a system (databases, file shares, applications, administrative consoles) is granted to individual identities rather than to a shared credential, using role or group membership to manage permissions without sharing logins.

  5. The access management team reconciles the identity store against the HR and contractor registers on a set schedule, confirming each active identity maps to exactly one current person and correcting any that have become shared or duplicated.

Keep it running

Day to day, this control lives in the identity and access provisioning process. Every new access request, whether for a system or a specific resource within it, should result in an identity tied to one named person. Watch for the common ways uniqueness erodes over time: a "temporary" shared login created during a project or outage, a vendor or contractor team given a single account, service or system accounts being used interactively by staff, and mailboxes or kiosks where several people sign in under one name.

Keep an eye on username collisions when systems are merged, when identities are federated between directories, or when people with similar names join. Periodic reconciliation between the HR or contractor register and the identity store helps confirm that each identity still maps to exactly one real person and that no identity has quietly become shared.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for an export of all user identities from the system's directory or identity provider.

    Look at

    Check whether every identity is tied to one named person, and look for generic names, duplicates or accounts labelled for a team, role or location rather than an individual.

    Good evidence

    Each identity maps to exactly one person and no shared or generic user accounts are used for access.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for the access provisioning procedure and a sample of recent access requests.

    Look at

    Confirm the procedure requires a separate identity per person and that the sampled requests each name a single individual as the account holder.

    Good evidence

    The procedure prohibits shared identities and the samples show one identity issued per named person.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the list of accounts with access to key resources within the system, such as databases, file shares and administrative consoles.

    Look at

    Check whether access to those resources is granted to individual identities, and whether any shared credential is used by several staff to reach them.

    Good evidence

    Resource access is assigned to individual identities, with permissions managed through roles or groups rather than shared logins.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for the directory or identity provider configuration relating to username and user ID uniqueness.

    Look at

    Look for settings or checks that prevent duplicate usernames or IDs, including across federated or connected directories.

    Good evidence

    The system enforces uniqueness technically so a duplicate identity cannot be created by mistake.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for the most recent reconciliation of user identities against the HR and contractor registers.

    Look at

    Check that each active identity was matched to one current person and that any shared or unmatched identities were investigated and corrected.

    Good evidence

    Reconciliation is performed regularly and shows a clean one-to-one match between identities and people, with exceptions resolved.

Mappings

Closest match in ISO/IEC 27001: A.5.16, Identity life cycle management, which this control partially meets.

ISO 27001

ISO/IEC 27001: 2 mappings

  • A.5.16Identity life cycle managementPartially meets
  • A.5.18Managing access rights to information assetsSupports
Essential Eight

ASD Essential Eight: 1 mapping

  • E8-RA-ML1.2Dedicated privileged user accounts for privileged dutiesSupports

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.