ASD Essentials IT.PRO-13.6 Enforce Unique Credentials per System and Account, Especially in High-Privilege Contexts
What it says
Ensure that user, machine, system and service account credentials are unique per system or account, particularly in high-privilege contexts.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishGives every account its own password or key on each system, never shared or reused, especially for accounts with admin rights.
Each password, key or other credential belongs to one account on one system. This applies to people, devices, apps and automated services. It matters most for powerful accounts, such as each computer's local administrator, domain and cloud administrator accounts, and accounts that run automation tools. To meet this, tools enforce it for every type of account. Any shared credential that remains gets extra safeguards, monitoring and a plan to remove it.
Free. Save your status, tasks and notes.
Where this action applies
What's in each domain?ASD orders the work by domain: apply this action to each ticked domain, phase by phase.
- Phase 3
Why it matters
One guessed, leaked or stolen password opens every system that accepts it, and the attacker looks like a valid user. A shared admin or app account password turns one hacked device into control of many, and hides who did what.
How to implement
The identity lead should keep a list of credentials for people, devices, systems and services, and where each is used.
With approval, scan for passwords and keys reused across accounts, and have owners fix powerful accounts first.
Device, server and network administrators should give every device's local administrator account its own random password, managed by a password tool.
Remove shared passwords from build images and enrol devices until every one is covered.
Identity and cloud administrators should give each built-in domain Administrator, cloud admin and emergency account its own password, never reusing an everyday one.
Where possible, platform teams should run automation on managed identities, which sign in with no stored password.
System owners should give each service and connected app its own account and password, and each device its own certificates and keys.
Passwords IT sets for users should be random, and users get a password manager to stop reuse.
The system owner should register each credential that cannot be made unique and every system using it.
Limit where it can be used from, have security operations alert on its use, and agree a dated fix plan.
Keep it running
Build uniqueness into everyday work so it does not slip: device builds, server templates, new app accounts and help desk resets should each create a new random password. Update the credential list whenever a system or account changes. Follow ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems and staff devices. Revisit the exceptions list when systems change, so exceptions close rather than pile up.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the service and admin accounts, the systems each uses, and the latest reuse check.
Look at
Whether one password or key serves several servers, or a person's admin and everyday accounts share one.
Good evidence
Each service and admin password or key belongs to one account on one system.
- Check 2 of 5What an auditor asks for
Ask for
Request the local admin password report for each device group, checked against the asset list.
Look at
Whether local admin passwords match across devices or come from a build image, or groups are left out.
Good evidence
Each relevant device has its own local admin password, and coverage matches the asset list.
- Check 3 of 5What an auditor asks for
Ask for
Request proof for each domain Administrator, cloud admin, emergency and automation account.
Look at
Whether some powerful accounts still share fixed passwords or keys, or available managed identities go unused.
Good evidence
Every powerful account has its own password or key, with managed identities used where possible.
- Check 4 of 5What an auditor asks for
Ask for
Ask how unique passwords and keys are enforced for each type of account, with settings evidence.
Look at
Whether enforcement covers only some account types or systems, or exists only as a written rule.
Good evidence
Unique passwords and keys are enforced for every relevant type of account, on every in-scope system.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the shared credential register, with each entry's extra safeguards, monitoring and fix plan.
Look at
Whether shared credentials are missing from the register, or entries lack safeguards, monitoring or a plan.
Good evidence
Every shared credential left has extra safeguards, watched use and a tracked fix plan.
ASD indicators of good practice (12)
The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".
Not effective(4)
- NE-1Local administrator credentials are shared across the device fleet, or service or privileged account credentials are routinely reused across systems.
- NE-2Credential uniqueness is not enforced for applicable user, machine, system or service identities.
- NE-3Credential uniqueness has not been addressed in high-privilege contexts, including domain administration, cloud administration or automation platforms.
- NE-4Where credential uniqueness cannot be enforced, neither compensating controls nor remediation paths are in place.
Partially effective(4)
- PE-1Local administrator credential uniqueness has been implemented for some device populations but coverage is incomplete across the device fleet.
- PE-2A technical mechanism is in place but applies to only a subset of credential types or systems within scope.
- PE-3Credential uniqueness has been addressed in some high-privilege contexts but gaps remain in others.
- PE-4Compensating controls exist for some shared credentials but monitoring is inconsistent or remediation plans do not exist.
Fully effective(4)
- FE-1Credentials for applicable local administrative accounts are unique to each system or account.
- FE-2Credential uniqueness is consistently enforced for applicable user, machine, system and service identities.
- FE-3Credential uniqueness is enforced consistently in high-privilege contexts, with managed identities or equivalent capabilities used in preference to shared static credentials wherever feasible.
- FE-4Where uniqueness cannot be enforced, compensating controls are applied, the use of the shared credentials is monitored, and a remediation plan exists.
Mappings
Closest match in ISO/IEC 27001: A.5.17, Management of Authentication Information, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.5.17.
IT.PRO-13.6 requires user, machine, system and service account credentials to be unique per system or account, particularly in high-privilege contexts. This is a specific rule within the controlled allocation and management of authentication information required by Annex A 5.17. Annex A 5.17 is broader, covering the whole management process for authentication information, including advising personnel on its appropriate handling.
ASD Essential Eight: 1 mapping
This control partially overlaps E8-RA-ML2.5.
IT.PRO-13.6 requires user, machine, system and service account credentials to be unique per system or account, especially where privileged; E8-RA-ML2.5 requires break glass, local administrator and service account credentials to be long, unique, unpredictable and managed, a specific case of that.
ASD Information Security Manual: 3 mappings
This control partially overlaps ISM-1227.
IT.PRO-13.6 requires user, machine, system and service account credentials to be unique per system or account, especially where privileged; ISM-1227 requires credentials set for user accounts to be randomly generated, which supports that uniqueness for user accounts.
This control partially overlaps ISM-1596.
IT.PRO-13.6 requires user, machine, system and service account credentials to be unique per system or account, especially where privileged; ISM-1596 requires users not to reuse credentials across different systems, covering the user side of that.
This control partially overlaps ISM-1953.
IT.PRO-13.6 requires user, machine, system and service account credentials to be unique per system or account, especially where privileged; ISM-1953 requires each domain's built-in Administrator account credentials to be long, unique, unpredictable and managed, a specific high-privilege case.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.