ASD ISM 1688 Block unprivileged account logons to privileged operating environments
What it says
Unprivileged user accounts cannot be used to log on to privileged operating environments.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEveryday user accounts are technically prevented from signing in to the hardened systems administrators use for privileged work, keeping ordinary accounts and admin environments apart.
A privileged operating environment is a system built for administrative work, such as a secure administration workstation, a jump host or a management server used to run the network. This control requires that unprivileged user accounts, the everyday accounts staff use for email, browsing and general work, cannot be used to log on to those environments at all. The logon must be blocked by the system, not simply discouraged by policy. The reason is separation. Unprivileged accounts are the most exposed accounts in an organisation: they open email, browse the web and sit on general-purpose workstations that are far more likely to be compromised. If one of those accounts can sign in to a privileged environment, an attacker who has phished or stolen it gains a foothold on the very systems that were built to be trustworthy. Keeping unprivileged accounts off privileged environments means a compromised everyday account cannot be used as a stepping stone into the administrative layer, and the privileged environment stays clean of the browsing, documents and credentials that come with normal user activity.
Free. Save your status, tasks and notes.
Why it matters
If unprivileged accounts can log on to privileged operating environments, a single phished password or a malware infection on a general-purpose workstation can be turned into interactive access to administration systems. From there an attacker can harvest cached privileged credentials, tamper with management tools or pivot to the servers those environments control. The hardening effort put into the privileged environment is undone because the weakest accounts in the organisation are allowed straight into it, and auditors will treat the boundary between user and administrative access as broken.
How to implement
System administrators should define which systems are privileged operating environments (for example secure administration workstations, jump hosts and management servers) and record them in the asset register so the logon restriction can be applied consistently to all of them.
The identity and access team should create dedicated privileged security groups and configure logon rights on each privileged environment so that local, remote desktop, SSH and console logon are permitted only to those groups, using group policy, configuration management or the platform's native logon-rights settings.
System administrators should add an explicit deny for standard user groups (such as Domain Users or the general staff group) to the logon rights of privileged environments, so an unprivileged account is blocked even if it is later added to another group by mistake.
Platform engineers should bake the logon restrictions into the build image or configuration baseline for privileged environments, and have the configuration management tool re-apply them on every build so newly deployed or re-imaged systems inherit the control automatically.
The security operations team should forward logon and denied-logon events from privileged environments to the central logging platform and set an alert for any successful logon by an account that is not a member of the approved privileged groups, so a gap is found and closed promptly.
Keep it running
Day to day this control lives in the logon rights of privileged operating environments. Local, remote desktop, SSH and console logon should be restricted to designated privileged accounts or groups, with everyone else denied by default. Whenever a new privileged environment is built or an existing one is re-imaged, the same deny rules need to be applied from the baseline image or configuration policy so the restriction does not depend on someone remembering to set it.
Account and group changes are the usual way the control drifts. If an unprivileged account is added to a group that carries logon rights, or a privileged account is reused as someone's everyday account, the boundary quietly disappears. Periodic checks of who can log on to each privileged environment, together with review of any denied-logon events, keep the control working after it is first set up.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the list of systems the organisation treats as privileged operating environments and the account or group that is allowed to log on to each.
Look at
Check that the list covers administration workstations, jump hosts and management servers, and that the allowed logon groups contain only privileged accounts.
Good evidence
Every privileged environment is identified and its logon rights point to dedicated privileged groups with no general user groups included.
- Check 2 of 5What an auditor asks for
Ask for
Request the effective logon rights configuration (for example the group policy result or equivalent) from a sample of privileged environments.
Look at
Look at the allow and deny entries for local, remote desktop, SSH and console logon to confirm standard user groups are denied.
Good evidence
Logon rights show explicit denies for unprivileged groups and allows only for the approved privileged groups, matching the documented design.
- Check 3 of 5What an auditor asks for
Ask for
Ask an administrator to attempt a logon to a privileged environment using an ordinary unprivileged account while you observe.
Look at
Watch whether the logon is refused by the system rather than succeeding or prompting for additional steps.
Good evidence
The logon attempt is rejected outright and a denied-logon event is generated.
- Check 4 of 5What an auditor asks for
Ask for
Request the membership of the privileged groups that carry logon rights to these environments, alongside the list of unprivileged user accounts.
Look at
Compare the two lists for overlap and for accounts that are used for both everyday work and privileged access.
Good evidence
No unprivileged or dual-purpose account appears in a group that grants logon to a privileged environment.
- Check 5 of 5What an auditor asks for
Ask for
Ask for logon event records from privileged environments over a recent period, including any denied-logon events.
Look at
Check that all successful logons come from approved privileged accounts and that any attempts by unprivileged accounts were denied and reviewed.
Good evidence
Successful logons are limited to approved privileged accounts, denied attempts are visible in the logs, and there is evidence someone reviewed them.
Mappings
Closest match in ASD Essential Eight: E8-RA-ML1.6, Unprivileged user accounts restricted from logging on to privileged environments, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.2.
ISM-1688 requires that unprivileged user accounts cannot log on to privileged operating environments. ISO/IEC 27001:2022 Annex A 8.2 requires privileged access rights to be restricted and managed, covering broader governance of privileged entitlements and their use. ISM-1688 is a specific restriction pattern (blocking unprivileged logons to privileged environments) that can be implemented as one mechanism under Annex A 8.2.
ASD Essential Eight: 3 mappings
- E8-RA-ML1.6Unprivileged user accounts restricted from logging on to privileged environmentsEquivalent
This control is equivalent to E8-RA-ML1.6.
ISM-1688 requires unprivileged user accounts to be technically prevented from accessing privileged operating environments. E8-RA-ML1.6 mandates the same restriction, ensuring unprivileged accounts cannot log on to such environments. Both controls share a similar focus on technical logon prohibition.
- E8-RA-ML1.7Prevent privileged user accounts from logging on to unprivileged environmentsPartially overlaps
This control partially overlaps E8-RA-ML1.7.
ISM-1688 mandates the prevention of unprivileged accounts accessing privileged environments, while E8-RA-ML1.7 prevents privileged accounts from accessing unprivileged environments. Both involve tier separation through logon restrictions but address distinct directions.
This control depends on E8-RA-ML1.5.
ISM-1688 specifies technical prevention for unprivileged account log-ins to privileged environments. E8-RA-ML1.5 requires the segregation of privileged and unprivileged environments, facilitating the enforcement of ISM-1688's logon controls.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.