Skip to content
System hardening
ASD ISMISM-1592

ASD ISM 1592 Restrict unprivileged users from installing unapproved applications

What it says

Unprivileged human users do not have the ability to install unapproved applications.

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

What it means

In plain English

Standard (non-administrator) staff accounts must be technically unable to install software that the organisation has not approved, so unwanted or malicious programs cannot get onto systems.

This control says that people using ordinary, unprivileged accounts (the everyday staff logins that do not carry administrator rights) must not be able to install applications that the organisation has not approved. It is not enough to tell people not to do it; the system itself should stop them. Why it matters: most malware and unwanted software arrives on a workstation because a user ran an installer. That could be a fake "update" from a phishing email, a free utility downloaded from an untrusted website, or a legitimate-looking tool bundled with something harmful. If a standard user account can complete an installation, an attacker only needs to trick one person to gain a foothold. Removing that ability from unprivileged users breaks the chain: even if the user is fooled, the installation fails. The control is deliberately scoped. It applies to human users who are unprivileged, and it targets unapproved applications. Approved applications can still be delivered to those users through an organisation-managed channel, and privileged administrators can still install software as part of their role. The point is that the general population of users cannot bring in whatever they like.

Why it matters

If unprivileged users can install unapproved applications, any successful phishing email, malicious download or bundled installer can plant malware, remote access tools or data-stealing software on a workstation. Unvetted applications also introduce unpatched vulnerabilities, licensing exposure and shadow IT that the organisation cannot see or maintain, and they undermine other controls such as application control and patching because the software estate no longer matches what is known and approved.

How to implement

  1. Endpoint or desktop engineers remove local administrator group membership from all standard user accounts, using group policy, MDM or configuration management to enforce this on every managed device and to reverse any manual additions.

  2. Endpoint engineers configure operating system and management policies so that unprivileged users cannot run installers or add software through app stores and package managers, including user-profile installers that do not prompt for elevation, and test this on a standard account before rollout.

  3. The IT service team publishes an approved-application catalogue or self-service portal through the endpoint management platform so that unprivileged users can obtain approved software without being granted installation rights.

  4. The IT service team defines and operates a software request process in which a nominated approver reviews new application requests, records the decision, and only then adds the application to the approved catalogue.

  5. Security or IT operations staff schedule a recurring review comparing installed-software inventories and local administrator group membership against the approved list and the expected privileged accounts, and remediate any exceptions found.

Keep it running

Day to day, this control lives in how endpoints are configured and how software reaches users. Standard user accounts should run without local administrator rights, and the operating system and endpoint management tooling should be configured so that installers, package managers and app stores cannot be used to add unapproved software.

Because users still need software to do their jobs, an approved-application path needs to exist alongside the restriction: a software catalogue, self-service portal or IT-delivered installation that provides approved applications without granting the user installation rights. Requests for new applications should go through a defined approval step before the application is added to that path.

Watch for drift. Accounts sometimes end up with local administrator rights after troubleshooting, new device images may ship with looser settings, and some installers can run entirely within a user profile without needing administrator rights. Periodic checks of group membership, endpoint policy and installed-software inventories help confirm the restriction is still holding.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the endpoint configuration or group policy settings that restrict software installation for standard user accounts.

    Look at

    Check that the settings apply to all managed devices and cover installers, app stores and package managers, not just one mechanism.

    Good evidence

    A documented, centrally enforced policy that blocks unprivileged users from installing software, with evidence it is applied fleet-wide.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for a report of local administrator group membership across workstations.

    Look at

    Look for everyday user accounts that appear in the local administrators group and for any explanation of why they are there.

    Good evidence

    Only designated privileged or service accounts hold local administrator rights, and any exceptions are approved and time-limited.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask to observe a test where a standard user account attempts to install an unapproved application.

    Look at

    Watch whether the installation is actually blocked, including for installers that run inside the user profile without asking for elevation.

    Good evidence

    The installation fails for the standard user and the attempt is visible in logs or endpoint tooling.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask how users obtain approved applications and how new applications are requested and approved.

    Look at

    Look for a defined request and approval step and a delivery mechanism such as a software catalogue that does not hand installation rights to the user.

    Good evidence

    Approved software is delivered through a managed channel, and additions to the approved list are backed by recorded approval decisions.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for recent installed-software inventory reports and any review of them against the approved list.

    Look at

    Check whether unapproved software appears on user devices and what was done about it.

    Good evidence

    Inventories are reviewed periodically, unapproved software is rare, and any findings are traced back to a root cause and remediated.

Mappings

Closest match in ISO/IEC 27001: A.8.18, Use of privileged utility programs, which partially overlaps with this control.

ISO 27001

ISO/IEC 27001: 2 mappings

  • A.8.18Use of privileged utility programsPartially overlaps
  • A.8.19Secure software installation proceduresPartially overlaps
Essential Eight

ASD Essential Eight: 2 mappings

  • E8-AC-ML1.2Application control is applied to user profiles and temporary foldersPartially overlaps
  • E8-AC-ML1.3Ensure only approved applications and scripts can runPartially overlaps

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