AllSigned is a PowerShell execution policy that allows only scripts and configuration files signed by a trusted publisher to run. It is stronger than RemoteSigned because it enforces signature checks for all scripts, not just remote ones. It is best suited to environments with mature code-signing and release governance.
Expanded Definition
AllSigned is a PowerShell execution policy that treats script trust as a verification problem, not just a file-origin problem. Every script and configuration file must carry a valid digital signature from a publisher trusted by the local policy, which makes it materially stricter than RemoteSigned. In NHI and IAM operations, that matters because many administrative workflows rely on scripts to automate access reviews, secret rotation, certificate handling, and environment changes. If those scripts are unsigned or signed by an untrusted publisher, execution fails before the code can run.
Definitions vary across vendors about whether execution policy should be treated as a security boundary or as a safety control, but Microsoft positions it as an enforcement mechanism that reduces accidental execution of untrusted content. For broader governance, the policy is best understood alongside code-signing, change approval, and publisher trust management rather than as a standalone control. The NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control context most teams use when mapping script integrity to formal access and change safeguards. The most common misapplication is assuming AllSigned protects against malicious logic in a trusted publisher’s script, which occurs when signature validation is confused with content review.
Examples and Use Cases
Implementing AllSigned rigorously often introduces release friction, requiring organisations to weigh operational speed against stronger provenance checks for administrative automation.
- PowerShell modules that provision service accounts are signed before deployment so only approved automation can create or modify NHI records.
- Incident-response scripts that rotate API keys are blocked unless the security team’s signing certificate is trusted on the host.
- Configuration scripts for privileged endpoints are distributed through a release pipeline that stamps signatures after peer review.
- Break-glass remediation scripts are pre-signed so they can run during an outage without weakening the execution policy.
For NHI governance context, the Ultimate Guide to NHIs is useful because it frames how automation, rotation, and lifecycle discipline intersect with script-based administration. In regulated environments, teams also align script trust with the same change-control expectations reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where privileged automation touches secrets or identity stores.
Why It Matters in NHI Security
AllSigned matters because NHI compromise often begins with automation that no one reviewed closely enough. If a script can modify service accounts, export tokens, or adjust certificate stores, then unsigned or tampered code becomes a direct path to identity abuse. This is especially relevant where administrative PowerShell is used to manage secrets, rotate credentials, or remediate access drift. In those cases, signature enforcement creates a gate that forces publisher trust into the workflow instead of leaving it implicit.
NHIMG research shows that 30.9% of organisations store long-term credentials directly in code, and 71% of NHIs are not rotated within recommended time frames, which helps explain why script integrity matters so much in practice. When identity operations are embedded in scripts, a compromised script can scale harm across many accounts faster than a human operator can respond. The distinction between signed and trusted is therefore operational, not cosmetic. Organisations typically encounter the consequences only after a malicious or altered script has already touched identity infrastructure, at which point AllSigned 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 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Signed automation reduces secret exposure and integrity risk in NHI workflows. |
| NIST CSF 2.0 | PR.AC-3 | Execution trust supports controlled access to privileged administrative actions. |
Require signed scripts for identity automation and review publisher trust before execution.