PowerShell’s execution policy is an administrator safety feature; it’s not a security feature.

Its purpose is to prevent you from accidentally running scripts. It does not stop you from running scripts if you really want to.

All you have to to is start the PowerShell executable with the -ExecutionPolicy parameter set to Bypass (or RemoteSigned, etc.), and your PowerShell process is running with the specified execution policy. Ergo: not a security feature. (If the execution policy was really a security feature, then it wouldn’t be so easy to bypass, would it?)

Even if someone sets the execution policy to Restricted or AllSigned in a Group Policy Object (GPO), this can still be bypassed on the client side by rewriting the registry value (if the user is a member of Administrators) or by running the following function:

function Disable-ExecutionPolicy {
  ($context = $ExecutionContext.GetType().GetField(
   “_context”,”nonpublic,instance”).GetValue($ExecutionContext)).GetType().GetField(
  “_authorizationManager”,”nonpublic,instance”).SetValue(
  $context,(New-Object Management.Automation.AuthorizationManager “Microsoft.PowerShell”))
}

So — if you’re under the impression that a restrictive execution policy will prevent users from running scripts, that’s simply incorrect.

Trying to prevent users from running scripts is a strange thing to want to do anyway. Running scripts doesn’t grant users extra permissions. Another way to say this: PowerShell is a program, not a security boundary. Any program a user starts (including a script, which is run by a program, obviously) runs as that user.

The execution policy can be useful where you want to allow only signed scripts to run automatically by default. But it won’t prevent the user from changing the policy on their own and running scripts.