ASD ISM 1883 Limit authorised privileged account online service access to duties
What it says
Privileged user accounts explicitly authorised to access online services are strictly limited to only what is required for users to undertake their duties or functions.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishWhere a privileged account has been explicitly allowed to reach online services, that access is cut back to only the specific services the person genuinely needs for their role.
Privileged accounts (administrator and similar high-power accounts) sometimes need to reach online services to do their work, for example a cloud management console or a vendor's update portal. When an organisation explicitly authorises a privileged account to access online services, this control says that access must be strictly limited to only what the user needs to carry out their duties or functions. It is not a general licence to browse or use any online service from a privileged account. This matters because privileged accounts are the most valuable target for an attacker. Every additional online service a privileged account can reach is another path for phishing, malicious downloads, credential theft or data exfiltration to reach an account that can change systems, create users or disable security controls. Keeping the authorised set of online services as narrow as possible shrinks the attack surface around the accounts that can do the most damage if compromised.
Free. Save your status, tasks and notes.
Why it matters
If authorised online access for privileged accounts is broader than the role requires, a compromised or misused privileged account can be steered to arbitrary websites and cloud services. That opens the door to malware delivered through the browser, credential harvesting through look-alike login pages, and uploading of sensitive data to services outside the organisation's control. Because the account is privileged, any resulting compromise can escalate quickly across systems, and the organisation cannot demonstrate that its exceptions to privileged online access were justified and contained.
How to implement
Security or platform team: build a register of every privileged account that has been explicitly authorised to access online services, recording the account, the named online services, the duty or function that requires them and the approver, so that the authorised scope is defined before any technical rule is created.
Identity and access owners: require each authorisation request for privileged online access to list specific services (by URL, domain or cloud tenant) tied to a stated duty, and reject requests that ask for general internet or broad category access from a privileged account.
Network or endpoint administrators: enforce the approved scope with technical controls such as web proxy allow-lists, firewall rules, secure administrative workstation policies or cloud conditional access, configured so each privileged account can only reach the services on its register entry.
System owners and line managers: when a privileged user's duties change, a project ends or a service is retired, submit a change to reduce or revoke the online service authorisation and have administrators update the allow-list to match on the same change ticket.
Security governance: schedule a recurring review (for example quarterly) that exports the live allow-list or policy configuration for privileged accounts, compares it against the register, and removes any online service access that is not backed by a current, duty-based authorisation.
Keep it running
Day to day, this control lives in the exception process for privileged accounts. Each time a privileged account is authorised to access online services, the request should name the specific services and the duty that requires them, and the enforcement (proxy allow-lists, firewall rules, cloud conditional access or similar) should be configured to match that list rather than granting broad internet access.
Keep a register of which privileged accounts hold online service authorisations, what services each is limited to and who approved it. When roles change, projects finish or a service is no longer used, tighten or remove the authorisation. Periodic reviews should compare the configured allow-lists against the approved scope and remove drift, because allow-lists tend to grow over time as one-off requests are added and never revisited.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the register or list of privileged accounts that have been explicitly authorised to access online services.
Look at
Check that each entry names the specific online services permitted and the duty or function that justifies them, rather than a blanket grant of internet access.
Good evidence
Every authorised privileged account has a narrow, named set of services tied to a documented job need, and there are no entries that simply say all or general web access.
- Check 2 of 5What an auditor asks for
Ask for
Request the technical configuration that enforces online access for privileged accounts, such as proxy allow-lists, firewall rules or cloud conditional access policies.
Look at
Compare the services actually reachable in the configuration against the approved scope in the register for a sample of privileged accounts.
Good evidence
The enforced allow-list matches the approved list for each sampled account, with no extra services or wildcard rules that widen access beyond what was authorised.
- Check 3 of 5What an auditor asks for
Ask for
Ask for a sample of the original authorisation requests and approvals for privileged accounts accessing online services.
Look at
Look for whether the request states the duty requiring access and lists the specific services, and whether the approver confirmed the minimum needed.
Good evidence
Requests are specific and duty-based, approvals show the scope was challenged or trimmed where appropriate, and approvals were granted before access was configured.
- Check 4 of 5What an auditor asks for
Ask for
Request evidence of the most recent review of online service access held by privileged accounts.
Look at
Check the review date, who performed it, what discrepancies were found between configured and approved access, and what was removed or tightened as a result.
Good evidence
Reviews happen on a defined cycle, discrepancies are recorded and resolved, and the review demonstrates that access has been reduced when it was no longer required.
- Check 5 of 5What an auditor asks for
Ask for
Ask for examples of privileged online service authorisations that were changed or revoked following a role change, project completion or service retirement.
Look at
Trace the change from the trigger event through the ticket to the updated register entry and the modified technical rule.
Good evidence
Authorisations are adjusted promptly when duties change, and the register and enforcement configuration both reflect the reduced scope.
Mappings
Closest match in ASD Essential Eight: E8-RA-ML1.4, Limit privileged user accounts to essential online service access, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.2.
ISM-1883 requires least-privilege restrictions specifically for privileged accounts that are authorised to access online services. ISO/IEC 27001:2022 Annex A 8.2 requires organisations to restrict and manage the allocation and use of privileged access rights in general. ISM-1883 fits within Annex A 8.2 as a more specific privileged access management requirement targeted at online service access.
ASD Essential Eight: 4 mappings
This control is equivalent to E8-RA-ML1.4.
ISM-1883 requires that privileged user accounts authorised to access online services are limited to only what is necessary to perform duties. E8-RA-ML1.4 states the same requirement for privileged accounts explicitly authorised to access online services, with essentially identical scope and intent. Implementing E8-RA-ML1.4 would largely satisfy ISM-1883 for this online-services privilege-limitation requirement.
This control partially meets E8-RA-ML3.1.
ISM-1883 requires that privileged accounts which are explicitly authorised to access online services have that online-service access constrained to what is required for the user's duties or functions. E8-RA-ML3.1 applies the same least-privilege principle to privileged access across systems, applications and data repositories generally. ISM-1883 is a specific instance of E8-RA-ML3.1 focused on the online-services use case rather than all privileged entitlements.
This control partially overlaps E8-RA-ML1.1.
E8-RA-ML1.1 requires organisations to validate privileged access requests at the point they are first raised. This relates to ISM-1883 because validating a request should include confirming the requested privileged access to online services is explicitly authorised and limited to what is necessary for service duties. ISM-1883 focuses on ongoing least-privilege scoping of privileged accounts for services, whereas E8-RA-ML1.1 focuses on the approval/validation step at request time.
- E8-RA-ML1.3Prevent privileged user accounts from accessing internet, email and web servicesPartially overlaps
This control partially overlaps E8-RA-ML1.3.
E8-RA-ML1.3 requires blocking privileged accounts from accessing the internet, email, and web services unless explicitly authorised. ISM-1883 governs exceptions by limiting authorised online service access to what's necessary for duties. E8-RA-ML1.3 focuses on deny-by-default access restriction, while ISM-1883 minimises permissions and scope for allowed cases instead of enforcing a blanket block.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.