PowerShell Execution Policies Explained for IT Admins

You run a script and get back: "cannot be loaded because running scripts is disabled on this system." So you Google the fix, find Set-ExecutionPolicy Unrestricted, and move on. That works — but it is probably the wrong call, and if you are managing a fleet, it may be creating problems you will not see until an audit.

PowerShell execution policies are rules that determine which scripts can run in a given PowerShell session. There are six policy types and five scopes, each with a defined precedence order. One important thing to establish upfront: Microsoft's own documentation states that execution policy is not a security system. It is designed to prevent accidental script execution, not malicious execution. That distinction matters.

There are also two separate PowerShell engines — Windows PowerShell 5.1 and PowerShell 7.x — and they maintain completely independent policy settings. The enforcement method you choose (local command, Group Policy, or MDM) determines whether users can override what you set. For fleet management, that difference is significant.

This article covers all six policy types, all five scopes and their precedence, how to check and set policies with the right commands, how to enforce them via Group Policy and MDM for cloud-managed environments, the security controls that work alongside execution policy, what compliance frameworks require, and how Trio MDM helps you manage this at scale.

What PowerShell Execution Policy Actually Does (and Doesn't Do)

If you already know what execution policy does and just need the commands, skip ahead to How to Check and Set PowerShell Execution Policy.

PowerShell execution policies are preference settings. They tell PowerShell whether to run scripts, and under what conditions. They are not a firewall, not an antivirus layer, and not an access control mechanism. Microsoft's documentation is direct on this point: execution policy is not a security system that restricts user actions. Anyone can bypass it by typing script contents directly at the command line.

Its real purpose is to prevent accidental script execution — a double-click on a .ps1 file, an unintended run from an Explorer context menu. That is a legitimate operational safeguard. But it is why you will occasionally hear practitioners call it security theater, and that's worth taking seriously. Execution policy works alongside other controls — the enforcement method and layered stack are what make the environment defensible. That's exactly why the enforcement method matters, and why this article covers more than just the six policy types.

Two PowerShell engines are in common use: Windows PowerShell 5.1, which ships with Windows 10/11 and Server 2016 through 2025 and is in maintenance mode, and PowerShell 7.x, which is cross-platform and installed side-by-side. As of its 7.4 LTS release, PowerShell 7 defaults to RemoteSigned on Windows — completely independently of whatever 5.1 is configured to. Setting execution policy on one engine has zero effect on the other.

If you have ever set RemoteSigned and still had a script blocked, or set a policy that seemed to apply but did not stop anything, the answer is almost always in the scope chain — or in the fact that execution policy was never meant to catch the attack in the first place. Both topics are covered below.

The Six Policy Types and Five Scopes

Knowing how to powershell set execution policy correctly means understanding two separate dimensions: the type (what behavior you want) and the scope (where it applies and who it affects). A RemoteSigned policy at the CurrentUser scope behaves very differently from the same policy enforced at MachinePolicy via Group Policy. The combination of type and scope determines the actual outcome on the machine.

The Six Policy Types

• Restricted — No scripts run at all; interactive commands only. This is the default for Windows 10/11 client machines. Most secure for endpoints that have no scripting need, but it blocks all automation.
• AllSigned — Every script, local and remote, must be signed by a trusted publisher. Requires PKI infrastructure to work at scale. The most restrictive scripting policy available — covered in detail in its own section below.
• RemoteSigned — Internet-downloaded scripts must be signed; locally created scripts run without a signature. Default for Windows Server. The standard enterprise baseline — but "remote" means the file carries a Zone.Identifier tag (Mark of the Web), not simply "from a network share."
• Unrestricted — All scripts run; internet-origin scripts prompt the user but are not blocked. This should never be set as a persistent policy on production machines. It exists, and you should know it exists, but it belongs nowhere near a managed endpoint.
• Bypass — Nothing is blocked, no warnings, no prompts. Designed for automation environments where the calling application enforces its own security. Tools that handle remote script execution typically rely on Process-scope Bypass so each session manages its own security context without inheriting persistent settings. Session-scoped use in controlled environments is reasonable; persistent LocalMachine Bypass on production endpoints is not.
• Undefined — No policy is set at this scope. The session falls through to the next scope in the precedence chain. This is the correct value to leave at scopes you want to inherit from a higher-priority setting.

The Five Scopes and Precedence Order

Scopes are evaluated from highest to lowest priority. The first scope with a defined (non-Undefined) value wins.

• MachinePolicy — Set by Group Policy for all users on the machine. Stored at HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell. Cannot be overridden by any local command.
• UserPolicy — Set by Group Policy for the current user. Stored at HKCU\SOFTWARE\Policies\Microsoft\Windows\PowerShell. Also GPO-enforced; also cannot be overridden locally.
• Process — Applies only to the current session. Not stored anywhere — it disappears when the session ends. The right scope for temporary exceptions and automation jobs.
• CurrentUser — Applies to the current user. Stored in HKCU. Standard users can write here without elevation — a detail that is easy to miss. This is exactly why relying on local Set-ExecutionPolicy alone is not sufficient for fleet enforcement: a standard user can silently change their own scope.
• LocalMachine — Applies to all users on the machine. Stored in HKLM. Requires elevation to change.

GPO wins, full stop. When MachinePolicy or UserPolicy is set via Group Policy, any local Set-ExecutionPolicy command will either fail or be silently ignored. Run Get-ExecutionPolicy -List to see every scope and its current value — not just the effective policy.

If you rely on -Scope Process for build pipelines or automation jobs, note that Process scope does not carry over between sessions. Each new PowerShell session starts fresh with whatever the inherited scope chain says — the parent process needs to set it every time.

If Set-ExecutionPolicy runs without error but the policy does not change, check whether MachinePolicy or UserPolicy scope is already set via GPO. That is the scope that wins, and the local command has no effect on it.

How to Check and Set PowerShell Execution Policy

Knowing how to set execution policy in powershell correctly starts with knowing what is already configured — before you change anything. These are the commands you will use in practice.

Checking the Current Policy

Get-ExecutionPolicy returns the effective (winning) policy only. It does not tell you which scope is enforcing it or what the other scopes are set to.

Get-ExecutionPolicy -List returns all five scopes and their current values. This is the command to run before any troubleshooting. If a scope shows Undefined, no policy is set there — it falls through to the next scope in the chain.

To check whether a specific script is tagged as an internet download, use:

Get-Item .\script.ps1 -Stream "Zone.Identifier"

Practitioners call this checking for the Mark of the Web (MOTW). If Zone ID = 3, the file is from the internet zone and will be blocked under RemoteSigned. To remove the tag:

Unblock-File -Path .\script.ps1

This strips the Zone.Identifier stream so RemoteSigned treats the script as local.

Setting the Policy

Set RemoteSigned for all users on the machine (requires elevation):

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

This sets the LocalMachine scope. It affects all users but can be overridden by MachinePolicy or UserPolicy scopes if GPO is in play.

Set Bypass for the current session only (no elevation required):

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process

This applies only to the current session and does not persist. It is the recommended approach for temporary exceptions without changing the machine's standing policy.

Set RemoteSigned for the current user only:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Running these commands on 200+ devices one at a time is not realistic — that is the problem the final section of this article addresses directly.

If Set-ExecutionPolicy returns an error saying the operation is not supported on this system, run Get-ExecutionPolicy -List first. A MachinePolicy or UserPolicy scope set via GPO is almost certainly blocking the change.

Enforcing Execution Policy at Scale — GPO and MDM

Knowing how to change execution policy powershell settings on a single machine is straightforward. Getting that change consistently applied across every endpoint in your fleet — and keeping it there — is the harder problem. There are two main paths depending on how your environment is built.

Group Policy (On-Premises / Hybrid AD)

For domain-joined machines, configure execution policy via Group Policy at this path:

Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on Script Execution

The setting maps three options to policy types: Allow all scripts (Unrestricted), Allow local scripts and remote signed scripts (RemoteSigned), Allow only signed scripts (AllSigned). Setting this via GPO creates a MachinePolicy scope entry — it overrides any local Set-ExecutionPolicy command. Users cannot change it. GPO wins.

The registry path for scripted auditing across the fleet is:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell — ExecutionPolicy (REG_SZ)

The Windows 11 24H2 ADMX templates were updated in October 2024. The PowerShell GPO path itself is unchanged, but you should import the latest ADMX files from the Microsoft Download Center to ensure accurate policy reporting in the Group Policy Management Console.

This GPO path applies to Windows PowerShell 5.1 only. PowerShell 7 uses a different registry hive — if both engines are deployed on your servers, you need to configure policy for both independently.

MDM and Cloud-Managed Environments (No On-Prem GPO)

For Azure AD Joined or Intune-managed devices without access to on-premises Group Policy, execution policy is enforced through the Intune Settings Catalog under Windows PowerShell. MDM-based enforcement creates the equivalent of the MachinePolicy scope — users cannot override it locally. This directly addresses one of the most frequently unanswered questions for cloud-native fleet admins: how to enforce execution policy when there is no on-prem GPO.

For organizations that need both policy enforcement and visibility into whether the policy is actually applied across every device, Trio MDM's RMM capabilities fill the monitoring gap that MDM alone does not cover.

One thing worth naming: getting a Group Policy change approved through change control, tested in a lab, and staged to production typically takes longer than the technical change itself. Build that into your planning before you start.

Why Execution Policy Alone Is Not Enough — and What to Use Alongside It

Execution policy on its own is a limited control — it prevents accidents, not attacks. The documented bypass techniques take under 30 seconds for anyone who knows what they are doing. MITRE ATT&CK T1059.001 (PowerShell abuse) is one of the most frequently observed sub-techniques across adversary groups tracked by MITRE. Execution policy alone will not stop any of them.

Common bypass approaches include: passing -ExecutionPolicy Bypass as a flag to powershell.exe, encoding script content in Base64, invoking the script via Invoke-Expression, downloading and running script content directly from memory, and using the PowerShell 2.0 engine (which predates many modern controls). Admins searching for how to set powershell set execution policy unrestricted to quickly unblock a problem script are creating exactly the gap these techniques exploit — a persistent, machine-wide Bypass with no audit trail.

The PS 2.0 downgrade is the most consequential of these — it bypasses both execution policy and AMSI. Disabling PowerShell 2.0 is addressed in the AMSI section directly below.

This is why layering Script Block Logging and AMSI on top of execution policy governance matters. The full stack is what makes the environment defensible, not any single setting in isolation.

AMSI (Antimalware Scan Interface)

AMSI scans PowerShell script content at runtime, independent of execution policy. Even if the policy is set to Bypass, a compatible AV or EDR platform can still detect and block malicious content before it runs. AMSI is available on Windows 10 and Server 2016 and later — it activates automatically when a compatible security product is installed.

One important gap: the PowerShell 2.0 downgrade attack bypasses AMSI entirely, because PS 2.0 predates the interface. This is why disabling PowerShell 2.0 is a DISA STIG requirement (STIG ID WN10-CC-000315).

If AMSI is blocking a script you know is safe, the issue is almost always pattern matching. The fix is whitelisting the specific script hash in your AV or EDR — not disabling AMSI.

Script Block Logging (Event ID 4104)

Script Block Logging records the full content of every executed script block, regardless of execution policy. A Bypass-executed script is still logged. No forensic record exists without it — a useful practitioner shorthand is "script block logging or it didn't happen."

Enable via GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging. This generates Event ID 4104 in the Microsoft-Windows-PowerShell/Operational log.

Once you enable Script Block Logging, expect a notable increase in log volume on endpoints. Make sure your SIEM or log forwarding infrastructure can handle the additional data before enabling it fleet-wide. This is exactly the visibility gap that Trio MDM's compliance monitoring addresses — covered in the section below.

Constrained Language Mode and WDAC

Constrained Language Mode restricts which .NET types and PowerShell language elements are available in a session, making many attack techniques non-functional even when execution policy is bypassed. It is triggered automatically by Windows Defender Application Control (WDAC) when script enforcement is active. Windows 11 24H2 updated the WDAC policy engine in October 2024, including changes to script enforcement behavior under Constrained Language Mode. For remoting environments, Just Enough Administration (JEA) adds another layer by restricting which cmdlets a user can run regardless of execution policy settings.

AllSigned Policy and Code Signing in Practice

AllSigned is the most restrictive scripting policy available and technically the most secure. The reason most mid-market organizations do not use it is operational, not technical.

To run AllSigned at scale, you need a PKI — either Active Directory Certificate Services internally or a commercial CA — certificates with the Code Signing EKU (OID 1.3.6.1.5.5.7.3.3), and a consistent process for signing every script before deployment. Key commands:

Set-AuthenticodeSignature -FilePath .\script.ps1 -Certificate $cert   # signs a script
Get-AuthenticodeSignature .\script.ps1                                  # verifies the signature
New-SelfSignedCertificate                                               # lab use only

That last point matters: self-signed certificates do not propagate trust to other machines without a PKI chain of trust. Practitioners consistently run into this — a cert that works on the machine where it was created fails everywhere else. This is not a PowerShell quirk; it is how certificate trust works.

The organizational friction in implementing AllSigned typically is not the PKI setup itself. It is getting developers and script authors to sign every script before deployment, and maintaining that discipline across teams and environments over time.

Most mid-market organizations settle on RemoteSigned + Script Block Logging + GPO or MDM enforcement as their practical baseline. AllSigned is the right answer for high-security environments with the PKI infrastructure and operational discipline to support it. Both are defensible choices — the decision belongs to your organization based on your actual risk posture and operational capacity.

Execution Policy and Compliance Frameworks

Execution policy governance is rarely a single checkbox in a compliance audit. It shows up as evidence under multiple controls across several frameworks. The unifying principle across all of them is "documented" — the policy needs to exist, be enforced via GPO or MDM, and be auditable.

• CIS Benchmarks (Windows 10/11 v3.0.0 and Windows Server 2022 v3.0.0, both March 2024): Recommend RemoteSigned or more restrictive via GPO. Separately require PowerShell Script Block Logging and disabling PowerShell 2.0.
• NIST SP 800-53 Rev 5: CM-7 (Least Functionality) and SI-3 (Malicious Code Protection) apply directly. CM-7 requires restricting software execution to only what is necessary for the business function — uncontrolled script execution conflicts with this control.
• NIST SP 800-171 Rev 3 (published May 2024): Control 3.4.6 (Principle of Least Functionality) aligns with RemoteSigned or AllSigned in environments handling Controlled Unclassified Information. Note: Rev 3 was a significant structural update with changed control numbering.
• DISA STIG (Windows 10 V2R9 and Windows 11 V2R2, both April 2024): Two binary pass/fail checks — WN10-CC-000326 (Script Block Logging must be enabled) and WN10-CC-000315 (PowerShell 2.0 must be disabled).
• SOC 2 (AICPA Trust Services Criteria): No specific execution policy mandate, but CC6.1 and CC7.1 require documented controls over script execution. GPO or MDM-enforced execution policy governance is commonly cited as audit evidence.
• ISO/IEC 27001:2022: Controls A.8.9 (Configuration Management) and A.8.19 (Installation of Software on Operational Systems) are relevant — uncontrolled script execution can violate configuration change controls.

How Trio MDM Helps You Manage PowerShell Execution Policy at Scale

Configuring execution policy on a single machine takes 30 seconds. Enforcing it, auditing it, and keeping it consistent across 200 to 400 endpoints is a different operational problem — one that requires visibility and automation that local commands alone cannot provide.

Remote script execution across the fleet: Trio MDM's RMM agent lets you run PowerShell commands on managed Windows devices from a central console. You can write a command once and execute it immediately, save it as a reusable template, or schedule it to run at a specific time. This is the practical mechanism for deploying Set-ExecutionPolicy changes, running Get-ExecutionPolicy -List to audit current policy state across devices, or using Unblock-File on flagged scripts — without touching each machine individually.

Compliance monitoring and fleet-wide visibility: Trio MDM provides real-time compliance status at the device level and calculates a company benchmark score across your full fleet. Failed security controls are surfaced immediately, giving you a clear view of which devices are out of policy without running manual scans. This directly addresses the audit question practitioners ask most: how do I know which machines in my fleet have non-compliant execution policy settings? Trio MDM also has Windows CSP support in development, which will extend configuration management capabilities for cloud-managed Windows devices. Contact the team for details on scope and availability.

If you want to see how Trio MDM handles fleet-wide policy management, you can start your free trial or book a demo to walk through the RMM and compliance capabilities with the team.