Skip to content
System management
ASD ISMISM-1689

ASD ISM 1689 Block privileged account logons to unprivileged operating environments

What it says

Privileged user accounts (excluding local administrator accounts) cannot be used to log on to unprivileged operating environments.

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

What it means

In plain English

Privileged user accounts, other than local administrator accounts, must be technically prevented from logging on to unprivileged operating environments such as everyday user workstations.

An unprivileged operating environment is the ordinary computing environment where staff read email, browse the web and open documents. It is the part of your fleet most exposed to phishing, malicious attachments and drive-by downloads. A privileged user account is one that holds elevated rights, for example a domain administrator, a server administrator or an account used to manage security tooling. This control says those privileged accounts (with the single exception of local administrator accounts, which exist on the individual machine rather than in the directory) cannot be used to log on to unprivileged operating environments. It is not enough to tell people not to do it; the logon must actually be blocked. Why it matters: when a privileged account logs on to an ordinary workstation, its credentials, tokens or session material land on a machine that may already be compromised. Attackers routinely harvest those credentials and use them to move from one infected workstation to domain controllers, servers and management consoles. Keeping privileged accounts off unprivileged environments removes one of the most common paths from a single phished user to a whole-of-network compromise.

Why it matters

If privileged accounts can log on to unprivileged operating environments, a single compromised workstation can expose domain or system administrator credentials to an attacker. Those credentials can then be replayed to reach servers, identity systems and security tooling, turning a contained malware infection into a full network compromise, with data theft, ransomware deployment and loss of control over the environment as likely outcomes.

How to implement

  1. The identity or directory administrator should enumerate every privileged user account and privileged group in the directory, excluding local administrator accounts, and record the list as the population that the logon restriction must apply to.

  2. The endpoint or Group Policy administrator should apply deny logon rights (deny log on locally, deny log on through Remote Desktop Services, deny log on as a batch job and deny log on as a service) for all privileged groups to every unprivileged workstation, using a policy that is linked to the organisational units or device groups holding unprivileged operating environments.

  3. The platform team should provide privileged users with a separate privileged operating environment, such as a dedicated administrative workstation, jump host or hardened virtual session, so that privileged accounts have a sanctioned place to be used and the restriction does not drive workarounds.

  4. The service desk lead should issue each privileged user a standard unprivileged account for their everyday device and document the two-account workflow in onboarding material, so staff log on to unprivileged environments only with unprivileged credentials.

  5. The security operations team should configure the SIEM or endpoint logging to alert on any successful interactive or remote logon by a privileged account to an unprivileged device, and should re-test the deny rules whenever a new device image, privileged group or operating system version is introduced.

Keep it running

Day to day, this control lives in your directory and endpoint configuration rather than in a document. Logon restrictions (for example "deny log on locally", "deny log on through Remote Desktop Services" and related deny rights applied to privileged groups) need to be enforced on every unprivileged workstation and kept in place as machines are rebuilt, re-imaged or added.

Privileged users need a supported way to do their work without the restriction becoming an obstacle, otherwise workarounds appear. That usually means a separate privileged environment (a dedicated admin workstation, a jump host or a hardened virtual session) from which privileged accounts are used, while the person's ordinary unprivileged account is what they log on to their everyday device with.

Keep the membership of privileged groups accurate, because the restriction is only as complete as the list of accounts it applies to. When a new privileged role or group is created, add it to the deny rules at the same time. Local administrator accounts are outside the scope of this control, but they should still be clearly identified so that nobody mistakes a domain-based privileged account for a local one.

Review failed logon events for privileged accounts on unprivileged devices periodically. A steady trickle of denied attempts usually indicates someone who has not been shown the correct workflow; a sudden spike may indicate credential misuse.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the inventory of privileged user accounts and privileged groups, and for the organisation's definition of which devices are unprivileged operating environments.

    Look at

    Check that the inventory is complete against the live directory and that local administrator accounts are separately identified as out of scope.

    Good evidence

    A current, reconciled list of privileged accounts and groups exists, unprivileged environments are clearly defined, and local administrator accounts are distinguished from directory-based privileged accounts.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for the Group Policy objects, configuration profiles or equivalent settings that deny privileged accounts logon to unprivileged workstations.

    Look at

    Look at which deny logon rights are set, which privileged groups they name, and which device scopes the policy is applied to.

    Good evidence

    Deny logon rights cover local, remote desktop, batch and service logons for all privileged groups, and the policy applies to every unprivileged workstation scope.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for a resultant policy report or configuration export from a sample of unprivileged workstations.

    Look at

    Confirm the deny rules are actually present and effective on the endpoint, not just defined centrally, and that no local override removes them.

    Good evidence

    Each sampled workstation shows the deny logon rights in effect for the full set of privileged groups.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask to observe a test in which a privileged account attempts an interactive and a remote desktop logon to an unprivileged workstation.

    Look at

    Watch whether the logon is rejected by the operating system rather than merely discouraged by policy or training.

    Good evidence

    Both logon attempts fail with a logon rights denial and the failure is recorded in the security log.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for security logs or SIEM reports covering successful logons by privileged accounts over a recent period.

    Look at

    Filter for successful logons where the target device is an unprivileged operating environment and check how any such events were handled.

    Good evidence

    No successful privileged logons to unprivileged devices appear, or any that do have been investigated and the gap in the deny rules closed.

Mappings

Closest match in ASD Essential Eight: E8-RA-ML1.7, Prevent privileged user accounts from logging on to unprivileged environments, which asks for the same thing.

ISO 27001

ISO/IEC 27001: 1 mapping

  • A.8.2Management of privileged access rightsPartially meets
Essential Eight

ASD Essential Eight: 4 mappings

  • E8-RA-ML1.7Prevent privileged user accounts from logging on to unprivileged environmentsEquivalent
  • E8-RA-ML1.6Unprivileged user accounts restricted from logging on to privileged environmentsPartially overlaps
  • E8-RA-ML1.5Privileged users use separate privileged and unprivileged environmentsSupports
  • E8-RA-ML2.3Privileged environments are not virtualised within unprivileged environmentsSupports

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