ASD ISM 1380 Privileged users work in separate privileged and unprivileged operating environments
What it says
Privileged human users use separate privileged and unprivileged operating environments.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishPeople who hold privileged access do their administrative work in one operating environment and their everyday computing in a different one, so the two never share a session.
This control is about the people in your organisation who hold privileged access, such as system administrators, and the operating environment they sit in when they use that access. It asks that each of those people has two distinct operating environments: one that is used only for privileged activities, and one that is used for unprivileged, everyday activities such as reading email, browsing the web and working on documents. The person moves between the two environments rather than doing both kinds of work from the same one. It matters because the everyday environment is the one most exposed to attack. It receives email attachments, opens web links and runs ordinary productivity software, and any one of those can be the way malicious code arrives. If the same environment is also where privileged access is exercised, a single phishing email or drive-by download hands the attacker whatever privileges that person holds. Keeping privileged work in its own environment means that compromising the everyday environment does not, by itself, give an attacker a foothold in the privileged one. The control applies to human users only; it is about how people work, not about service or machine accounts.
Free. Save your status, tasks and notes.
Why it matters
If privileged human users perform their administrative work from the same operating environment they use for email, web browsing and general productivity, a compromise of that environment through phishing, a malicious download or a browser exploit directly exposes their privileged access. The attacker inherits the administrator's ability to change configurations, create accounts, access sensitive data and move across systems, turning what should have been a contained user-level incident into a whole-of-environment compromise.
How to implement
The security team compiles and maintains a register of all privileged human users, drawn from directory group memberships and privileged role assignments, so that every person who needs a separate privileged operating environment is known.
The IT operations team provisions a dedicated privileged operating environment for each privileged human user, distinct from the environment that person uses for everyday work, and records which environment is which against the user's name in the register.
The security team writes a short procedure for privileged users that states which activities are privileged and must be done only in the privileged environment, and which are unprivileged and must be done only in the unprivileged environment, and issues it to every privileged user when access is granted.
The identity and access team adds provisioning of the separate privileged operating environment to the privileged-access onboarding workflow, and adds its removal to the offboarding and access-revocation workflow, so environments are created and withdrawn in step with privileged access.
The security team briefs privileged users on why the separation exists and how to move between the two environments during their work, and repeats the briefing whenever the environments or the procedure change.
Keep it running
Day to day, this control shows up as a habit that privileged users must keep and that the organisation must make easy to keep. Each privileged user needs a clearly identified privileged operating environment and a clearly identified unprivileged one, and needs to know which activities belong in each. Privileged activities happen only in the privileged environment; email, web browsing, document work and other everyday tasks happen only in the unprivileged environment.
When someone is granted privileged access for the first time, provisioning the separate privileged environment should be part of the onboarding steps, not an afterthought. When someone loses privileged access, the privileged environment should be withdrawn at the same time. Periodic checks that privileged users still have both environments, and are actually using the privileged one for privileged work, keep the separation from quietly eroding as people look for shortcuts.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the register of privileged human users together with the record of the privileged and unprivileged operating environments assigned to each of them.
Look at
Check that every privileged user in the register has two distinct operating environments recorded, and that none is listed with only one environment for both kinds of work.
Good evidence
Every privileged human user has a separately identified privileged operating environment and a separately identified unprivileged one, with no gaps.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the procedure or guidance issued to privileged users describing which activities belong in the privileged environment and which belong in the unprivileged environment.
Look at
Read it for a clear split of activities between the two environments and for evidence it was issued to privileged users, such as acknowledgements or distribution records.
Good evidence
The guidance plainly assigns privileged activities to the privileged environment and everyday activities to the unprivileged environment, and privileged users have received it.
- Check 3 of 5What an auditor asks for
Ask for
Ask to sit with two or three privileged users and watch how they carry out a privileged task and an everyday task.
Look at
Observe whether they switch to their privileged environment for the privileged task and return to the unprivileged environment for email, browsing or documents.
Good evidence
Privileged work is done only in the privileged environment and everyday work only in the unprivileged one, and users can explain why they keep them apart.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the onboarding and offboarding records of privileged users who joined or left the privileged group in the review period.
Look at
Check that the separate privileged operating environment was provisioned when privileged access was granted and withdrawn when it was removed.
Good evidence
Environment provisioning and removal line up with the dates privileged access was granted and revoked for each user sampled.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the most recent periodic check confirming that privileged users still hold and use separate environments.
Look at
Look for the date of the check, who performed it, which users were covered and any exceptions found and followed up.
Good evidence
A recent check covers all privileged users, and any user found doing privileged work from an unprivileged environment has been corrected.
Mappings
Closest match in ASD Essential Eight: E8-RA-ML1.5, Privileged users use separate privileged and unprivileged environments, which asks for the same thing.
ASD Essential Eight: 6 mappings
This control is equivalent to E8-RA-ML1.5.
ISM-1380 requires privileged human users to use separate privileged and unprivileged operating environments for administrative versus everyday work. E8-RA-ML1.5 states the same separation requirement for privileged users and environments. Both controls are aligned in intent, scope and implementation outcome (two distinct operating environments to prevent session/context crossover).
This control is broader than E8-RA-ML2.3.
ISM-1380 requires privileged human users to use separate privileged and unprivileged operating environments. E8-RA-ML2.3 supports ISM-1380 by constraining implementation choices: it prevents privileged environments being virtualised within unprivileged environments, reducing the risk of boundary bypass or shared-session artefacts. ISM-1380 defines the separation outcome, while E8-RA-ML2.3 is a design constraint that strengthens the separation.
- E8-RA-ML1.3Prevent privileged user accounts from accessing internet, email and web servicesPartially overlaps
This control partially overlaps E8-RA-ML1.3.
ISM-1380 requires privileged users to separate administrative work from everyday computing by using different operating environments. E8-RA-ML1.3 supports ISM-1380 by reducing exposure of privileged accounts to common infection vectors (internet, email, web services), which complements the goal of keeping privileged activity isolated. ISM-1380 is about environment/session separation, whereas E8-RA-ML1.3 is about limiting network/service exposure for privileged accounts.
This control supports E8-RA-ML1.6.
ISM-1380 requires privileged human users to use separate privileged and unprivileged operating environments to avoid shared sessions and cross-contamination. E8-RA-ML1.6 supports ISM-1380 by preventing unprivileged accounts from logging into privileged environments, reinforcing the boundary from the opposite direction. ISM-1380 is about how privileged users operate day-to-day, whereas E8-RA-ML1.6 is a login policy control that helps maintain that separation.
This control supports E8-RA-ML1.7.
ISM-1380 requires privileged human users to work in separate privileged and unprivileged operating environments. E8-RA-ML1.7 supports ISM-1380 by enforcing separation through a specific technical restriction: preventing privileged accounts from logging on to unprivileged environments. ISM-1380 is broader in that it focuses on the user practice/outcome of separation, while E8-RA-ML1.7 is one enforcement mechanism.
This control supports E8-RA-ML2.4.
ISM-1380 requires privileged users to perform administration in a separate privileged operating environment from their standard user environment. E8-RA-ML2.4 supports ISM-1380 by prescribing jump servers as a controlled pathway for administrative activities, which helps implement and enforce that separate privileged environment. ISM-1380 does not mandate jump servers specifically, and E8-RA-ML2.4 does not necessarily require a fully separate daily-use environment for the user outside the admin pathway.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.