PowerShell Script Blocked by ExecutionPolicy: Diagnostic Guide

Recognizable condition

You run a PowerShell script and execution stops before any code runs. Typical messages are "cannot be loaded because running scripts is disabled on this system" or "cannot be loaded because the script is unsigned". The script may be local, downloaded, or invoked from a build step. ExecutionPolicy is not a security boundary for interactive commands, only for scripts and modules.

Useful takeaway: ExecutionPolicy is evaluated per scope with precedence MachinePolicy > UserPolicy > LocalMachine > CurrentUser > Process. Group Policy sets MachinePolicy and UserPolicy and cannot be overridden by local Set-ExecutionPolicy.

Cause / diagnostic table

Ordered checks

1. Capture the exact error and context

Run PowerShell as the same user and from the same working directory that fails. Note the full error text, the script path, and whether the file was downloaded.

2. List effective policy scopes

Open PowerShell console. No admin rights needed to read.

Get-ExecutionPolicy -List

Expected checks: identify which scope is non-Undefined and which is effective. MachinePolicy and UserPolicy, if set, win over all local settings. LocalMachine requires Administrator to change. CurrentUser can be changed by the user.

3. Inspect script origin and signature

For a specific file:

Get-AuthenticodeSignature -Path <Path\To\Script.ps1>

Check Status and SignerCertificate. A script from an internet zone carries an alternate data stream that PowerShell treats as remote. RemoteSigned requires a valid signature for remote files.

Risk: do not trust a signature without verifying the certificate chain and publisher.

4. Test with Process scope isolation

Process scope affects only the current PowerShell process and does not persist. Useful for confirming policy is the blocker without changing machine state.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

Run the script in the same process. If it now runs, the issue is policy scope, not file integrity. Revert is automatic when the process ends. No rollback needed.

Permission note: Process scope does not require Administrator.

Fixes tied to findings

Effective policy is Restricted

If MachinePolicy and UserPolicy are Undefined, set a user-scoped policy:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

Risk: RemoteSigned still requires signatures for remote files. Avoid Unrestricted or Bypass for persistent use.

Group Policy overrides local setting

If Get-ExecutionPolicy -List shows MachinePolicy or UserPolicy set, local Set-ExecutionPolicy will not help and may be reverted on refresh. Do not use Bypass permanently.

Fix path: request change via IT security or run the script in an approved context. Document the required policy value and business justification.

Script is unsigned and policy requires signature

Options: sign the script with a trusted certificate, or move the script to a trusted local path and use RemoteSigned. Signing requires access to a code-signing certificate trusted by the local machine.

Verification: after signing, re-run Get-AuthenticodeSignature and confirm Status is Valid.

Certificate not trusted

Install the publisher certificate into the Trusted Publishers store for the user or machine. This requires Administrator for machine store. Verify by re-checking signature status.

Escalation criteria

• MachinePolicy or UserPolicy is set by Group Policy and cannot be changed locally.
• Multiple users report the same block and the policy is enforced centrally.
• Script requires Bypass or Unrestricted to run and cannot be signed or moved.
• Signature validation fails with a certificate chain error you cannot resolve.

Escalate to Windows administration or security team with the output of Get-ExecutionPolicy -List and Get-AuthenticodeSignature.

Limitations and verification

ExecutionPolicy does not prevent execution of individual commands typed interactively. It only gates script and module loading. Changing policy does not validate script content.

Practical verification after any change:

1. Re-run Get-ExecutionPolicy -List to confirm the effective scope.
2. Open a new PowerShell process and attempt to run the script.
3. If a temporary Process scope test succeeded, revert any persistent change and document the original value.

Always verify source and integrity of scripts before relaxing policy. Use Group Policy for enterprise enforcement rather than manual per-machine changes.