How To Enable Script Execution In PowerShell | Set Policies That Work

To enable script execution in PowerShell, use the Set-ExecutionPolicy cmdlet, with RemoteSigned offering the best balance of security and usability.

A PowerShell script that refuses to run isn’t broken — it’s blocked by the execution policy, a safety feature that keeps untrusted code from executing uninvited. The fix takes one command, but picking the wrong setting can open security holes you didn’t intend. This guide covers every method that works, the trade-offs each one carries, and the mistakes that keep scripts blocked even after you’ve changed the policy.

What Is A PowerShell Execution Policy?

A PowerShell execution policy is a safety mechanism that determines which scripts can run on your system and under what conditions. It’s not a security boundary — a determined attacker can bypass it — but it prevents accidental execution of malicious code and stops unsigned or untrusted scripts from running without your knowledge.

The default policy on most Windows systems is Restricted or RemoteSigned depending on the build. Restricted blocks all scripts. RemoteSigned lets local scripts run without a signature but requires remote scripts — those downloaded from the internet — to carry a trusted digital signature. PowerShell 7.6 and Windows PowerShell 5.1 both follow these same rules.

Check Your Current Execution Policy First

Checking your current policy with Get-ExecutionPolicy takes five seconds and prevents unnecessary changes. Open PowerShell as Administrator, type Get-ExecutionPolicy, and press Enter. The output shows the effective policy for your current session.

To see every scope at once — including policies set by Group Policy that override local settings — run Get-ExecutionPolicy -List. The list shows five scopes in priority order, with the highest-priority non-undefined value being the effective policy.

Enabling Script Execution In PowerShell: Three Reliable Methods

Three approaches let you enable scripts in PowerShell: changing the policy permanently with Set-ExecutionPolicy, bypassing it temporarily with the -ExecutionPolicy flag, or configuring it via Group Policy for managed environments. Each serves a different use case.

Method 1: Set-ExecutionPolicy (Permanent Change)

This is the standard route for daily script work. Open PowerShell as Administrator, then run the command for your preferred policy level. When prompted, type Y (or A for “Yes to All” on Windows 11) and press Enter.

Set-ExecutionPolicy RemoteSigned — local scripts run without a signature; remote scripts must be signed. This is the recommended setting for everyday use.

Set-ExecutionPolicy Unrestricted — all scripts run regardless of signature. Use only on isolated development machines.

Set-ExecutionPolicy Bypass — no checks at all. Useful for automated deployment scripts but leaves the system wide open.

Verify the change with Get-ExecutionPolicy — the output should match what you set. The no error message, and the new policy appears in the output.

Method 2: Bypass Flag (Temporary, No Admin Required)

To run a single script without changing the system policy permanently, use the -ExecutionPolicy Bypass flag when launching PowerShell from the command line or another script:

powershell.exe -ExecutionPolicy Bypass -File .\YourScript.ps1

This override applies only to that one invocation. The system policy stays unchanged, and no confirmation prompt appears. The the script runs without an “execution of scripts is disabled” error.

Method 3: Group Policy (For Domains and Managed Environments)

In enterprise settings, domain-level Group Policy often overrides local execution policy settings. To configure it centrally, open gpedit.msc and navigate to Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell. Enable “Turn on Script Execution” and set the policy to “Allow all scripts.”

This method requires the Group Policy Management Console and is typically handled by IT administrators. Local policy changes are ignored when a domain policy is enforced — the success cue is that domain-joined machines now run scripts without reverting to Restricted.

Execution Policy Options

The RemoteSigned policy works for most people most of the time. Only drop to Unrestricted or Bypass when a specific script requires it, and revert immediately after.

Common Mistakes That Keep Scripts Blocked

Most “still blocked” issues after changing the execution policy come from one of four sources: wrong scope, architecture mismatch, domain policy override, or a missed confirmation prompt. Each has a straightforward fix.

• Wrong scope. Running Set-ExecutionPolicy without the -Scope parameter defaults to LocalMachine, which requires Administrator privileges. Use -Scope CurrentUser to set the policy for your account without admin rights: Set-ExecutionPolicy -Scope CurrentUser RemoteSigned.
• 32-bit and 64-bit mismatch. PowerShell’s 32-bit and 64-bit versions have separate execution policy settings. If you set the policy in 64-bit PowerShell but run scripts in 32-bit PowerShell (located at C:\Windows\SysWOW64\cmd.exe), the scripts will still be blocked. Set the policy in both versions.
• Domain policy override. On a domain-joined machine, Active Directory Group Policy can override local execution policy settings. Even if Get-ExecutionPolicy shows RemoteSigned locally, a domain policy set to Restricted will take precedence. Check Get-ExecutionPolicy -List — if the MachinePolicy or UserPolicy scope shows a value, that’s the domain override.
• Forgotten confirmation prompt. After running Set-ExecutionPolicy, PowerShell asks for confirmation. If you type anything other than Y (or A on Windows 11) and press Enter, the policy doesn’t change.

Scope Comparison

The Process scope is ideal for testing — it requires no admin rights and resets when you close the PowerShell window. The CurrentUser scope is the best permanent option for individual developers who don’t have admin access.

Security Considerations Before Changing Policies

Execution policies are a safety mechanism, not a security boundary. They prevent accidental script execution but won’t stop a determined attacker or malware that already has user-level access. Microsoft’s official documentation makes this distinction clear.

Using Unrestricted or Bypass as your permanent policy allows unsigned remote scripts to run without any checks, increasing exposure to malware. For daily use, RemoteSigned is the right balance — local scripts you write work without signatures, but anything downloaded from the internet must be signed by a publisher you trust. After running a one-off script, revert the policy back to RemoteSigned or Restricted with Set-ExecutionPolicy RemoteSigned.

For environments that require stronger protection, sign your scripts with a code-signing certificate and use the AllSigned policy. This ensures only scripts signed by approved publishers can execute, which is the standard practice in managed enterprise environments.

Choosing The Right Execution Policy

The best execution policy depends on what you’re doing and who controls the machine. Use this quick checklist to decide:

• Daily script development on your own machine: Set-ExecutionPolicy RemoteSigned — local scripts work, remote scripts stay safe.
• Running one script from a trusted source: Use the -ExecutionPolicy Bypass flag — no permanent change, no security risk.
• No admin access but need scripts to run: Set-ExecutionPolicy -Scope CurrentUser RemoteSigned — works without elevation.
• Domain-managed corporate machine: Contact IT or use Group Policy — local changes will be overridden.
• Testing a script without committing: Set-ExecutionPolicy -Scope Process Bypass — resets when you close the window.

After any change, run Get-ExecutionPolicy -List to confirm the active scopes. If the policy you set isn’t the one shown as effective, check for a domain override or a higher-priority scope blocking it.