ASD Essentials IT.PRO-12.3 Provision User, Administrative and Non-Person Accounts with Minimum Required Privileges
What it says
Provision user, administrative and non-person accounts with only the minimum access and privileges required to perform defined operational functions.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishGives every account, whether used by staff, admins, apps or systems, only the minimum access its defined tasks need.
Every account should get only the access its job needs, and nothing extra by default. To meet this, set up each account from a written list of what its job needs. Administrators get a separate admin account that cannot be used for email or web browsing. Their everyday account has no admin powers. Accounts used by apps are limited to the one system-to-system connection they serve, such as an HR system updating the staff directory.
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
Some accounts get broad rights by default, or administrators use one account for everything. Then one stolen login gives an attacker far more access than it should. They can create accounts to stay in, or quietly change existing ones.
How to implement
The identity and access owner and system owners should define each job function and the minimum access it needs.
Record it as an access profile for user, admin and app accounts, such as a table of groups per role.
The identity team or service desk should set up each new account or access request from its profile, starting from no access.
Record who approved anything extra, and why.
The identity team should give each administrator a separate admin account for only the systems they manage, and remove admin rights from everyday accounts.
Record any exception with its reason and approval.
Platform administrators should block admin accounts from email, web browsing and online services, using mailbox, web filter and sign-in settings.
The only exception is a service the account is approved to manage.
Platform and app owners should limit each app account to what its one system-to-system connection needs, and record its owner and purpose.
Run server apps under their own minimum-access accounts, letting the directory manage their passwords where supported.
Keep it running
The identity team or service desk handles every account request against the written access list for that job. They record the reason for anything extra. Watch for broad default groups, copying a colleague's access, and built-in all-powerful admin roles. Follow ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems. Include local admin and app accounts set up directly on devices, outside the normal process.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the access profiles for each job function, and the account set-up procedure.
Look at
Whether profiles cover all account types and ASD domains, or just point to broad default groups.
Good evidence
Profiles list specific access per function for every account type, and every request starts from one.
- Check 2 of 5What an auditor asks for
Ask for
Request set-up records and live access for sampled staff, admin, app and firewall accounts.
Look at
Whether live access goes beyond the profile through broad defaults, copied access or unexplained extras.
Good evidence
Each sampled account holds only its profile's access, and any extra is justified and approved.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the list of administrators, their admin accounts and any recorded exceptions.
Look at
Whether any administrator lacks a separate account, everyday accounts hold admin rights, or exceptions lack a reason.
Good evidence
Sampled everyday accounts hold no admin rights, and every exception has a recorded reason and approval.
- Check 4 of 5What an auditor asks for
Ask for
Ask to see an admin account try to open email and browse the web.
Look at
Whether the block is a technical setting or relies only on policy and people's good habits.
Good evidence
Email and web access are refused by settings, except for services the account manages.
- Check 5 of 5What an auditor asks for
Ask for
Request the register of app accounts with owners, purposes and access, and inspect a sample.
Look at
Whether app accounts hold broad admin rights, are shared, or have no recorded owner or purpose.
Good evidence
Each sampled app account has a named owner and purpose, and access for one connection only.
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-1Accounts are provisioned with broad default permissions that exceed operational requirements.
- NE-2Administrative and day-to-day user functions share the same account, with no separate privileged accounts.
Partially effective(2)
- PE-1Minimum privilege provisioning is defined but not consistently applied to all account types.
- PE-2Administrative accounts are separated from user accounts but some exceptions exist without documented justification.
Fully effective(3)
- FE-1All accounts are provisioned with documented minimum permissions aligned to defined operational functions.
- FE-2Separate accounts are allocated for privileged and day-to-day functions, and controls prevent privileged use from day-to-day context.
- FE-3Non-person and service accounts are scoped to their specific integration requirements.
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.
IT.PRO-12.3 requires user, administrative and non-person accounts to be provisioned with only the minimum access and privileges needed for defined operational functions. This puts into practice least privilege, a core principle of the access control rules required by Annex A 5.15. Annex A 5.15 is broader, requiring rules for both physical and logical access to be established and implemented based on business and information security requirements.
This control partially meets A.5.18.
IT.PRO-12.3 requires user, administrative and non-person accounts to be provisioned with only the minimum access and privileges needed for defined operational functions. This applies least privilege at the provisioning stage of the access rights process required by Annex A 5.18. Annex A 5.18 is broader, also covering the review, modification and removal of access rights.
This control partially meets A.8.3.
IT.PRO-12.3 requires user, administrative and non-person accounts to be provisioned with only the minimum access and privileges needed for defined operational functions. Provisioning to this least privilege standard directly limits access in the way Annex A 8.3 requires, restricting access to information and other associated assets in line with the access control policy. IT.PRO-12.3 concentrates on what each account is granted, including operational privileges, while Annex A 8.3 covers the technical restriction of access to information more generally.
This control partially overlaps A.8.2.
IT.PRO-12.3 requires user, administrative and non-person accounts to be provisioned with only the minimum access and privileges needed for defined operational functions. For administrative accounts this restricts the allocation of privileged access rights, which is central to Annex A 8.2. IT.PRO-12.3 applies least privilege to every account type, while Annex A 8.2 focuses on privileged access and also covers managing its use.
ASD Essential Eight: 4 mappings
This control partially overlaps E8-RA-ML1.2.
IT.PRO-12.3 requires user, administrative and non-person accounts to be provisioned with only the minimum access and privileges they need; E8-RA-ML1.2 gives privileged users a dedicated privileged account used solely for privileged duties, a related rule for administrative accounts.
- 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.3 requires user, administrative and non-person accounts to be provisioned with only the minimum access and privileges they need; E8-RA-ML1.3 blocks privileged accounts from the internet, email and web services unless explicitly authorised, limiting administrative account access.
This control partially overlaps E8-RA-ML1.4.
IT.PRO-12.3 requires user, administrative and non-person accounts to be provisioned with only the minimum access and privileges they need; E8-RA-ML1.4 strictly limits privileged accounts authorised to access online services to what their duties require, a narrower case of that.
This control partially overlaps E8-RA-ML3.1.
IT.PRO-12.3 requires user, administrative and non-person accounts to be provisioned with only the minimum access and privileges they need; E8-RA-ML3.1 limits privileged access to what users and services need for their duties, covering the privileged side of that.
ASD Information Security Manual: 3 mappings
This control partially overlaps ISM-1249.
IT.PRO-12.3 requires user, administrative and non-person accounts to be provisioned with only the minimum access and privileges they need; ISM-1249 requires server applications to run as a separate user account with minimum privileges, a specific case for application accounts.
This control partially overlaps ISM-1619.
IT.PRO-12.3 requires user, administrative and non-person accounts to be provisioned with only the minimum access and privileges they need; ISM-1619 requires service accounts to be created as group Managed Service Accounts, a related rule for those non-person accounts that does not itself limit their privileges.
This control partially overlaps ISM-1852.
IT.PRO-12.3 requires user, administrative and non-person accounts to be provisioned with only the minimum access and privileges they need; ISM-1852 limits unprivileged access to what users need for their duties or functions, covering the user account part.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.