Windows - Security - Set PowerShell ExecutionPolicy to AllSigned

What the PowerShell AllSigned enforcer does

This Automox Worklet™ sets the PowerShell execution policy to AllSigned at the machine level on Windows endpoints. Once the policy is in place, PowerShell refuses to load any script, module, or configuration file that lacks a valid digital signature from a publisher in the endpoint's trust store. Interactively-allowed scripts still require a signature. The AllSigned state has no Bypass exit.

The Worklet runs the same effect that Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy AllSigned produces, but it does so through Group Policy registry values so the setting survives user overrides. The remediation script writes ExecutionPolicy = AllSigned (String) and EnableScripts = 1 (DWord) under HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell. That hive takes precedence over per-user policy and over the legacy ShellIds value at HKLM:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell ExecutionPolicy.

Before flipping the policy, the Worklet validates that the trust chain is in place. It downloads the Automox code-signing certificate and the organization-specific code-signing certificate from the Automox API, then installs them into the LocalMachine Root and TrustedPublisher stores using the .NET X509Store API. The certificate install is the prerequisite that makes AllSigned safe to enable. Without those trust anchors, every Automox PowerShell Worklet would fail signature validation on the next run.

Why enforce signed-only PowerShell execution

PowerShell is the dominant living-off-the-land binary on Windows. MITRE ATT&CK technique T1059.001 (Command and Scripting Interpreter: PowerShell) is one of the most frequently observed execution techniques in threat actor campaigns. Attackers prefer PowerShell over dropped binaries because it runs in-memory, inherits a trusted process tree, and lets unsigned .ps1 payloads execute the same way an admin one-liner does. AllSigned breaks that primitive at the loader. Unsigned scripts fail before the first cmdlet evaluates, which neutralizes most PowerShell-based lateral movement, persistence, and data exfiltration tooling delivered through phishing or post-exploitation channels. CIS Benchmark control 18.10.86.1 and NIST 800-53 SI-7 both name signed-script enforcement as a hardening requirement on managed Windows endpoints.

Once an organization commits to AllSigned, the operational problem is reaching every Windows endpoint with both the policy registry values and the code-signing trust anchors that AllSigned depends on. Scheduling this Worklet against the Windows estate writes ExecutionPolicy = AllSigned and EnableScripts = 1 under HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell and installs the Automox and organization code-signing certificates into the LocalMachine Root and TrustedPublisher stores in the same evaluation cycle. A workstation that has been off the corporate network for a quarter picks up the policy and the certificate trust chain on its next agent check-in, instead of waiting for the next time it joins the domain and pulls a GPO.

How AllSigned policy enforcement works

1. Evaluation phase: The Worklet pulls the current Automox and organization code-signing certificate authorities from the Automox API and compares their thumbprints against certificates already present in Cert:\LocalMachine\Root and Cert:\LocalMachine\TrustedPublisher. It then reads HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell and confirms ExecutionPolicy = AllSigned and EnableScripts = 1. If any certificate is missing or the registry value is not AllSigned, the endpoint is flagged non-compliant and remediation is scheduled. The check inspects the policy hive directly rather than calling Get-ExecutionPolicy. Get-ExecutionPolicy can return AllSigned from a transient process-scoped override even when the machine policy is set to something else.

2. Remediation phase: The Worklet downloads any missing certificate from the Automox signing API and installs it into the correct LocalMachine store using the .NET X509Store API. It then creates HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell if absent, writes ExecutionPolicy = AllSigned (String) and EnableScripts = 1 (DWord), and completes with exit 0. A REVERT parameter is available in both scripts. Uncommenting it removes the policy values and returns the endpoint to its inherited default, which is useful for piloting before a fleet-wide rollout.

PowerShell hardening requirements

• Windows 10, Windows 11, or Windows Server 2016 and later with PowerShell 5.1 or PowerShell 7 installed

• Automox agent running with SYSTEM-level permissions (the default Worklet context)

• Automox code-signing certificate authority obtained through the Automox code-signing opt-in process

• Organization-specific code-signing certificate provisioned by Automox and reachable through the signing API

• Outbound HTTPS reachability to console.automox.com so the endpoint can download the current certificate set

• All in-house and vendor PowerShell scripts on the endpoint must be signed by a trusted publisher; pilot the policy on a non-production group before fleet rollout, or set the REVERT parameter to roll back

Expected PowerShell state after enforcement

After a successful run, Get-ExecutionPolicy -List reports AllSigned for the MachinePolicy scope on the endpoint, and that value overrides any UserPolicy, Process, CurrentUser, or LocalMachine scope underneath it. Unsigned scripts fail at load time with the UnauthorizedAccess error; signed scripts from publishers in the TrustedPublisher store load without an interactive prompt. Individual cmdlets typed at an interactive console are unaffected by AllSigned; the policy applies to .ps1 script files and dot-sourced modules.

Validate the policy with three checks. First, run Get-ExecutionPolicy -List in an elevated PowerShell session and confirm MachinePolicy reads AllSigned. Second, inspect the registry with Get-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell and confirm ExecutionPolicy is the string AllSigned and EnableScripts is the DWord 1. Third, drop a one-line unsigned .ps1 file on the desktop and run it; it should fail with PSSecurityException: AuthorizationManager check failed. If you need to back the policy out, set the REVERT parameter in both evaluation and remediation and run the Worklet again. The registry values are cleared so PowerShell falls back to its inherited execution policy.