PowerShell security features
PowerShell has several features designed to improve the security of your scripting environment.
PowerShell's execution policy is a safety feature that controls the conditions under which PowerShell loads configuration files and runs scripts. This feature helps prevent the execution of malicious scripts. You can use a Group Policy setting to set execution policies for computers and users. Execution policies only apply to the Windows platform.
For more information see about_Execution_Policies.
Module and script block logging
Module Logging allows you to enable logging for selected PowerShell modules. This setting is effective in all sessions on the computer. Pipeline execution events for the specified modules are recorded in the Windows PowerShell log in Event Viewer.
Script Block Logging enables logging for the processing of commands, script blocks, functions, and scripts - whether invoked interactively, or through automation. This information is logged to the Microsoft-Windows-PowerShell/Operational event log.
For more information, see the following articles:
The Windows Antimalware Scan Interface (AMSI) is an API that allows application actions to be passed to an antimalware scanner, such as Windows Defender, to be scanned for malicious payloads. Beginning with PowerShell 5.1, PowerShell running on Windows 10 (and higher) passes all script blocks to AMSI.
PowerShell 7.3 extends the data that's sent to AMSI for inspection. It now includes all invocations of .NET method members.
For more information about AMSI, see How AMSI helps.
Constrained language mode
ConstrainedLanguage mode protects your system by limiting the cmdlets and .NET types that can be used in a PowerShell session. For a full description, see about_Language_Modes.
Windows 10 includes two technologies, Windows Defender Application Control (WDAC) and AppLocker that you can use to control applications. They allow you to create a lockdown experience to help secure your PowerShell environment.
For more information about how PowerShell supports AppLocker and WDAC, see Using Windows Defender Application Control.
Changes in PowerShell 7.4
On Windows, when PowerShell runs under a Windows Defender Application Control (WDAC) policy, it changes its behavior based on the defined security policy. Under a WDAC policy, PowerShell runs trusted scripts and modules allowed by the policy in Full Language mode. All other scripts and script blocks are untrusted and run in Constrained Language mode. PowerShell throws errors when the untrusted scripts attempt to perform disallowed actions. It's difficult to know why a script fails to run correctly in Constrained Language mode.
PowerShell 7.4 now supports WDAC policies in Audit mode. In audit mode, PowerShell runs the untrusted scripts in Constrained Language mode but logs messages to the event log instead of throwing errors. The log messages describe what restrictions would apply if the policy was in Enforce mode.
Changes in PowerShell 7.3
- PowerShell 7.3 now supports the ability to block or allow PowerShell script files via the WDAC API.
Changes in PowerShell 7.2
There was a corner-case scenario in AppLocker where you only have Deny rules and constrained mode isn't used to enforce the policy that allows you to bypass the execution policy. Beginning in PowerShell 7.2, a change was made to ensure AppLocker rules take precedence over a
Set-ExecutionPolicy -ExecutionPolicy Bypasscommand.
PowerShell 7.2 now disallows the use of the
Add-Typecmdlet in a NoLanguage mode PowerShell session on a locked down machine.
PowerShell 7.2 now disallows scripts from using COM objects in AppLocker system lock down conditions. Cmdlet that use COM or DCOM internally aren't affected.
Security Servicing Criteria
PowerShell follows the Microsoft Security Servicing Criteria for Windows. The table below outlines the features that meet the servicing criteria and those that do not.
|System Lockdown - with WDAC||Security Feature|
|Constrained language mode - with WDAC||Security Feature|
|System Lockdown - with AppLocker||Defense in Depth|
|Constrained language mode - with AppLocker||Defense in Depth|
|Execution Policy||Defense in Depth|
Software Bill of Materials (SBOM)
Beginning with PowerShell 7.2, all install packages contain a Software Bill of Materials (SBOM). The
SBOM is found at
$PSHOME/_manifest/spdx_2.2/manifest.spdx.json. The creation and publishing of the
SBOM is the first step to modernize Federal Government cybersecurity and enhance software supply
The PowerShell team is also producing SBOMs for modules that they own but ship separately from
PowerShell. SBOMs will be added in the next release of the module. For modules, the SBOM is
installed in the module's folder under
For more information about this initiative, see the blog post Generating Software Bills of Materials (SBOMs) with SPDX at Microsoft.