PowerShell cmdlets are lightweight commands built into PowerShell for administering systems, querying data and automating tasks. They follow a verb-noun naming pattern, can be piped together and often expose structured parameters, objects and output for scripting and remote management.
What PowerShell cmdlets are built for
PowerShell cmdlets are the built-in, lightweight commands that make PowerShell useful for system administration and automation. Their design encourages consistent, scriptable administration because they return objects rather than plain text, which makes it easier to inspect, filter, transform and pass results between commands in a controlled way.
That object-based model is what separates cmdlets from many traditional shell commands. It lets administrators work with structured data, repeat tasks reliably and build remote management workflows that are easier to standardise across systems and teams.
How cmdlets are named and used
Cmdlets usually follow a verb-noun pattern such as Get-Process or Set-Item, which helps users infer what a command does before they run it. The naming convention also improves discoverability in large environments, where hundreds of commands may be available through PowerShell modules and platform extensions.
Cmdlets are designed to be composable. Output from one command can be piped into another, so an administrator can query, sort, select or modify objects without converting them into brittle text strings. In practice, that makes them a core building block for repeatable administration and orchestration.
Why cmdlets matter in automation and remote management
Cmdlets are central to PowerShell's value in enterprise operations because they provide a common interface for local tasks, remote sessions and scripted administration. They often expose parameters that support filtering, targeting and precise control, which reduces manual error and makes routine administration faster to automate.
They also sit close to high-trust operational functions. Cmdlets can query services, manage configuration, change accounts, alter permissions, inspect logs and invoke remote actions, so they are often used in privileged workflows. That makes them operationally powerful, but it also means the commands should be governed with the same care as other administrative interfaces.
How cmdlets differ from functions, scripts and aliases
Cmdlets are compiled commands provided by PowerShell or by modules, whereas functions and scripts are typically authored by users to extend behaviour. Aliases are only shortcuts to existing commands and do not provide new capability on their own. Understanding the difference matters because cmdlets usually expose richer metadata, parameter binding and object semantics than ad hoc shell wrappers.
This distinction matters for maintainability. A script may combine many cmdlets to create a workflow, but the cmdlets themselves remain the reusable atomic operations that other tooling can inspect, document and automate against. That is why cmdlets are often the preferred interface for administration at scale.
Risk and Threat Considerations
PowerShell cmdlets are attractive to attackers because they are native, powerful and often already trusted by defenders. The same features that make them useful for administration, especially automation and remote execution, can also be abused for reconnaissance, persistence, privilege abuse and living-off-the-land activity.
Failure mechanism: If organisations allow broad PowerShell use without script controls, logging and execution governance, cmdlets can become a low-friction path for misuse of legitimate administrative capability. Attackers may blend malicious activity into ordinary admin workflows, making detection harder than with custom malware alone.
Impact: Misused cmdlets can expose sensitive systems, configuration data, credentials and remote management pathways, and they can accelerate lateral movement once an initial foothold exists. Monitoring command usage, restricting unnecessary privilege and reviewing high-risk admin activity are therefore important defensive measures.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Cmdlet activity should be logged because it can change systems and access paths. |
| AC-6 — Least Privilege | Cmdlets often run in privileged contexts and should be limited to necessary rights. | |
| Recommendation — Log privileged PowerShell cmdlet use and review it for suspicious administration patterns. Constrain PowerShell execution rights to the minimum needed for each administrative role. | ||
| MITRE ATT&CK | T1059.001 — PowerShell | PowerShell is a recognised command-and-script execution technique used in attacks. |
| Recommendation — Map suspicious PowerShell usage to ATT&CK and hunt for malicious command execution paths. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Cmdlet abuse is best detected with strong logging and review of administrative actions. |
| CIS-6 — Access Control Management | Cmdlets often administer privileged resources and need tight access control. | |
| Recommendation — Centralise and review PowerShell-related logs to detect unusual administrative activity. Restrict who can run administrative PowerShell actions and validate privilege assignments. | ||
Practitioner Guidance
Why practitioners should care: Treat cmdlets as part of your operational control surface, not just as a convenience layer. If administrators can use them to make broad changes quickly, then misuse, accidental damage and excessive privilege can all scale just as quickly.
What to watch for: Pay attention to unusual command patterns, unexpected remote execution, and administrative scripts that rely on broad permissions rather than narrowly scoped task-specific access. Standardising approved cmdlets and reviewing how they are used in privileged workflows helps reduce both drift and abuse.
Practitioner takeaway: The safest PowerShell environments are not those that eliminate cmdlets, but those that combine them with tight privilege, logging and review so legitimate automation remains efficient without becoming an easy abuse path.
Related resources from NHI Mgmt Group
- How do you detect Active Directory enumeration using PowerShell cmdlets?
- How do you detect AADInternals PowerShell cmdlets targeting Microsoft Entra ID?
- How do you detect offensive PowerShell frameworks and malicious cmdlets on Windows?
- What breaks when PowerShell and BITSAdmin are allowed to run unchecked on user endpoints?
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 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org