How to Enable Running Scripts in PowerShell

PowerShell is one of the most powerful tools built into Windows — but the first time many users try to run a .ps1 script, they hit a wall. The error message usually looks something like this:

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

This isn't a bug. It's a deliberate security feature called execution policy, and understanding how it works is the key to getting your scripts running safely.

What Is PowerShell Execution Policy?

Execution policy is a safety mechanism in PowerShell that controls which scripts are allowed to run on a system. Microsoft ships Windows with a restrictive default to prevent malicious scripts from running automatically — for example, in phishing attacks or malware that disguises itself as a .ps1 file.

There are several execution policy levels, and each one draws the line differently:

For most personal or developer use cases, RemoteSigned is the practical sweet spot: it keeps you protected from untrusted downloaded content while letting you run scripts you've written yourself.

How to Check Your Current Execution Policy

Before changing anything, it helps to know where you're starting from. Open PowerShell and run:

Get-ExecutionPolicy 

If the result is Restricted, that explains the error. You can also check policies across all scopes with:

Get-ExecutionPolicy -List 

This shows policies applied at the MachinePolicy, UserPolicy, Process, CurrentUser, and LocalMachine levels. The most restrictive policy in the chain wins.

How to Enable Script Execution in PowerShell 🛠️

Option 1: Change the Policy for the Current User

This is the most common and least disruptive approach. Open PowerShell as Administrator and run:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser 

Using -Scope CurrentUser means the change only applies to your account — it doesn't affect other users on the same machine. You'll be prompted to confirm. Type Y and press Enter.

Option 2: Change the Policy System-Wide

If you need scripts to run for all users on the machine — common in IT or shared workstations — use:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine 

This requires Administrator privileges and affects every user account on the system.

Option 3: Bypass the Policy for a Single Session

If you don't want to permanently change settings, you can override execution policy for just the current PowerShell session:

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process 

Once you close that PowerShell window, the setting reverts. This is useful for one-off tasks or testing scripts without altering your system configuration.

Option 4: Run a Single Script Without Changing Global Policy

You can also invoke a script directly with an inline bypass:

PowerShell -ExecutionPolicy Bypass -File "C:path oyourscript.ps1" 

This is a clean option when you want to run a specific script once without touching any persistent settings.

What About Group Policy?

On domain-joined machines — computers managed by an organization's IT department — execution policy may be enforced through Group Policy. In that case, Set-ExecutionPolicy will either fail or appear to work but get overridden on the next login.

If you see MachinePolicy or UserPolicy at the top of the Get-ExecutionPolicy -List output with a restrictive setting, Group Policy is likely in control. Changing this requires access to Group Policy management tools or coordination with your IT administrator — not something that can be worked around at the user level.

Security Considerations Worth Understanding ⚠️

Execution policy is a convenience feature, not a full security boundary. A determined attacker can bypass it in several ways — which is why Microsoft is explicit that it's not a substitute for proper access controls.

That said, keeping your execution policy at RemoteSigned or AllSigned rather than Unrestricted or Bypass does meaningfully reduce exposure to accidental script execution. The risks shift depending on:

• Whether you're running scripts from the internet vs. written locally
• Whether the machine is shared or personal
• Whether you're in a managed corporate environment vs. a home setup
• How frequently you're running third-party scripts or automation tools

Scripts downloaded from the internet — including from otherwise trusted sources — carry more risk than locally authored ones. RemoteSigned draws that line for you automatically.

The Variables That Shape the Right Approach

There's no one-size-fits-all answer here because the correct execution policy depends on several factors specific to your situation:

• Who else uses the machine — a personal laptop has different needs than a shared workstation
• What kinds of scripts you're running — development automation, IT management scripts, and one-off utilities each carry different risk profiles
• Whether your machine is domain-joined — Group Policy may override any changes you make
• Your Windows edition and version — PowerShell behavior and defaults can vary between Windows 10, Windows 11, and Windows Server editions
• Whether you're using Windows PowerShell (5.1) or PowerShell 7+ — these are separate installations with separate execution policies

The commands above work across both versions, but if you have both installed, changing the policy in one doesn't automatically affect the other. Your system may have more than one PowerShell environment active simultaneously, each with its own independent policy state.