PowerShell Security: Goals, Mechanisms, and Script Execution Policies

1. PowerShell Security Goals

PowerShell has one primary security goal: preventing inexperienced users from unintentionally running scripts. It is not designed to stop authorized users from performing dangerous actions. If a user has permission to delete Active Directory accounts, PowerShell will allow it—just like any other administrative tool.

PowerShell is not a security gateway. Real security must be enforced through Windows permissions, roles, and access control—not through PowerShell itself.

2. PowerShell Security Mechanisms

PowerShell includes three built‑in layers of protection, all enabled by default:

2.1 Script Execution Requires a Path

PowerShell never executes scripts from the current directory unless a path is explicitly provided.
Running dir will never execute dir.ps1.
Scripts must be run using paths like .\script.ps1 or C:\Scripts\script.ps1.
This prevents “command hijacking” by malicious scripts with common names.

2.2 File Extensions Are Not Executable

Extensions like .ps1, .psm1, .psd1 are not associated with PowerShell.exe.
Double‑clicking a script opens it in a text editor instead of executing it.
This prevents accidental execution of malicious attachments.

2.3 Execution Policy

The most important layer, controlling which scripts are allowed to run based on signature requirements.

3. Digital Signatures and Script Signing

Digital signatures ensure two things:

The identity of the script’s author.
That the script has not been modified since it was signed.

3.1 Creating a Code‑Signing Certificate

For testing, you can use MakeCert.exe to create a local certificate:

makecert -n "CN=PowerShell Local Certificate Root" -a sha1 ...

3.2 Signing a Script

Set-AuthenticodeSignature .\script.ps1 -Certificate $cert

If the script is edited—even by one character—the signature becomes invalid and must be reapplied.

4. Execution Policy in PowerShell

Execution Policy determines which scripts PowerShell will allow to run. It is not a security boundary—it is a safety mechanism.

Execution Policy Levels

Restricted: No scripts run at all.
RemoteSigned: Local scripts run freely; downloaded scripts require a valid signature.
AllSigned: Every script must be signed.
Unrestricted: All scripts run without signature checks.
Bypass: No restrictions; intended for hosting scenarios.

Viewing and Changing Execution Policy

Get-ExecutionPolicy
Set-ExecutionPolicy RemoteSigned

Execution Policy is stored in the Registry and can be enforced via Group Policy.

5. How PowerShell Handles Script Execution

When running a script, PowerShell checks:

Whether the script is signed.
Whether the signature is valid.
Whether the current Execution Policy allows it.

If the signature is invalid, PowerShell reports a HashMismatch error.

Conclusion

PowerShell does not replace Windows security—it simply adds guardrails to prevent accidental misuse. By understanding its security mechanisms, digital signatures, and execution policies, administrators can create a safe and controlled scripting environment while maintaining full flexibility and automation power.