PowerShell 7 is the modern, cross-platform edition of PowerShell built on .NET Core. It runs on Windows, macOS, Linux, and containers, and it adds performance, parallel execution, and broader module compatibility for administrative automation and configuration management.
Expanded Definition
PowerShell 7 is the current cross-platform branch of PowerShell used to automate administration, configuration, and orchestration across Windows, Linux, macOS, and containerised environments. In NHI and IAM operations, it matters because it often executes with service account privileges, stored credentials, API tokens, or delegated access to infrastructure and cloud services. That means a script interpreter becomes part of the identity attack surface, not just a productivity tool.
PowerShell 7 differs from older Windows PowerShell in runtime, compatibility, and portability. The modern execution model improves performance and supports parallelism, but it also widens the places where scripts, modules, and secrets can be embedded or copied. Guidance varies across vendors on how to classify PowerShell-based automation, but in NHI governance it is best treated as privileged automation that must follow least privilege, logging, and secret handling controls. For a broader governance lens, NHI Management Group’s Ultimate Guide to NHIs is a useful reference point, and the NIST Cybersecurity Framework 2.0 provides a control-oriented way to think about protecting automated access. The most common misapplication is assuming PowerShell scripts are harmless because they are “just admin code,” which occurs when privileged commands run with unattended credentials and no inventory or review.
Examples and Use Cases
Implementing PowerShell 7 rigorously often introduces operational friction, requiring teams to weigh fast automation and portability against tighter controls on execution, signing, and secret use.
- Infrastructure teams use PowerShell 7 to provision cloud resources, but must ensure the script runner uses short-lived credentials rather than embedded API keys.
- Security teams run audit scripts across hybrid estates to enumerate service accounts and detect stale privilege assignments, then map findings to Ultimate Guide to NHIs guidance on visibility and lifecycle management.
- DevOps pipelines call PowerShell 7 modules for deployment tasks, and those modules should be treated as software supply chain assets with version control, review, and dependency checks.
- Incident responders use PowerShell 7 to collect artefacts from endpoints and servers, but logging and command-line transcription become essential when the tool itself can be abused for lateral movement.
- Administrators automate Windows and Linux configuration from one codebase, aligning the workflow with NIST Cybersecurity Framework 2.0 practices for asset, access, and audit governance.
In practice, the same script that speeds up provisioning can also replicate privilege at scale if its token handling, module sourcing, or execution policy is weakly controlled.
Why It Matters in NHI Security
PowerShell 7 matters because it is frequently the execution layer where non-human identities become operationally active. When a service account, managed identity, or API credential is consumed by a script, the security problem shifts from “who owns the identity” to “what can the automation do, where, and under what logging constraints.” That is why PowerShell 7 should be governed as a privileged automation platform, not merely an administrative shell. The attack surface expands when scripts are copied into CI/CD jobs, run from shared jump hosts, or invoke modules that store secrets in plain text.
NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which makes scripted automation especially hard to govern at scale. That visibility gap is compounded when PowerShell 7 is used across mixed operating systems without consistent logging, rotation, and owner assignment. The issue is not just access, but persistence: if a script keeps working after the responsible team changes or a credential should be revoked, the identity outlives its intended purpose. Organisations typically encounter uncontrolled PowerShell 7 exposure only after a script-based privilege escalation, at which point the automation chain 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret handling and exposure risks common in scripted automation. |
| OWASP Agentic AI Top 10 | A-03 | Automation execution with tool access overlaps with agentic command authority risks. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and permission management apply directly to PowerShell-run identities. |
| NIST SP 800-63 | AAL2 | Credential assurance concepts inform how scripted admin access should be protected. |
| NIST Zero Trust (SP 800-207) | SC-4 | Zero Trust requires each automated session to be explicitly authenticated and authorised. |
Inventory PowerShell secrets, remove hard-coded credentials, and enforce vault-backed retrieval.
Related resources from NHI Mgmt Group
- What breaks when PowerShell and BITSAdmin are allowed to run unchecked on user endpoints?
- What breaks when users are allowed to execute PowerShell from untrusted prompts?
- How should security teams detect ClickFix-style PowerShell abuse in practice?
- What do teams get wrong about PowerShell-based malware campaigns?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
