Skip to content
System hardening
ASD ISMISM-0382

ASD ISM 0382 Prevent unprivileged human users uninstalling or disabling approved applications

What it says

Unprivileged human users do not have the ability to uninstall or disable approved applications.

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

What it means

In plain English

Lock approved applications so that ordinary (non-administrator) users cannot remove them or switch them off, keeping security tooling and sanctioned software in place.

Organisations approve certain applications to run on their systems. Some of these applications exist purely to protect the system (endpoint protection, logging agents, device management clients, VPN clients, backup agents) and others are the sanctioned business tools that users are meant to work with. This control says that people who use those systems without administrative privileges should not be able to uninstall an approved application or disable it (for example by stopping its service, turning off its protection, removing it from start-up or deregistering its agent). It matters because the value of an approved application depends on it actually running. A user who can remove or switch off an endpoint protection agent, whether out of frustration with performance, a misunderstanding, or because a malicious actor has tricked or coerced them, removes a layer of defence for the whole organisation without anyone necessarily noticing. Adversaries who compromise an unprivileged account will also try to disable security tooling as one of their first steps. Restricting these actions to privileged administrators, through operating system permissions, application self-protection features and configuration policy, keeps the approved software set stable and makes tampering harder and easier to detect.

Why it matters

If unprivileged users can uninstall or disable approved applications, security agents such as endpoint protection, logging and device management can be switched off by a careless user or by malware running in a user's context, leaving devices unmonitored and unprotected. Sanctioned business applications may be removed, creating support burden, inconsistent fleets and gaps in the organisation's ability to prove that its baseline is in place. Attackers who gain a normal user account can then blind defenders and establish persistence far more easily.

How to implement

  1. The endpoint or platform team removes local administrator rights from standard user accounts on workstations and servers, so that uninstalling software or stopping services requires elevation with a separate privileged account.

  2. The security team enables tamper protection or self-protection on approved security agents (endpoint protection, EDR, logging and device management clients) through the vendor console, so that even a user with some elevated rights cannot stop, disable or uninstall the agent without an administrator-set password or console approval.

  3. The configuration management team applies policy (for example Group Policy, Intune, Jamf or an equivalent Linux tool) that blocks access to add/remove programs for standard users, restricts service control permissions on approved application services, and prevents users from disabling start-up items for those applications.

  4. The endpoint team configures compliance or remediation rules in the device management platform that detect a missing or stopped approved application and automatically reinstall or restart it, and reports the event for follow-up.

  5. The security operations team forwards uninstall, service-stop and agent-tamper events to the SIEM and creates an alert for any such event originating from a non-administrator account, with a documented triage step to confirm whether the control failed or an attack is under way.

Keep it running

In practice this control is enforced through a combination of standard user accounts (no local administrator rights), operating system controls that require elevation to uninstall software or stop services, and the tamper-protection or self-protection features built into many security agents. Configuration management tools (for example Intune, Group Policy, Jamf or a Linux configuration manager) push these settings and can re-enable or reinstall an agent that goes missing.

Day to day, the help desk will see requests from users who want to remove an application they consider unnecessary or who believe an agent is slowing their device; these should be routed to an administrator who can assess and act rather than granting the user rights to do it themselves. Security operations should watch for agent heartbeat loss, service stop events and uninstall events from non-administrator accounts, since these indicate either a gap in the control or attempted tampering. Any change to the list of approved applications, or to which accounts hold privileged rights, should flow through the organisation's normal change and access management processes so the protection stays consistent across the fleet.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the list of approved applications and the policy or standard that states unprivileged users may not uninstall or disable them.

    Look at

    Look at whether the approved application list is current, whether it identifies security agents and business applications, and whether the policy names the technical measures used to enforce the restriction.

    Good evidence

    Good looks like a maintained approved application list, owned by a named team, with a policy that explicitly reserves uninstall and disable actions to privileged administrators.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for evidence that standard user accounts do not hold local administrator rights on workstations and servers.

    Look at

    Look at a recent export of local administrator group membership across a sample of devices and the process for granting and reviewing privileged access.

    Good evidence

    Good looks like local administrator groups containing only approved administrative accounts, with no everyday user accounts, and a documented review cycle.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the configuration of tamper protection or self-protection on the approved security agents.

    Look at

    Look at screenshots or exports from the vendor console showing tamper protection enabled fleet-wide, and any devices where it is off with a justification.

    Good evidence

    Good looks like tamper protection enforced on all managed devices with a very small, documented set of exceptions and a recent compliance figure close to 100 per cent.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask to observe or see the results of a test where a standard user attempts to uninstall or stop an approved application.

    Look at

    Look at whether the attempt is blocked by an elevation prompt, an access denied message or the agent's self-protection, and whether the attempt was logged.

    Good evidence

    Good looks like a clear denial for the standard user, with the attempt recorded in the device log or the security console.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for monitoring and remediation records covering agents that stopped reporting or were uninstalled.

    Look at

    Look at SIEM alerts or device management reports for uninstall, service-stop and tamper events, and the tickets that show what was done about them.

    Good evidence

    Good looks like alerts that fire on such events, timely investigation of any that came from unprivileged accounts, and automatic or ticketed reinstallation of the affected application.

Mappings

Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.

ISO 27001

ISO/IEC 27001: 3 mappings

  • A.5.15Access control policies and proceduresPartially meets
  • A.8.3Restrict access to information and assetsPartially meets
  • A.8.19Secure software installation proceduresPartially meets
Essential Eight

ASD Essential Eight: 3 mappings

  • E8-AC-ML1.2Application control is applied to user profiles and temporary foldersPartially overlaps
  • E8-AH-ML1.4Web browser security settings locked down to usersPartially overlaps
  • E8-AH-ML2.7Office productivity suite settings are immutable by usersPartially overlaps

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