PowerShell ExecutionPolicy Explained: Important Safety Feature

Do you want to learn PowerShell ExecutionPolicy and how to use it? This guide teaches you all you need to know about this important PowerShell safety feature.

To make this guide fun to read and easy to understand, I divided it into sections. The first section introduces you to the PowerShell ExecutionPolicy.

Then, in section two, you’ll learn how this PowerShell safety feature works, followed by its types and scopes in section three. In section four, you’ll learn the pros and cons of PowerShell ExecutionPolicies.

I then crown the guide with how to view and set ExecutionPolicies with multiple examples. Finally, I have an FAQ section where I answer questions most people ask about this PowerShell safety feature.

Overview

If you’ve been using Windows PowerShell, you may have downloaded scripts from the internet. When you try to run a PowerShell script you download from the internet, you’ll receive a warning similar to the screenshot below.

PowerShell’s execution policy displays this warning message. Displaying warning messages like this is one of the ways PowerShell keeps you safe from running malicious scripts.

PowerShell ExecutionPolicy is a safety feature PowerShell uses to control how it loads configuration files and runs scripts. As I mentioned earlier, this feature helps you prevent running malicious scripts.

You can define 7 execution policies in PowerShell. In addition to the types of execution policies, PowerShell has 5 scopes of execution policies.

While the execution policies define how PowerShell manages how scripts are executed, the scope defines how the policy is applied (more on these later).

Types And Scopes Of PowerShell ExecutionPolicy

In the last section, I mentioned that PowerShell has 7 different types of execution policies you can set. Additionally, I also hinted that PowerShell offers 5 ExecutionPolicy scopes.

Furthermore, in the first sub-section of this section, I will explain the 7 execution policies. Then, in the second sub-section, you’ll learn the 5 scopes of execution policies.

Types Of PowerShell ExecutionPolicy

There are 7 execution policies you can set in PowerShell. Here they are…

1. AllSigned ExecutionPolicy. If you set this PowerShell execution policy, PowerShell can run all scripts.
   
   However, PowerShell requires a trusted publisher to sign all scripts and configuration files. This includes scripts that you write on your local computer.
   
   In addition to the above features, the AllSigned ExecutionPolicy will also prompt a warning informing you when you’re about to run a script from a publisher that you have not yet classified as trusted or untrusted.
   
   Even though this execution policy appears secure, you still risk running signed but malicious scripts. In essence, a script may be signed but still dangerous!
2. Bypass ExecutionPolicy. Unlike the AllSigned policy, this execution policy is not restrictive.
   
   When you set the Bypass execution policy, PowerShell will allow all scripts to run without warnings or prompts.
3. Default ExecutionPolicy. If you set the Default execution policy, PowerShell assigns the default execution policies for Windows clients and Server.
   
   For a Windows client (Windows 10, Windows 11), the default execution policy is Restricted. On the other hand, for a Windows Server, the default is RemoteSigned.
   
   More on these two execution policies shorltly.
4. RemoteSigned ExecutionPolicy. This is the default execution policy for Windows Servers.
   
   When you set the RemoteSigned execution policy, PowerShell allows scripts to run with some restrictions. Specifically, with this execution policy, PowerShell requires that all scripts you download from the internet must be digitally signed by a trusted publisher.
   
   For the RemoteSigned execution policy, “scripts you download from the internet” include scripts you receive via email or instant messages.
   
   The major difference between the RemoteSigned and the AllSigned execution policy is that the RemoteSigned policy does NOT require you to digitally sign scripts you write on your local computer.
   
   So, the AllSigned execution policy is more restrictive than the RemoteSigned policy. To make it easy to differentiate, remember All and Remote.
   
   “All”Signed means that everything is signed, while “Remote”Signed means that only scripts you receive from remote sources need to be signed.
5. Restricted ExecutionPolicy. This is the default PowerShell execution policy PowerShell sets on Windows clients like Windows 10 and Windows 11.
   
   This policy is very restrictive – it permits running individual PowerShell commands but does not allow you to run scripts.
   
   So, if you want to only run PowerShell commands on your computer, set the execution policy to Restricted. With this policy, you cannot run any script with the following file extensions – .ps1 (PowerShell scripts), .psm1 (module script files), or .ps1xml (PowerShell configuration files).
6. Undefined ExecutionPolicy. When you set the Undefined PowerShell execution policy, PowerShell does not set any execution policy in the current scope (more on scopes later).
   
   So, with the Undefined execution policy, PowerShell defaults to the Restricted execution policy for Windows clients and RemoteSigned execution policy for Windows Servers.
7. Unrestricted ExecutionPolicy. PowerShell now supports non-Windows computers.
   
   When you run PowerShell on non-Windows computers, the default PowerShell ExecutionPolicy is Unrestricted. It is important that on non-Windows computers, you CAN NOT change this execution policy.
   
   In terms of its restrictions, the Unrestricted execution policy allows you to run unsigned scripts. However, when you set the Unrestricted execution policy, PowerShell warns you before it runs scripts and configuration files that are not from the local intranet zone.
   
   Obviously, with this execution policy, you run the risk of running malicious scripts.

Scopes Of PowerShell ExecutionPolicy

PowerShell ExecutionPolicy has 5 scopes.

1. MachinePolicy scope. This scope is set via Group Policy, and it applies to all users logged in to a computer.
2. UserPolicy scope. Similar to the MachinePolicy scope, the UserPolicy scope is set by the domain administrator via Group Policy.
   
   However, unlike MachinePolicythe scope that applies to all signed-in users of a computer, the UserPolicy scope applies only to the current user of the computer.
3. Process scope. This scope only affects the current PowerShell session.
   
   PowerShell saves this scope in the env:PSExecutionPolicyPreference Variable.
4. CurrentUser scope. The CurrentUser scope only affects the currently signed-in user.
   
   PowerShell stores this in the HKEY_CURRENT_USER registry subkey.
5. LocalMachine scope. PowerShell saves this execution policy in the HKEY_LOCAL_MACHINE registry subkey.
   
   However, unlike the CurrentUser scope, which applies only to the current user, the LocalMachine scope applies to all users on the current computer.

How PowerShell ExecutionPolicy Works

The PowerShell ExecutionPolicy that applies to a computer or a user is controlled by the policy and the scope. When you run a PowerShell script, PowerShell uses APIs in the Windows Desktop Shell (explorer.exe) to determine the Zone of a script file.

Talking about deciding the zone of a script file, when you download a file from the internet, the browser adds an alternate data stream to the file. So, before PowerShell runs a script, it checks for this “alternate data stream.”

If a script file contains the information, PowerShell marks the file as downloaded from the internet. Then, it checks for the effective execution policy and determines how to execute the file.

If the effective PowerShell execution policy is REMOTESIGNED, PowerShell will not run the script if it is not digitally signed. This applies to scripts downloaded from the internet as well as scripts you received via email and instant messages.

So, how does PowerShell determine the effective policy for the current user?PowerShell achieves this by evaluating the execution policies in the following precedence order:

Group Policy: MachinePolicy
Group Policy: UserPolicy
Execution Policy: Process (or pwsh.exe -ExecutionPolicy)
Execution Policy: CurrentUser
Execution Policy: LocalMachine

Effectively, the MachinePolicy scope execution policies applied via Group Policy take the highest precedence. This means that, if this policy exists, that will be the active ExecutionPolicy.

This is followed by any UserPolicy scope execution policy the administrator applies via Group Policy.

Features Of PowerShell ExecutionPolicy

So far, in this guide, you have read an overview of the PowerShell ExecutionPolicy. You have also read the types and scope of this essential PowerShell security feature as well as how the feature works.

In this section, I will further explain the PowerShell ExecutionPolicy by highlighting its core features.

PowerShell Saves The Process Scope ExecutionPolicy In An Environment Variables But Saves Others In Windows Registry

When you set the execution policy to the Process scope, PowerShell saves the settings in the $env:PSExecutionPolicyPreference environment variable. On the contrary, PowerShell saves any other ExecutionPolicy in Windows registry.

As I mentioned in the last section, PowerShell saves the MachinePolicy and UserPolicy scopes (deployed via Group Policy) in the Windows Registry.

Specifically, When a domain administrator applies MachinePolicy, it saves the policy in the following registry path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

On the other hand, when the administrator sets UserPolicy, Windows saves the policy in the following registry path:

HKEY_CURRENT_USER\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

In the next sub-section, you’ll learn the full paths where the administrator sets this policies on the Group Policy editor.

You Can Set PowerShell Execution Policy Via The Computer And/Or User Configuration In Group Policy Editor

In the last sub-section, I mentioned that when a Windows administrator sets PowerShell ExecutionPolicy via Group Policy, Windows saves the policies in the Windows Registry.

If you’re a Windows SysAdmin that has worked with Group Policy Objects (GPOs), you will be aware that the Group Policy Editor has two nodes – Computer Configuretion and User Configuration.

If you wish to set PowerShell MachinePolicy, use the path below

Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell

Once you navigate to this node, you can set any of the policies on the details pane of the Group Policy Editor.

Similarly, if you wish to set UserPolicy via Group Policy, use the path below:

User Configuration\Administrative Templates\Windows Components\Windows PowerShell

The MachinePolicy Scope Applied Via Group Policy Takes Precedence Over All Other Execution Policies

In the last section I mentioned that Windows evaluates the “Group Policy: MachinePolicy” last. So, if an administrator applied a MachinePolicy via Group Policy, it takes precedence over all other ExecutionPolicy scopes.

This is a very important feature with mentioning in this features section.

When You Close The Current Session, PowerShell Clears The env:PSExecutionPolicyPreference Variable

In the first sub-section of this section, I mentioned that PowerShell saves the “Process” ExecutionPolicy scope in the $env:PSExecutionPolicyPreference environment variable.

You have also learned that when you set the “Process” ExecutionPolicy scope, PowerShell applies the policy to the currently signed in user. Effectively, the “Process” ExecutionPolicy scope applies to the current user and PowerShell saves the settings in the $env:PSExecutionPolicyPreference environment variable.

One important feature of this setting worth noting is that PowerShell clears the information saved in the $env:PSExecutionPolicyPreference environment variable when the user closes the PowerShell console.

So, if you want to set a PowerShell ExecutionPolicy to use only in the current section, use the “Process” scope. More on this in the examples section of this guide.

Pros And Cons Of PowerShell ExecutionPolicy

No matter how great a feature is, it must have some limitations, and this PowerShell feature is no exception. This section discusses the pros (benefits) and cons (limitations/disadvantages) of PowerShell ExecutionPolicy.

Pros Of Using PowerShell ExecutionPolicy

1. PowerShell’s execution policy feature safeguards your PC from running malicious scripts. This PowerShell’s safety features keep your PC safe.
   
   Without this feature, you may download a dangerous script from the internet and run it without knowing that it puts your computer at risk.
2. Domain admins can apply a company-wide policy to all computers via Group Policy. Network administrators can safeguard all PCs on the network by applying a strict PowerShell execution policy.
   
   Without the Group Policy, administrators may run malicious codes that may cause major problems for the business.
3. You can use the Bypass execution policy to allow you to run scripts in the current section. If there is no Group Policy MachinePolicy the network administrator applied, you can set a temporal Bypass policy to allow you to run scripts you deem safe.
4. Non-administrators cannot change PowerShell’s execution policy. For Windows admins, this is a big plus as it gives them control over who can modify the execution policy.
5. Nobody can override PowerShell ExecutionPolicy set by Group Policy. Users cannot bypass the execution policy if an administrator sets a PowerShell ExecutionPolicy via Group Policy.
   
   If a local admin user tries to set a less restrictive policy, they’ll receive an error message.

Cons (Limitations/Disadvantages) Of Using PowerShell ExecutionPolicy

1. You need administrator privileges to change PowerShell’s execution policy. Before you can modify the current PowerShell’s execution policy, you must run PowerShell as administrator.
   
   Depending on who you ask, this may be an advantage. For example, for the network administrator, this is an advantage.
   
   However, for the end-user, this is a nightmare as she will not be able to run any PowerShell script unless it meets the execution policy set by the network administrator.
2. PowerShell ExecutionPolicy may stop users from running useful scripts. In point 1 above, I mentioned that a user needs administrative privilege to change the execution policy.
   
   Unfortunately, if a user does not have the right to modify the execution policy, this may stop the user from running useful PowerShell scripts.
3. May slow down the ability to fix problems quickly. Following on from points 1 and 2 above, if a user wants to fix a problem by running a PowerShell script but cannot, they may need to wait for the support team to help them.
   
   This will waste valuable business time and even increase the workload on the IT support team.

How To View And Set PowerShell ExecutionPolicy With Examples

Finally, we got to the fun bit! This section shows hands-on applications of this PowerShell safety feature.

How To Use The Get-ExecutionPolicy Command To Display Effective Execution Policy And List All Execution Policies

If you want to see the current ExecutionPolicy, run the Get-ExecutionPolicy command.

Get-ExecutionPolicy

As shown by my screenshot below, my current ExecutionPolicy is Unrestricted.

However, if I want to list all ExecutionPolicy scopes, use the command below:

Get-ExecutionPolicy -List

Here is the result. The result of the last command explains why my effective ExecutionPolicy is Unrestricted.

If you read this article from the beginning, you will remember that the MachinePolicy (defined via Group Policy) takes precedence over all other policies.

So, since no other policy scope is defined (according to the result of the “Get-ExecutionPolicy -List” command), the only defined scope (LocalMachine) becomes the effective PowerShell ExecutionPolicy.

How To Set PowerShell ExecutionPolicy For The Current Session

If there is no MachinePolicy (defined via Group Policy), you can set an ExecutionPolicy for the current user. For example, the command below overrides my existing ExecutionPolicy and sets a new “Bypass” ExecutionPolicy.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force

Now, if I run the “Get-ExecutionPolicy -List” command below, it will return a different result from what it displayed in the first example above.

Get-ExecutionPolicy -List

As expected, the last command returns the result shown in the screenshot below…

Can you guess my current effective PowerShell ExecutionPolicy? To find out, I’ll run the command below:

Get-ExecutionPolicy

As expected, my effective ExecutionPolicy is Bypass.

How To Set PowerShell ExecutionPolicy From Group Policy

Earlier in this article, I mentioned that you could set PowerShell MachinePolicy via this Group Policy path.

Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell

Similarly, I mentioned that you could set the UserPolicy via this Group Policy path.

User Configuration\Administrative Templates\Windows Components\Windows PowerShell

In this example, I want to set the PowerShell MachinePolicy scope. So, I’ll edit this path.

Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell

Now, I’ll edit the Turn on Script Execution policy. To edit the policy, double-click it.

Then, select the “Enabled” option when the policy opens for editing.

Next, in the Options section, click the “Execution Policy” drop-down and select one of the options. I will select the “All signed scripts” option in this example.

This option sets the MachinePolicy to the AllSigned ExecutionPolicy.

Finally, click OK to close the Turn on Script Execution policy window. Group Policy Editor now shows the state of Turn on Script Execution policy as “Enabled”.

To force the Group Policy to apply to my computer, I’ll run the command below in PowerShell…

gpupdate /force

Then, I will close and reopen the PowerShell console by running it as administrator. Next, to list all ExecutionPolicy scopes, I’ll run the command below…

Get-ExecutionPolicy -List

Bingo! My MachinePolicy is now set to AllSigned.

This is a result of me setting the Turn on Script Execution policy to “All signed scripts” in Group Policy.

If you’ve been following this guide, it wouldn’t surprise you to see that my current effective ExecutionPolicy is AllSigned.

Why?

Well, this is the MachinePolicy scope set via Group Policy, and since this takes precedence, my effective ExecutionPolicy will be AllSigned.

To confirm this theory, I’ll now run the command below.

Get-ExecutionPolicy

And here is the result…

Finally, let me show you what happens if I try to override this MachinePolicy set by Group Policy. I will run the command below to attempt to bypass the Group Policy setting…

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force

As expected, the last command throws the error message…

Set-ExecutionPolicy : Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more
specific scope. Due to the override, your shell will retain its current effective execution policy of AllSigned.

Effectively, my command failed to override the PowerShell ExecutionPolicy set by Group Policy!

Frequently Asked Questions

My Final Thoughts

PowerShell ExecutionPolicy is an important PowerShell security and safety feature every serious PowerShell enthusiast must know.

This guide introduced you to this all-important PowerShell safety feature. Then, you also learned the types and scopes of PowerShell ExecutionPolicy.

Not only that, but you also learned how this PowerShell feature works, followed by its features plus pros and cons.

I hope I was able to teach you all there is to know about the PowerShell ExecutionPolicy. If I did, kindly spare us 2 minutes to share your thoughts at [discourse_topic_url].

You may also ask a question about this topic by replying to this article’s topic at [discourse_topic_url].

Finally, to read more PowerShell guides, visit our PowerShell Explained page. You may also find our Windows PowerShell How-To Guides page helpful.

References And Further Reading

1. about Execution Policies – PowerShell | Microsoft Docs
2. Set-ExecutionPolicy (Microsoft.PowerShell.Security) – PowerShell | Microsoft Docs
3. Set-ExecutionPolicy for Managing PowerShell Execution Policies (adamtheautomator.com)
4. [discourse_topic_url]