How to Set PowerShell Execution Policy (Step-by-Step Guide in 2026)

PowerShell won’t run your script. You see an error message about execution policies. You’re stuck.

This happens because Windows blocks PowerShell scripts by default. The execution policy acts as a safety feature that controls which scripts can run on your system.

Here’s what you need to know: the execution policy isn’t real security. It’s a guardrail. Anyone with admin rights can change it. But it stops accidental script execution and helps prevent basic mistakes.

This guide shows you exactly how to set execution policy in PowerShell, when to change it, and how to do it safely.

What Is PowerShell Execution Policy?

Execution policy determines whether PowerShell allows scripts to run. Think of it as a permission system for automation.

When you try to run a .ps1 script file, PowerShell checks the current execution policy. If the policy blocks unsigned scripts and your script isn’t signed, you get an error.

Important: This isn’t a security boundary. Users can bypass it easily. Microsoft designed it to prevent accidental script execution, not to stop determined attackers.

The Five Main Execution Policies

PowerShell offers several execution policy levels:

Restricted: No scripts run. Only individual commands work. This is the default on Windows client machines.

AllSigned: Only scripts signed by a trusted publisher can run. PowerShell asks for confirmation before running scripts from new publishers.

RemoteSigned: Local scripts run without signatures. Downloaded scripts need a signature from a trusted publisher. This is the most common setting for developers.

Unrestricted: All scripts run. PowerShell warns you about downloaded scripts but doesn’t block them.

Bypass: Nothing gets blocked. No warnings appear. Use this for automation scenarios where you trust all scripts completely.

There’s also Undefined, which means no policy is set at that scope level.

Why PowerShell Blocks Scripts by Default

Microsoft chose Restricted as the default for good reasons.

Most users never need to run PowerShell scripts. The default setting prevents malicious scripts from running if someone accidentally double-clicks a .ps1 file or opens an email attachment.

But developers, system administrators, and power users need to run scripts regularly. That’s when you need to change the execution policy.

How to Check Your Current Execution Policy

Before changing anything, see what’s currently set.

Open PowerShell and run:

Get-ExecutionPolicy

This shows the effective policy for your current session.

Want more detail? Check all scope levels:

Get-ExecutionPolicy -List

This displays policies at every scope: MachinePolicy, UserPolicy, Process, CurrentUser, and LocalMachine.

The actual policy that applies is the most restrictive one across all scopes.

How to Set Execution Policy in PowerShell (Step-by-Step)

Here’s the core command structure:

Set-ExecutionPolicy -ExecutionPolicy <PolicyName> -Scope <ScopeName>

Setting Policy for Current User (Recommended)

This is the safest approach. It affects only your user account, not the entire machine.

Open PowerShell (no admin rights needed):

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

PowerShell asks for confirmation. Type Y and press Enter.

This allows you to run local scripts and signed remote scripts under your account.

Setting Policy for the Entire Machine

This requires administrator privileges.

Right-click PowerShell and select “Run as Administrator.”

Then execute:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

This affects all users on the computer.

Warning: Changing LocalMachine scope impacts system security for everyone. Only do this on machines you control.

Setting Policy for Current Session Only

Need to run one script without permanently changing settings?

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process

This lasts only until you close the PowerShell window. Perfect for temporary needs.

Bypassing Execution Policy for a Single Script

You can also run individual scripts without changing the policy:

PowerShell.exe -ExecutionPolicy Bypass -File "C:\Scripts\MyScript.ps1"

Or unblock a downloaded script:

Unblock-File -Path "C:\Scripts\DownloadedScript.ps1"

The Unblock-File command removes the “downloaded from internet” flag that triggers RemoteSigned restrictions.

Understanding Execution Policy Scopes

PowerShell uses five scope levels. Understanding them prevents confusion.

Scope	Description	Who Can Set It
MachinePolicy	Set by Group Policy for all users	Domain administrators only
UserPolicy	Set by Group Policy for current user	Domain administrators only
Process	Affects current PowerShell session only	Any user
CurrentUser	Affects current user account	Current user
LocalMachine	Affects all users on the computer	Local administrators

Group Policy scopes (MachinePolicy and UserPolicy) override everything else. If your IT department sets a policy through Group Policy, you cannot change it without admin intervention.

The effective execution policy is the most restrictive one set across all scopes.

Common Execution Policy Errors and Solutions

“Running Scripts Is Disabled on This System”

Full error message:

File cannot be loaded because running scripts is disabled on this system.

Solution: Set execution policy to RemoteSigned or higher:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

“File Is Not Digitally Signed”

You’re trying to run a downloaded script with RemoteSigned policy.

Solution: Either sign the script, change to Unrestricted, or unblock the file:

Unblock-File -Path "C:\Path\To\Script.ps1"

“Access Denied” When Setting Policy

You lack administrator rights for the scope you’re trying to modify.

Solution: Use CurrentUser scope instead of LocalMachine, or run PowerShell as administrator.

Group Policy Overrides Your Settings

Your organization controls execution policy through Group Policy.

Solution: Contact your IT department or use Process scope for temporary workarounds:

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process

Which Execution Policy Should You Use?

The right policy depends on your situation.

For personal computers: RemoteSigned at CurrentUser scope. This lets you run your own scripts while protecting against random downloaded files.

For development machines: RemoteSigned or Unrestricted at CurrentUser scope. You need flexibility but should still verify downloaded scripts.

For enterprise environments: Let Group Policy handle it. Don’t fight your IT department’s policies.

For automation servers: Bypass or Unrestricted at LocalMachine scope. These machines run trusted automation only.

Never use for production: Undefined or Restricted (unless you never run scripts).

According to Microsoft’s official PowerShell documentation at https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies, RemoteSigned provides the best balance for most users.

Security Considerations

Let’s be direct: execution policy is not a security feature.

Anyone can bypass it. Here are just a few methods:

Copy the script content and paste it directly into PowerShell. The execution policy only affects script files, not interactive commands.

Run the script with a bypass flag:

PowerShell.exe -ExecutionPolicy Bypass -File script.ps1

Read the script and execute it:

Get-Content .\script.ps1 | PowerShell.exe -NoProfile -

So why does it exist? It prevents accidents. It stops users from double-clicking malicious .ps1 files without thinking. It creates a small speed bump for basic attacks.

Real security requires:

• Proper user permissions and least privilege access
• Application whitelisting (like AppLocker or Windows Defender Application Control)
• Code signing with trusted certificates
• Regular security audits
• Network segmentation

Don’t rely on execution policy as your primary defense.

Best Practices for Managing Execution Policy

Follow these guidelines to balance usability and security:

Use the least permissive policy that allows your work. If RemoteSigned works, don’t use Unrestricted.

Prefer CurrentUser scope over LocalMachine. This limits impact to your account only.

Sign your production scripts. Get a code signing certificate and sign scripts you distribute.

Document policy changes. Keep notes about why you changed policies on specific machines.

Audit regularly. Check execution policies across your environment periodically.

Train users. Make sure people understand that execution policy isn’t real security.

Use Process scope for testing. When trying new scripts, use temporary scope changes.

Never set Bypass permanently on multi-user machines. This removes all guardrails.

Setting Execution Policy via Group Policy

Enterprise environments should manage execution policy centrally.

Open Group Policy Management Console (GPMC). Navigate to:

Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell

Find “Turn on Script Execution” and configure it.

Options include:

• Allow only signed scripts
• Allow local scripts and remote signed scripts
• Allow all scripts

Apply the policy to appropriate organizational units.

Group Policy settings override local settings. Users cannot change policies set this way without domain admin rights.

Execution Policy in Different PowerShell Versions

Behavior varies slightly across PowerShell versions.

Windows PowerShell 5.1: Default is Restricted on client OS, RemoteSigned on server OS.

PowerShell 7+: Default is Restricted on Windows, Unrestricted on Linux and macOS (where the concept doesn’t really apply).

PowerShell Core 6: Similar to PowerShell 7.

PowerShell 7 runs alongside Windows PowerShell. They maintain separate execution policies. Changing one doesn’t affect the other.

Check your PowerShell version:

$PSVersionTable.PSVersion

Troubleshooting Execution Policy Issues

Policy Won’t Change

Check if Group Policy controls it:

Get-ExecutionPolicy -List

If MachinePolicy or UserPolicy shows a value, Group Policy is in control. You cannot override it locally.

Scripts Still Won’t Run After Changing Policy

Verify the effective policy:

Get-ExecutionPolicy

Close and reopen PowerShell. Policy changes sometimes require a new session.

Check if the script is blocked:

Get-Item "C:\Path\To\Script.ps1" -Stream *

If you see a Zone.Identifier stream, unblock the file:

Unblock-File -Path "C:\Path\To\Script.ps1"

Different Behavior in PowerShell ISE vs Console

PowerShell ISE and PowerShell console can have different effective policies if they run under different contexts or user accounts.

Always check the execution policy in the environment where you’re running scripts.

Quick Reference Table

Task	Command
Check current policy	Get-ExecutionPolicy
Check all scopes	Get-ExecutionPolicy -List
Set for current user	Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
Set for machine (admin)	Set-ExecutionPolicy RemoteSigned -Scope LocalMachine
Set for session only	Set-ExecutionPolicy Bypass -Scope Process
Bypass for one script	PowerShell.exe -ExecutionPolicy Bypass -File script.ps1
Unblock downloaded file	Unblock-File -Path "script.ps1"
Reset to undefined	Set-ExecutionPolicy Undefined -Scope CurrentUser

Conclusion

Setting execution policy in PowerShell is straightforward once you understand the system.

Use Get-ExecutionPolicy to check your current setting. Use Set-ExecutionPolicy with the appropriate scope to change it. RemoteSigned at CurrentUser scope works well for most developers and power users.

Remember that execution policy is not security. It’s a helper that prevents accidents. Real security comes from proper permissions, code signing, and defense in depth.

Start with the least permissive policy that allows your work. Use CurrentUser scope when possible. Sign your production scripts. And keep in mind that anyone can bypass these policies if they really want to.

The key is making informed decisions about your environment and understanding the trade-offs between convenience and protection.

Frequently Asked Questions

What is the default execution policy in PowerShell?

The default execution policy is Restricted on Windows client operating systems like Windows 10 and Windows 11. On Windows Server, the default is RemoteSigned. This means client machines block all scripts by default, while servers allow local scripts and signed remote scripts.

Can I bypass execution policy without admin rights?

Yes. You can set execution policy at CurrentUser scope without administrator privileges. You can also use Process scope or run scripts using bypass methods like PowerShell.exe -ExecutionPolicy Bypass -File script.ps1. The execution policy was never designed as a security boundary.

What’s the difference between RemoteSigned and Unrestricted?

RemoteSigned allows local scripts to run freely but requires downloaded scripts to be signed by a trusted publisher. Unrestricted allows all scripts to run but prompts you before running scripts downloaded from the internet. RemoteSigned is generally more secure for everyday use.

Will changing execution policy affect other users on my computer?

It depends on the scope. CurrentUser scope affects only your account. LocalMachine scope affects all users on the computer. Process scope affects only the current PowerShell session. Use CurrentUser scope to avoid impacting others.

How do I permanently fix the “scripts disabled” error?

Run Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser in PowerShell. This permanently allows you to run local scripts and signed remote scripts under your user account. If Group Policy controls your execution policy, contact your IT department instead.