pwsh is the command used to start PowerShell 7 and later from the command line. It launches the cross-platform PowerShell shell and scripting environment, where administrators run cmdlets, scripts and automation tasks on Windows, Linux and macOS.
What pwsh is and what it does
pwsh is the executable that starts PowerShell 7 and later. It opens a cross-platform shell and scripting environment used to run cmdlets, scripts and automation tasks across Windows, Linux and macOS. Because it is a general-purpose administrative entry point, the command is often the first step before higher-trust operations begin.
In practice, pwsh is not just a convenience alias. It is the runtime boundary where a user moves from an interactive terminal into a programmable management environment, which means its availability, invocation context and execution policy all matter to security teams as much as to system administrators.
Why pwsh matters in administration and automation
PowerShell 7 is widely used for system administration, orchestration, cloud operations and repeatable automation because it combines an interactive shell with scripting and object-based command pipelines. That makes pwsh especially useful for tasks that need consistency, remote execution or integration with other tooling.
Its value also creates operational dependency. If teams standardise on pwsh for provisioning, remediation or configuration work, then outages, version drift or restricted access to the executable can interrupt routine operations. In mature environments, the command becomes part of the control plane for day-to-day administration.
Security implications of the PowerShell 7 runtime
Because pwsh can execute arbitrary scripts and commands, it is a high-value administrative interface. The same flexibility that helps automation also gives defenders and attackers a powerful runtime for live-off-the-land activity, so its usage should be visible, authorised and consistent with least-privilege expectations.
The main security concern is not the command itself but what it can do once launched: read and transform data, call local or remote interfaces, invoke APIs, alter system state and chain into other tools. That makes script provenance, module trust and execution context important to monitor whenever PowerShell is used in production environments.
Operational boundaries and platform behaviour
pwsh is cross-platform, which is useful for portability but also means teams should not assume Windows-only controls or habits will fully transfer. Differences in pathing, file permissions, package sources and shell integration can change how scripts behave and how securely they are deployed.
Administrators should treat pwsh as part of the operating environment, not just an application. Standardising approved versions, documenting where it may run and understanding which accounts are permitted to invoke it helps reduce ambiguity in both troubleshooting and incident response. Where PowerShell is used for automation, the command should be managed as a governed execution surface rather than an ad hoc utility.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | pwsh workflows often depend on managed credentials and secrets. |
| AC-6 — Least Privilege | pwsh is commonly used for administration and should run with limited authority. | |
| Recommendation — Manage credentials used with pwsh automation so privileged command execution stays controlled. Limit pwsh execution privileges to the minimum access needed for each task. | ||
| CIS Controls v8 | CIS-5 — Account Management | pwsh is frequently invoked by administrative accounts and service accounts. |
| Recommendation — Review and restrict accounts that can launch pwsh in production environments. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Enforcement | pwsh usage in admin automation depends on controlled authentication and access enforcement. |
| Recommendation — Enforce strong authentication and access controls around pwsh-based administration. | ||
| MITRE ATT&CK | T1059.001 — PowerShell | pwsh is the PowerShell execution environment used in adversary command execution. |
| Recommendation — Detect and investigate suspicious PowerShell command execution and script activity. | ||
Practitioner Guidance
Why practitioners should care: pwsh often sits at the centre of administrative automation, so weak controls around it can quickly turn routine scripting into broad system-level exposure. The practical question is not whether to use PowerShell 7, but how to make its use observable and bounded.
What to watch for: unexpected interactive use on servers, unusual script launch paths, and automation that runs under over-broad accounts or from untrusted locations are common warning signs. If pwsh is part of a privileged workflow, its execution should be aligned with the same governance applied to other administrative tooling.
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org