ASD Essentials IT.PRO-12.2 Restrict Account and Role Management and Privileged Functions to Authorised Administrative Roles
What it says
Grant only authorised administrative roles permissions to create, modify or delete accounts and roles, and access privileged functions or applications.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishLets only authorised admin roles create, change or delete accounts and roles, or use admin functions and applications.
Setting up accounts and using admin tools are powerful jobs, so only approved admin roles should do them. To meet this, nobody else can create, change or delete accounts and roles, or use admin tools and apps. Close indirect routes too, such as an ordinary user who owns an admin group and can add members. Keep powers handed to other teams (delegated powers) narrow and audited. The riskiest changes need approval before they happen.
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
- Business systems (does not apply)
- User devices (does not apply)
Why it matters
When ordinary accounts, or accounts given broad delegated powers, can manage accounts or reach admin tools, one takeover is enough. The attacker can create accounts and give themselves rights. That control lasts and looks like routine admin work.
How to implement
The identity and access owner should define the approved admin roles for in-scope systems, and what each may manage.
Have the head of security authorise them, and grant the rights only through roles, never to a person.
Identity administrators should remove the right to create, change or delete accounts and roles from everyone else.
Do this in the directory and in each device's or app's own settings, and close indirect routes such as group ownership.
The identity team should limit each delegated power, such as service desk password resets, to the tasks and accounts it needs, never admin accounts.
Record its owner and reason, and audit it on a schedule set by risk.
System owners should let only approved admin roles reach admin tools and apps, such as the identity admin console and firewall management screens.
Treat operating system security settings as admin-only: standard users must not bypass, switch off or change them.
The head of security should define which identity and access changes are high-impact, such as a new admin account or a wider role.
The identity team then sets each one to need recorded approval before it takes effect.
Keep it running
The identity team routes every request for admin access, or a new or wider role, through the approval process. It investigates any change made outside that process. Before a system goes live, give its admin functions to approved roles only. Firewalls and similar devices often keep their own local users, so include them in every audit. Follow ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the register of approved admin roles and who authorised each one.
Look at
Whether roles on sampled systems match the register, or rights sit with individuals or unlisted groups.
Good evidence
Every admin right on sampled systems is held through an approved, authorised role.
- Check 2 of 5What an auditor asks for
Ask for
Request reports of who can create, change or delete accounts and roles, centrally and on devices.
Look at
Whether any ordinary user, group owner, self-service setting or app account holds these rights.
Good evidence
Every report, central and local, shows these rights held only by approved admin roles.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the list of delegated powers, with owners and reasons, and their latest audit.
Look at
Whether any are broader than the task needs, reach admin accounts, go unaudited, or have open findings.
Good evidence
Delegated powers name their owner, reason and tasks, exclude admin accounts and are audited on schedule.
- Check 4 of 5What an auditor asks for
Ask for
Request access lists for admin tools and apps, then have a standard user try them.
Look at
Whether anyone outside the approved roles can use them, or standard users can change operating system security.
Good evidence
The standard user is refused, and only approved roles can use admin tools and apps.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the list of high-impact identity and access changes and a sample of recent ones.
Look at
Whether each sampled change was approved beforehand, and which change types skip the approval process.
Good evidence
Each sampled change was approved before it took effect, and unapproved changes are blocked.
ASD indicators of good practice (7)
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(2)
- NE-1Non-administrative users can create, modify or delete accounts or roles.
- NE-2Delegated permissions are broad and have not been audited.
Partially effective(2)
- PE-1Permissions are restricted to administrative roles but some delegated permissions are broader than required.
- PE-2Approval workflows exist for some high-impact changes but not all.
Fully effective(3)
- FE-1Only designated administrative roles can create, modify or delete accounts and roles.
- FE-2Delegated permissions are audited and scoped to the minimum required.
- FE-3Approval workflows are enforced for high-impact identity and access changes.
Mappings
Closest match in ISO/IEC 27001: A.5.18, Managing Access Rights to Information Assets, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.5.18.
IT.PRO-12.2 requires that only authorised administrative roles can create, modify or delete accounts and roles, or access privileged functions or applications. By limiting who can change accounts and roles, it protects the integrity of the provisioning, modification and removal of access rights required by Annex A 5.18. Annex A 5.18 defines the access rights process itself, while IT.PRO-12.2 restricts who is able to carry it out.
This control partially meets A.8.2.
IT.PRO-12.2 requires that only authorised administrative roles are given permissions to create, modify or delete accounts and roles, and to access privileged functions or applications. This is a specific restriction on the allocation of privileged access rights, which Annex A 8.2 requires to be restricted and managed. Annex A 8.2 is broader, also covering how the use of privileged access rights is managed over time.
ASD Essential Eight: 3 mappings
This control partially overlaps E8-RA-ML1.1.
IT.PRO-12.2 requires only authorised administrative roles to manage accounts and roles or access privileged functions; E8-RA-ML1.1 requires privileged access requests to be validated when first requested, supporting that authorisation step.
- E8-RA-ML1.3Prevent privileged user accounts from accessing internet, email and web servicesPartially overlaps
This control partially overlaps E8-RA-ML1.3.
IT.PRO-12.2 requires only authorised administrative roles to manage accounts and roles or access privileged functions; E8-RA-ML1.3 blocks privileged accounts from the internet, email and web services unless explicitly authorised, a related limit on privileged account use.
This control partially overlaps E8-RA-ML3.1.
IT.PRO-12.2 requires only authorised administrative roles to manage accounts and roles or access privileged functions; E8-RA-ML3.1 limits privileged access to what users and services need for their duties, overlapping on restricting privileged access.
ASD Information Security Manual: 1 mapping
This control partially overlaps ISM-1584.
IT.PRO-12.2 requires only authorised administrative roles to manage accounts and roles or access privileged functions; ISM-1584 prevents unprivileged users from bypassing, disabling or modifying operating system security functionality, keeping those functions out of their reach.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.