Windows - Security - Set PowerShell ExecutionPolicy to RemoteSigned

What the PowerShell RemoteSigned policy Worklet does

This Automox Worklet™ enforces the RemoteSigned execution policy on Windows endpoints at the LocalMachine scope and installs the code-signing certificates the policy depends on. The Worklet writes the ExecutionPolicy value and the EnableScripts flag directly to HKLM:\Software\Policies\Microsoft\Windows\PowerShell using the .NET RegistryKey API, which sets the machine-level policy without calling Set-ExecutionPolicy and without requiring PowerShell's execution policy to already permit script execution.

Before writing the registry values, the Worklet validates that both the Automox root certificate and your organization's code-signing certificate are present in the LocalMachine Root and TrustedPublisher stores using the .NET X509Store API. Missing certificates are pulled from the Automox signing API, decoded from base64 into X509Certificate2 objects, and installed into both the Root and TrustedPublisher stores. The result is an endpoint that recognizes Automox-signed and organization-signed PowerShell scripts as trusted while refusing unsigned remote scripts.

The policy is enforced through the registry rather than through Set-ExecutionPolicy directly, because the registry value at HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ExecutionPolicy takes precedence over per-user settings and cannot be overridden by a non-admin user running Set-ExecutionPolicy in their own session. Locally authored scripts continue to run without interruption, so internal automation, login scripts, and admin one-offs are unaffected.

Why harden PowerShell against unsigned remote scripts

PowerShell is the lateral-movement weapon of choice for nearly every commodity malware family and ransomware operator on Windows. The default Restricted policy stops nothing useful, because attackers routinely bypass it with -ExecutionPolicy Bypass at the command line. The RemoteSigned policy enforced through HKLM closes that loophole at the host: any script tagged with the Zone.Identifier alternate data stream from a network source must carry a valid Authenticode signature chained to a trusted publisher, or it refuses to load. CIS Microsoft Windows 10 Benchmark control 18.9.95.2 and NIST 800-53 SI-7 both call for this enforcement, and most internal hardening baselines treat it as a tier-one PowerShell control.

Reaching every Windows endpoint with both the RemoteSigned policy value and the supporting code-signing trust chain is the operational half of the control. Scheduling this Worklet against the Windows estate writes ExecutionPolicy = RemoteSigned under HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell and installs the required Authenticode certificates into the LocalMachine Root and TrustedPublisher stores in the same evaluation cycle. Every enrolled endpoint - domain-joined or standalone - receives the same registry write on the next Automox agent check-in, with no dependency on Group Policy infrastructure. Recurring evaluation catches any endpoint where a hardening baseline reset or sysprep cycle reverts the value to Restricted.

How RemoteSigned enforcement works

1. Evaluation phase: The Worklet reads the Automox and organization UUIDs from the agent config at amagent\config.json, then queries the Automox signing API for both CURRENT and FUTURE certificate statuses tied to each UUID. It opens the LocalMachine Root and TrustedPublisher certificate stores via the .NET X509Store API and confirms each required certificate is present by thumbprint. Finally it opens HKLM:\Software\Policies\Microsoft\Windows\PowerShell via the .NET RegistryKey API and verifies EnableScripts is a DWord of 1 and ExecutionPolicy is the string RemoteSigned. Any missing certificate, missing registry subkey, or wrong value flags the endpoint as non-compliant and exits non-zero.

2. Remediation phase: For each missing certificate, the Worklet pulls the base64 payload from the Automox API, decodes it into an X509Certificate2 object, and writes it into both Cert:\LocalMachine\Root and Cert:\LocalMachine\TrustedPublisher using the .NET X509Store API. It creates the HKLM:\Software\Policies\Microsoft\Windows\PowerShell subkey if absent via RegistryKey.CreateSubKey(), then writes EnableScripts to 1 and ExecutionPolicy to RemoteSigned using RegistryKey.SetValue(). Existing values that differ from the desired state are deleted and rewritten to ensure the correct registry type is set.

PowerShell RemoteSigned policy requirements

• Windows 10, Windows 11, or any supported Windows Server release with PowerShell 5.1 or later

• Automox agent installed and registered with a valid organization UUID resolvable in amagent\config.json

• Outbound HTTPS reachability to console.automox.com so the certificate fetch can complete

• Local administrative context (the Automox agent runs as SYSTEM by default, which satisfies registry HKLM and certificate store write access)

• Optional: to roll the policy back, uncomment the $REVERT parameter in both evaluation.ps1 and remediation.ps1 and set it to $true; the remediation will then remove the ExecutionPolicy value and let PowerShell fall back to its default scope chain

• Coexistence: if an existing Group Policy already enforces a stricter execution policy (AllSigned or Restricted), GPO will win at refresh time; resolve the conflict in your policy tooling before scheduling this Worklet

Expected PowerShell execution state after enforcement

After this Worklet runs, Get-ExecutionPolicy -List reports MachinePolicy as RemoteSigned and the registry at HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ExecutionPolicy holds the literal string RemoteSigned. Locally authored .ps1 files execute without prompts. Scripts tagged with the Mark-of-the-Web from an internet download or a network share refuse to run unless they carry a valid Authenticode signature chained to the Automox root or to your organization's code-signing CA.

Validate by saving a one-line unsigned script (Write-Host hello) to %TEMP% and running it directly with powershell.exe -File. It should execute, because the file was created locally. Then download the same script through a browser or copy it from a UNC share and run it again; PowerShell will refuse with an error indicating the file is not digitally signed and cannot be loaded, which is the expected RemoteSigned response for an unsigned remote file. Run Get-AuthenticodeSignature against a signed Automox script and confirm the status reads Valid with the signer matching the Automox code-signing certificate. The control persists across reboots and PowerShell version upgrades, and a recurring Worklet keeps the registry pinned if an admin clears it locally.