RemoteSigned is a PowerShell execution policy that requires scripts downloaded from the internet to be signed by a trusted publisher, while locally created scripts may run unsigned. It balances usability and control for mixed environments. Teams use it to reduce risk from external content without blocking every internal automation workflow.
Expanded Definition
RemoteSigned is a PowerShell execution policy that distinguishes between local scripts and scripts obtained from remote sources. In practice, it allows unsigned scripts created on a workstation to run, but requires a trusted signature when a script is downloaded from the internet or delivered from another untrusted location. That makes it a control on script provenance rather than a full security boundary. It is commonly used in environments that need to preserve internal automation while reducing the chance that externally sourced code is executed without review.
Definitions vary across vendors and administration guides on how much protection execution policy provides, but the operational meaning in Windows PowerShell is consistent: it helps enforce trust on remote content while leaving room for legitimate local development. For governance purposes, it should be treated as one layer among code signing, software restriction, and endpoint hardening, not as a substitute for broader application control. The most common misapplication is treating RemoteSigned as a malware prevention mechanism, which occurs when teams assume execution policy alone will stop risky scripts from running.
Examples and Use Cases
Implementing RemoteSigned rigorously often introduces workflow friction for administrators who distribute scripts across mixed trust zones, requiring organisations to weigh developer convenience against provenance control.
- Help desk automation scripts run locally on managed endpoints without forcing every internal helper script to be signed.
- Downloaded admin tooling from a vendor portal is blocked until it is signed by a trusted publisher and reviewed.
- Security teams use it to reduce casual execution of internet-sourced PowerShell during incident response preparation.
- In a compromise scenario, a downloaded script with no signature check is less likely to be executed automatically on a hardened workstation.
- Policy tuning is often paired with enterprise guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls to align script execution expectations with broader control objectives.
For NHI-adjacent operations, the control matters when automation scripts interact with secrets, tokens, or service credentials. A script that is unsigned locally may still be acceptable in a controlled build pipeline, but any script pulled from a remote share or download should be evaluated more carefully before it can touch non-human identities. NHIMG’s analysis of the Schneider Electric credentials breach underscores how quickly trusted automation paths can become exposure paths when execution and credential handling are not tightly governed.
Why It Matters in NHI Security
RemoteSigned matters because non-human identities often depend on scripts for provisioning, rotation, validation, and decommissioning. If script trust is not controlled, those workflows can become an entry point for credential theft, unauthorized automation, or persistence. In NHI programs, a script is rarely just code. It is frequently the mechanism that creates, moves, or revokes access for service accounts, API keys, and certificates. When that mechanism is loosely governed, the blast radius expands from one workstation to an entire identity lifecycle.
NHIMG reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. Those conditions make script provenance especially important because a remotely sourced PowerShell file can become the path from harmless execution to high-impact identity abuse. RemoteSigned does not solve secret sprawl, but it can reduce the odds that externally delivered automation runs without scrutiny. Organisations typically encounter the operational need for this control only after a suspicious script executes or a service account is abused, at which point script policy becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Script provenance helps prevent misuse of credentials and tokens in NHI automation. |
| NIST CSF 2.0 | PR.AC-3 | Execution trust for scripts supports controlled access and authorized system use. |
| NIST SP 800-63 | Digital identity assurance informs how automation scripts should be trusted and governed. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires verifying code and execution context before granting action. | |
| NIST AI RMF | Risk management applies when AI or automation scripts can alter identity operations. |
Approve script execution paths so only trusted automation can reach sensitive systems.
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org