PowerShell execution policy is not a security boundary

PowerShell execution policy is a safety feature, not a security boundary. Microsoft says so directly: users can bypass it by typing script contents at the command line. Use it to prevent accidents, and rely on application control, logging and least privilege for real enforcement.

What the policy does

The policy controls the conditions under which PowerShell loads configuration files and runs scripts. On Windows you can set it for the local computer, the current user or a single session, and Group Policy can set it too. Enforcement happens only on Windows. On other platforms the policy reads as Unrestricted and cannot be changed.

The documented policies include AllSigned, RemoteSigned, Restricted, Unrestricted, Bypass, Default and Undefined. RemoteSigned is the default for Windows computers per Microsoft's page, and it requires a trusted publisher signature only for scripts downloaded from the internet, including through email and chat programs.

If no scope defines a policy, the effective policy is Restricted on Windows clients and RemoteSigned on Windows Server.

Why it is not a boundary

Microsoft's wording is that the policy is defense in depth, and that it helps users set basic rules and avoid violating them unintentionally. A few reasons it cannot stop a determined user:

• Someone can paste the script text into a prompt, and no file is ever loaded.
• A session scope setting overrides the machine and user scopes. It does not override Group Policy.
• Some download methods do not mark files as coming from the internet. The documentation lists curl.exe, Invoke-RestMethod and Invoke-WebRequest as examples, so a downloaded file may carry no internet mark and run under RemoteSigned.
• Unblock-File exists for a reason, and anyone can run it on their own files.

None of this makes the policy useless. It stops a double click on a random downloaded script from running by accident.

Scope and precedence

When Group Policy does not define the policy, precedence runs from Process, then CurrentUser, then LocalMachine. You can see the lot with this command:

Get-ExecutionPolicy -List

A command that changes one scope can succeed and still not change the effective policy, because a higher scope overrides it. That surprises people during troubleshooting. Always read the full list, not just the effective value.

Group Policy settings, MachinePolicy and UserPolicy, sit above all of these. The Turn on Script Execution setting overrides the policies set in PowerShell in every scope, so if you want a policy users cannot change from a prompt, set it there.

What to use for real control

Treat execution policy as one layer and add the layers that actually block or detect:

• Application control that restricts what can run at all, with an audit phase first.
• Script block logging, shipped off the machine, so you see what ran.
• Standard user accounts for daily development, so scripts do not inherit admin rights.
• Code signing for the scripts your team distributes, so AllSigned is workable where you need it.

For developer machines, a pragmatic baseline is RemoteSigned set by Group Policy, plus logging. AllSigned fits tightly controlled automation hosts where every script is signed by your own pipeline.

A common mistake

Teams hit an error, run Set-ExecutionPolicy Bypass for the machine, and never revert it. If you must loosen the policy for a task, use the Process scope. It lives only in memory and disappears with the session.

pwsh.exe -ExecutionPolicy AllSigned

That form also works in reverse: start a stricter session for a risky task.

Quick check

Sources

• about_Execution_Policies, Microsoft Learn

Last reviewed: 19 October 2026.