No. Microsoft's documentation says the execution policy is not a security boundary, it is defense in depth, and that a user can easily bypass it by typing a script's contents at the command line. It helps people avoid running scripts by accident. It does not stop a determined attacker or malicious code.
What it actually does
PowerShell's execution policy is described as a safety feature that controls the conditions under which PowerShell loads configuration files and runs scripts. It sets basic rules and prevents users from violating them unintentionally. On Windows clients, if no policy is set in any scope, the effective policy is Restricted, and RemoteSigned is described as the default for Windows computers. On non-Windows systems the policy is Unrestricted and cannot be changed.
The policies in plain words
| Policy | What it means |
|---|---|
| Restricted | Individual commands run, scripts do not |
| AllSigned | All scripts must be signed by a trusted publisher, including your own |
| RemoteSigned | Scripts downloaded from the internet must be signed; local ones need not be |
| Unrestricted | Unsigned scripts can run, with a warning for non-local ones |
| Bypass | Nothing is blocked and there are no warnings |
Even AllSigned notes a risk: it can run signed but malicious scripts.
Why developers should care
Developers often set the policy to something loose because a tool's install script would not run. That is a convenience change, and it is fine as long as nobody believes it was ever protecting the machine. Two details from the documentation are worth knowing:
- The downloaded from the internet mark comes from an alternate data stream added by browsers. Microsoft notes that other download methods, such as
curl.exe,Invoke-RestMethodandInvoke-WebRequest, may not mark files that way. A script fetched by a command line tool can therefore skip the RemoteSigned check. - A process scope setting, for example
pwsh.exe -ExecutionPolicy AllSigned, only affects that session, and Group Policy overrides all scopes.
What to rely on instead
- Treat the policy as a guardrail against accidents, not as a control.
- Review scripts before running them, especially ones piped from the internet. See is curl pipe to shell safe to run.
- Use the least rights you can. Run as a standard user and elevate only when needed.
- Keep real controls, such as application allow listing and endpoint management, in the hands of your IT team where they exist.
- Check the effective setting with
Get-ExecutionPolicy -Listso you know which scope is winning.
Safeguard scans the dependencies behind your projects and gives you an SBOM, which covers the packages your scripts install rather than the scripts themselves. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Should I set Bypass to make installers work?
Prefer a process scoped setting for one session. It is not stored in the config file and goes away when the session closes.
Does execution policy apply on macOS and Linux?
Not in practice. Microsoft says enforcement occurs only on Windows, and the non-Windows value is Unrestricted.
Sources
Last reviewed: 19 October 2026.
