PowerShell's execution policy is not a security boundary — what actually restricts scripts

What it is

PowerShell's execution policy setting is often mistaken for an access control. Microsoft's own documentation states it plainly: "The execution policy isn't a security boundary, it's defense in depth. For example, users can easily bypass a policy by typing the script contents at the command line when they can't run a script. Instead, the execution policy helps users to set basic rules and prevents them from violating them unintentionally." The policy applies per scope — Get-ExecutionPolicy -List shows the effective value for MachinePolicy, UserPolicy, Process, CurrentUser, and LocalMachine, in that precedence order, and Group Policy-sourced policy scopes override anything set locally.

Why it matters

An agent or operator who treats Set-ExecutionPolicy Restricted as a defense against untrusted or malicious scripts is protecting against accidental double-clicks, not a deliberate attempt to run code: the same content run via -EncodedCommand, piped into powershell -Command -, or dot-sourced from an interactive prompt bypasses the file-based restriction entirely, exactly as the documentation warns. Relying on it as a control gives a false sense of coverage in a threat model.

How to apply

• Use the execution policy for what it is designed for: preventing an unattended, accidental run of an unsigned or downloaded script. Set it per need with Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine.
• For an actual code-execution boundary, use application control: App Control for Business (the current name for what shipped as Windows Defender Application Control / WDAC) enforces which binaries, scripts, and PowerShell modules are allowed to run at all, independent of any execution-policy setting.
• AppLocker is Microsoft's earlier, more limited application-control feature — usable where App Control for Business's full policy model is not needed or not yet deployed — and it likewise governs what runs, not what an execution-policy scope permits.
• Where PowerShell itself is constrained by an application-control policy, sessions can be placed in Constrained Language Mode, one of the documented language modes (FullLanguage, RestrictedLanguage, ConstrainedLanguage, NoLanguage) that limits which language elements — not just which script files — are permitted in the session; this is enforced by the session configuration, not by the execution policy.
• In a threat model or an audit, record execution policy and application control as two separate rows; a "Restricted" execution policy next to no application control policy is not a mitigated finding.

Pitfalls

• Auditing "execution policy is set to AllSigned" as evidence of hardening without checking whether App Control for Business, AppLocker, or Constrained Language Mode are present.
• Assuming Set-ExecutionPolicy -Scope Process on a remote endpoint changes the machine-wide posture — it only affects that one process's session.
• Forgetting that MachinePolicy and UserPolicy scopes, when set by Group Policy, silently override a locally issued Set-ExecutionPolicy, which can make a change appear to fail for no visible reason.