PowerShell execution policy controls the conditions for loading configuration files and running script files on Windows. It can help prevent accidental script execution, but it is not a security boundary: it does not prove that permitted code is safe, and it can be bypassed. Microsoft describes it as one layer of defense in depth.
What execution policy controls
Execution policy determines whether PowerShell runs scripts and loads certain configuration files, and what conditions apply. It is primarily an accident-prevention feature—for example, it can make an unsigned script downloaded from the internet harder to run unintentionally. It does not inspect a script to establish that its actions are harmless.
Microsoft’s about_Execution_Policies puts the distinction plainly: “The execution policy isn’t a security boundary, it’s defense in depth.” That means policy can contribute to safer operation, but it should not be treated as a substitute for controls that restrict what code or users can do.
How the policy choices differ
The policy names describe execution conditions, not levels of trustworthiness. A signature requirement is a check on signing and publisher trust; it is not a guarantee that the signed code is benign.
#1 Best Overall
| Policy | What it permits or requires | Important qualification |
|---|---|---|
| Restricted | Allows individual commands, but blocks script files, module script files, formatting files, configuration files, and profiles. | It limits file-based script execution; it does not make commands themselves harmless. |
| RemoteSigned | Requires scripts downloaded from the internet to be signed by a trusted publisher. Scripts created locally do not need a signature. | It relies on Windows marking a file as coming from the Internet Zone. Some download methods may not add that mark. |
| AllSigned | Requires scripts and configuration files—including locally authored files—to be signed by a trusted publisher. | A signed script can still be malicious. |
| Unrestricted | Allows unsigned scripts to run. | PowerShell warns before running scripts and configuration files that are not from the local intranet zone. |
| Bypass | Blocks nothing and shows no warnings or prompts. | Microsoft describes it for configurations where an embedding application has its own security model; it removes this policy’s execution friction. |
| Undefined | No policy is set at that scope. | If all scopes are undefined, the effective default is Restricted on Windows clients and RemoteSigned on Windows Server. |
Microsoft documents the policy behaviors and defaults in about_Execution_Policies. The default is Restricted on Windows client computers and RemoteSigned on Windows Server; the default is not the same as a value explicitly configured at a scope.
Why execution policy does not guarantee safety
It can be bypassed
One example in Microsoft’s documentation is entering script contents directly at the command line instead of running a script file. That avoids the file-running condition execution policy is meant to control. Policy is therefore not a boundary that reliably prevents a determined user or other code from running instructions.
Rank #2
- Book - powershell for sysadmins: workflow automation made easy
- Language: english
- Binding: paperback
A signature does not certify benign behavior
AllSigned can require a trusted-publisher signature, but Microsoft warns that a signed script can still be malicious. A signature identifies that code was signed by a publisher whose certificate is trusted; it does not establish that the script’s actions are safe for your system.
RemoteSigned depends on file marking
RemoteSigned makes the Internet Zone mark important. If a download method does not mark a file as originating from the Internet, PowerShell may treat it like a local script and not require a signature. The policy name alone therefore does not mean every file that traveled over a network will receive the same treatment.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →How to check which policy is actually in effect
Policy is evaluated by scope. Group Policy settings—MachinePolicy and UserPolicy—take priority over locally set policies. If Group Policy does not define a policy, Process takes precedence over CurrentUser, which takes precedence over LocalMachine. Use both commands below to see the configured scopes and the result that currently applies.
- List policies by scope: run
Get-ExecutionPolicy -List. Check MachinePolicy and UserPolicy first; they are controlled by Group Policy. - Check the effective policy: run
Get-ExecutionPolicywithout parameters. This reports the policy that governs the current session.
A Set-ExecutionPolicy command can succeed without changing the effective policy if a higher-precedence scope controls it. Microsoft’s Set-ExecutionPolicy documentation also notes that a session-level setting can take precedence over registry settings, but not over Group Policy.
Rank #4
What temporary settings change—and what they do not
A Process-scope setting applies only to that PowerShell process and its child processes; it is not stored in the registry. Starting a session with powershell.exe -ExecutionPolicy ... sets the policy for that new session, subject to Group Policy precedence. It does not override a policy imposed by Group Policy.
Windows PowerShell launched as powershell.exe and PowerShell launched as pwsh.exe are managed separately, according to Microsoft’s Set-ExecutionPolicy documentation. Check the host you actually use rather than assuming a change in one applies to the other.
Execution policy is Windows-specific
Microsoft says execution policy does not apply on non-Windows platforms. In PowerShell 6 and later on non-Windows, the default is Unrestricted and changing execution policy is unsupported. These platform details are documented in Set-ExecutionPolicy and about_Scripts; do not read a non-Windows policy value as a Windows enforcement control.
What to use alongside execution policy
Microsoft lists other PowerShell security features that can form part of a broader defense-in-depth approach, including module and script-block logging, Antimalware Scan Interface (AMSI) support, constrained language mode, and application control. Which measures are suitable depends on the system and administrative environment; execution policy alone does not provide those controls. See Microsoft’s PowerShell security features.
If a script is blocked
Do not unblock or run an unfamiliar script just to get past an execution-policy message. First inspect its contents and verify that it is safe and comes from a source you trust. Microsoft’s Set-ExecutionPolicy documentation advises reading a script and verifying it is safe before using Unblock-File. Unblocking changes the file’s blocked status; it does not change the execution policy itself.
If a policy change appears not to work, run Get-ExecutionPolicy -List and then Get-ExecutionPolicy. A higher-priority Group Policy setting may explain why a local change did not affect the active policy.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
