ASD ISM 1491 Block unprivileged users from running script execution engines
What it says
Unprivileged human users are prevented from running script execution engines, including: - Windows Script Host (cscript.exe and wscript.exe) - PowerShell (powershell.exe, powershell_ise.exe and pwsh.exe) - Command Prompt (cmd.exe) - Windows Management Instrumentation (wmic.exe) - Microsoft Hypertext Markup Language (HTML) Application Host (mshta.exe).
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishStandard (non-admin) staff accounts must be technically blocked from launching Windows Script Host, PowerShell, Command Prompt, WMIC and mshta.exe.
Windows ships with several built-in tools that run scripts and commands: Windows Script Host (cscript.exe and wscript.exe), PowerShell (powershell.exe, powershell_ise.exe and pwsh.exe), Command Prompt (cmd.exe), the Windows Management Instrumentation command-line tool (wmic.exe) and the HTML Application Host (mshta.exe). Ordinary staff rarely need any of them to do their jobs, but attackers rely on them constantly. This control requires that unprivileged human users (everyday accounts that are not administrators) are prevented from running these five script execution engines. The block must apply to all of the listed executables, not just one or two of them. Why it matters: most phishing and malicious-document attacks do not deliver a traditional virus file. Instead they trick the user's machine into calling one of these trusted, already-installed tools to download and run the attacker's code, a technique often described as "living off the land". Because the tools are signed Microsoft binaries, antivirus tends to leave them alone. If a standard user account cannot launch them at all, a large class of malware chains simply fails at the first step, even when the user has clicked the link or opened the attachment.
Free. Save your status, tasks and notes.
Why it matters
If unprivileged users can run these script engines, a single opened attachment or malicious link can lead to PowerShell, WScript, mshta or WMIC being used to fetch and execute malware, harvest credentials, establish persistence and spread across the network, all under a normal user account and without tripping traditional file-based antivirus. Partial coverage (for example blocking PowerShell but leaving cmd.exe, wmic.exe or mshta.exe available) still leaves a working path for attackers.
How to implement
The desktop or endpoint engineering team should build an application control rule set (for example AppLocker or Windows Defender Application Control) that explicitly denies cscript.exe, wscript.exe, powershell.exe, powershell_ise.exe, pwsh.exe, cmd.exe, wmic.exe and mshta.exe, and apply it to all standard user accounts while exempting only defined administrative groups.
The identity or Active Directory team should define which security groups count as privileged for this purpose and scope the deny rules by group membership, so that the block follows the account rather than the device and cannot be dodged by logging on to another workstation.
The endpoint team should deploy the policy in audit-only mode first, collect the block events for two to four weeks, and work with application owners to move any legitimate dependency (login scripts, software installers, monitoring agents) to run under a service or administrative context instead of the user's own account.
The endpoint team should build the rules using publisher or hash conditions rather than path conditions, so that the block also covers alternate copies and locations of the engines (for example the SysWOW64 folder and any per-user PowerShell 7 installs) and renaming or copying the executable does not bypass it.
The security operations team should forward application control block events to the central logging platform and set up a recurring review so that attempts by standard users to launch these engines are investigated and the policy is re-checked after each operating system feature update or new device image.
Keep it running
Day to day, this control is a standing configuration rather than a task. The block is typically enforced by an application control policy (such as AppLocker or Windows Defender Application Control) or by Group Policy restrictions scoped to non-administrative accounts, and it must cover every executable named in the statement: cscript.exe, wscript.exe, powershell.exe, powershell_ise.exe, pwsh.exe, cmd.exe, wmic.exe and mshta.exe.
Expect friction. Some line-of-business software, login scripts and help-desk tools call these engines behind the scenes, so the desktop team should keep a short register of legitimate exceptions and the way each has been handled (for example running the task under a service or administrative context rather than the user's account). Any exception should still leave the human user unable to launch the engine directly.
Watch for drift when new device images, software or operating system changes (for example a PowerShell 7 install adding pwsh.exe) or new organisational units are introduced. Block events from the enforcement tool should be reviewed periodically, both to catch attempted misuse and to spot business processes that are silently failing. Confirm the control on a sample of standard user sessions after any change to the policy.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the current application control or Group Policy configuration that blocks script execution engines, including the list of executables it covers.
Look at
Check that all eight executables named in the control (cscript.exe, wscript.exe, powershell.exe, powershell_ise.exe, pwsh.exe, cmd.exe, wmic.exe, mshta.exe) appear as denied for standard users.
Good evidence
Every listed engine is explicitly denied for unprivileged users and the policy is enforced rather than left in audit-only mode.
- Check 2 of 5What an auditor asks for
Ask for
Ask which accounts or groups the policy applies to and which groups are exempt.
Look at
Compare the exempt groups against the organisation's definition of privileged users and check that ordinary staff accounts are not members of those groups.
Good evidence
The deny rules apply to all standard user accounts, and exemptions are limited to named administrative groups with a documented reason.
- Check 3 of 5What an auditor asks for
Ask for
Ask to observe or receive a live test from a standard user session attempting to launch each engine.
Look at
Watch whether each executable is actually blocked, including when launched from a Run dialog, from File Explorer or from a copied file in a user-writable folder.
Good evidence
All attempts fail with a block message for the standard user, while the same attempts succeed for an authorised administrative account.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the register of exceptions and the change records for the policy over the past twelve months.
Look at
Look at whether exceptions allow a human user to run an engine directly, or whether they redirect the task to a service or administrative context, and whether changes were approved.
Good evidence
Exceptions are few, justified, time-bound where possible, and none of them give an unprivileged human user direct access to a listed engine.
- Check 5 of 5What an auditor asks for
Ask for
Ask for recent block-event logs or reports from the enforcement tool.
Look at
Check that events exist for the listed engines, are being collected centrally and show evidence of review or investigation.
Good evidence
Block events are logged, reviewed on a regular cycle, and any pattern of attempts is followed up rather than ignored.
Mappings
Closest match in ASD Essential Eight: E8-AC-ML1.3, Ensure only approved applications and scripts can run, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially overlaps A.8.18.
Annex A 8.18 requires restricting and tightly controlling utility programs that can override system and application controls, addressing misuse of powerful tools on operational systems. ISM-1491 relates by preventing unprivileged users from running script execution engines (e.g. PowerShell, cmd.exe, wmic.exe) that can function as utilities to bypass intended controls and install or execute unauthorised code. However, Annex A 8.18 focuses on tight control of override-capable utilities across all users and contexts, while ISM-1491 is specifically scoped to unprivileged users and a defined set of scripting/execution engines.
ASD Essential Eight: 4 mappings
This control partially meets E8-AC-ML1.3.
ISM-1491 requires organisations to block unprivileged users from running specific script execution engines such as PowerShell, cmd.exe, wmic.exe, mshta.exe and Windows Script Host. E8-AC-ML1.3 requires application control that restricts executables and scripts (including compiled HTML and HTML applications) to an approved set, which is a broader mechanism that can include blocking these engines. ISM-1491 is effectively a specific, named set of deny controls that can be implemented as part of the broader allowlisting requirement in E8-AC-ML1.3.
This control partially overlaps E8-AC-ML1.1.
ISM-1491 requires organisations to technically prevent unprivileged users from launching specific script execution engines (e.g. PowerShell, cmd.exe, wmic.exe, mshta.exe and Windows Script Host). E8-AC-ML1.1 requires application control on workstations, which can be implemented to block those same executables for standard users. E8-AC-ML1.1 is broader (covers general application allowlisting/denylisting) while ISM-1491 is a specific prohibition focused on script execution engines and unprivileged users.
This control partially overlaps E8-AH-ML3.3.
ISM-1491 requires organisations to prevent unprivileged users from running PowerShell (and other script execution engines) at all. E8-AH-ML3.3 requires PowerShell to use Constrained Language Mode, which limits what PowerShell can do rather than blocking it outright. The controls overlap in addressing PowerShell abuse, but ISM-1491 is stricter (deny execution) while E8-AH-ML3.3 is a hardening constraint that may still permit some PowerShell use.
This control supports E8-AC-ML1.2.
ISM-1491 requires organisations to prevent standard users from launching key script execution engines that are commonly abused for execution. E8-AC-ML1.2 applies application control to user profiles and temporary folders, reducing the likelihood that users can run scripts or dropped binaries from common writeable paths even if an engine is available. E8-AC-ML1.2 does not itself mandate blocking the listed engines, but it strengthens the effectiveness of ISM-1491 by constraining common execution locations.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.