ASD ISM 0445 Dedicated privileged accounts used solely for privileged duties
What it says
Privileged human users are assigned a dedicated privileged user account to be used solely for duties requiring privileged access.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEach person who needs privileged access gets a separate admin account, kept apart from their everyday account and used only when the task genuinely needs elevated rights.
People who administer systems (creating users, changing configurations, installing software, managing security settings) need more power than an ordinary user. This control says that power must not live in the account they use for email, web browsing and day-to-day work. Instead, each privileged human user is issued a second, dedicated account that carries the elevated rights, and that account is used only for the duties that actually require them. Everything else is done from the person's standard account. Why it matters: the everyday account is the one most exposed to attack. It reads email, opens attachments, browses the web and signs in to many services, so it is the most likely to be phished or compromised. If that same account also holds administrator rights, one successful phishing email hands an attacker control of the environment. Separating the two means a compromise of the everyday account does not automatically become a compromise of privileged access, and the dedicated account is exposed far less often because it is only used when it is genuinely needed. It also makes privileged activity easier to distinguish from routine activity, because it comes from a clearly identifiable account.
Free. Save your status, tasks and notes.
Why it matters
If administrators perform everyday work from accounts that carry privileged rights, a single phishing email, malicious attachment or compromised website can give an attacker full administrative control of systems. Malware that runs in the context of a privileged account can disable security tools, create backdoor accounts, spread across the network and access or destroy data at scale. Mixing privileged and routine activity in one account also makes it much harder to tell legitimate administration from misuse, and increases the chance of accidental damage from routine tasks being run with elevated rights.
How to implement
The identity or IT operations team defines a naming convention for privileged accounts (for example a `-adm` suffix or `admin.` prefix) and applies it consistently across the directory, cloud tenants and standalone systems so that privileged accounts are easy to identify and report on.
The access management team updates the privileged access request and approval workflow so that approval for privileged duties results in the creation of a separate dedicated account for that named person, rather than adding elevated rights to their existing standard account.
System administrators remove privileged group memberships and role assignments from standard user accounts, re-assigning those rights to each person's dedicated privileged account, and then verify through a directory report that no standard accounts remain in privileged groups.
The security team publishes clear direction that the dedicated privileged account is signed in to only for tasks that need elevated rights and that all other work is done from the person's standard account, and samples sign-in logs to confirm privileged accounts appear only against administrative consoles and systems.
The identity team records each dedicated privileged account as a distinct object in provisioning records, tied to the single named person who holds it, so that every privileged account can be reconciled against the list of people approved for privileged duties and no shared or generic privileged accounts are in use by human users.
Keep it running
In practice this means every administrator holds at least two identities: a standard account for email, documents and general work, and a separately named privileged account (for example a `-adm` or `admin.` suffixed account) that is only signed in to for administrative tasks. The dedicated account is issued when a person is approved for privileged duties, tied to that named individual, and not shared with anyone else.
Day to day, staff should switch to the privileged account only for the specific task that needs it and then return to their standard account. Privileged accounts should not be used to read email, browse the web or do ordinary work. Provisioning records should treat the privileged account as a distinct object tied to its owner, so it can be reconciled against the list of people approved to hold privileged access. Checks of group membership and sign-in activity can confirm that no standard accounts have quietly accumulated privileged group memberships and that no privileged accounts are being used for routine activity.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the current list of people approved to hold privileged access and the directory export of privileged accounts.
Look at
Match each approved person to a separately named privileged account that is distinct from their standard account.
Good evidence
Every privileged user has their own dedicated privileged account, and there are no privileged accounts that cannot be traced to a named approved individual.
- Check 2 of 5What an auditor asks for
Ask for
Ask for a report of the members of privileged groups and roles across the directory, cloud tenants and key systems.
Look at
Check whether any standard everyday user accounts appear as members of privileged groups or hold administrative roles.
Good evidence
Privileged group and role membership contains only dedicated privileged accounts, with no standard accounts holding elevated rights.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the privileged account provisioning procedure and a sample of recent access requests.
Look at
Confirm the procedure creates a separate dedicated account on approval rather than elevating the person's existing account, and that the samples show this happening.
Good evidence
The documented process and the completed requests both show dedicated privileged accounts being created as a distinct step.
- Check 4 of 5What an auditor asks for
Ask for
Ask how staff are directed to use their dedicated privileged account, and request a sample of sign-in records for a few privileged accounts.
Look at
Look for documented direction that the dedicated account is used only for administrative tasks, and sign-in records showing privileged accounts appearing against administrative consoles and systems rather than everyday services.
Good evidence
Documented direction and sign-in records together show privileged accounts are used solely for duties that require privileged access.
- Check 5 of 5What an auditor asks for
Ask for
Interview a sample of administrators and ask them to show which account they use for email and general work and which they use for administration.
Look at
Confirm each administrator holds two distinct accounts and describes using the privileged one only for tasks that require elevated rights.
Good evidence
Administrators consistently hold a separate dedicated account and describe using it solely for privileged duties.
Mappings
Closest match in ASD Essential Eight: E8-RA-ML1.2, Dedicated privileged user accounts for privileged duties, which asks for the same thing.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.2.
ISM-0445 requires privileged human users to be issued a dedicated privileged account used solely for privileged duties. ISO/IEC 27001:2022 Annex A 8.2 (Management of Privileged Access Rights) is broader, covering how privileged rights are allocated, restricted, reviewed, and managed across the organisation. ISM-0445 is a specific privileged-access management measure (separation of admin and standard accounts) that would contribute to meeting Annex A 8.2 but does not cover all its management expectations.
This control partially overlaps A.5.3.
Annex A 5.3 requires segregation of conflicting duties so a person cannot perform incompatible activities without detection or independent oversight. ISM-0445 relates by requiring privileged users to use separate dedicated privileged accounts for privileged activities, which helps separate day-to-day user actions from administrative actions and improves accountability. ISM-0445 is a specific identity/account design control, while Annex A 5.3 is broader and also includes process separations such as change requester vs change implementer.
ASD Essential Eight: 8 mappings
This control is equivalent to E8-RA-ML1.2.
ISM-0445 requires privileged human users to be assigned a dedicated privileged user account used solely for duties requiring privileged access. E8-RA-ML1.2 states the same requirement: privileged users are assigned a dedicated privileged account to be used only for duties requiring privileged access. Both controls have the same intent (separating admin and standard identities) and comparable scope and depth.
This control partially overlaps E8-RA-ML2.4.
ISM-0445 requires privileged users to use a dedicated privileged account only when performing privileged duties. E8-RA-ML2.4 focuses on the pathway for administration by requiring administrative activities to be conducted through jump servers, which commonly use (and can enforce) separate privileged accounts. ISM-0445 is about account separation, while E8-RA-ML2.4 is about administrative access architecture and does not, by itself, mandate separate accounts.
- E8-RA-ML3.3Just-in-time administration is used for administering systems and applications.Partially overlaps
This control partially overlaps E8-RA-ML3.3.
ISM-0445 requires privileged users to be issued a dedicated privileged account used only for privileged duties. E8-RA-ML3.3 requires just-in-time administration, which can change how privileged accounts are provisioned/activated and often works in tandem with separate admin accounts. ISM-0445 mandates separation of accounts, while E8-RA-ML3.3 focuses on time-bounded elevation and does not necessarily require separate named accounts.
This control supports E8-RA-ML1.3.
ISM-0445 requires each privileged human user to have a dedicated privileged account that is used only for privileged duties. E8-RA-ML1.3 strengthens that separation by constraining what those privileged accounts can do (blocking internet/email/web access except where explicitly authorised), reducing the likelihood the privileged account is used for day-to-day activity. E8-RA-ML1.3 is about network/service access restrictions, whereas ISM-0445 is about account separation and correct use of that account.
This control supports E8-RA-ML1.4.
ISM-0445 requires privileged users to use a separate privileged account only when elevated rights are needed. E8-RA-ML1.4 supports this by ensuring any online service access granted to privileged accounts is tightly scoped to essentials, discouraging non-privileged, routine usage of the privileged identity. E8-RA-ML1.4 governs authorisation boundaries for online services, while ISM-0445 governs account assignment and intended purpose.
This control supports E8-RA-ML1.5.
ISM-0445 requires privileged users to have a dedicated privileged account used only for privileged duties, separating admin activity from standard activity. E8-RA-ML1.5 supports and operationalises that separation by requiring separate privileged and unprivileged operating environments, reducing the chance the privileged account is used in a standard browsing/user context. E8-RA-ML1.5 adds an environment/device boundary that ISM-0445 does not explicitly require.
This control supports E8-RA-ML1.6.
ISM-0445 requires a separation between standard user accounts and privileged accounts, with privileged accounts used only for privileged duties. E8-RA-ML1.6 supports that separation by technically preventing unprivileged accounts from logging on to privileged operating environments, reducing the incentive to use the everyday account for admin tasks. E8-RA-ML1.6 is an environment logon restriction, while ISM-0445 is an account assignment and usage rule.
This control depends on E8-RA-ML1.7.
ISM-0445 requires dedicated privileged accounts to be used only for duties requiring privileged access. E8-RA-ML1.7 complements this by preventing privileged accounts from logging on to unprivileged operating environments, helping ensure the dedicated privileged account is not used for routine activity. ISM-0445 mandates account separation, whereas E8-RA-ML1.7 enforces where that privileged account may be used.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.