Description: Added in Windows 10, version 1607. Specifies whether or not the user can interact with Cortana using speech while the system is locked. If you allow or don’t configure this setting, the user can interact with Cortana using speech while the system is locked. If you block this setting, the system will need to be unlocked for the user to interact with Cortana using speech.

Why It's Important: Allowing Cortana to respond while the device is locked could expose sensitive information or allow unintended interactions—especially in shared or public environments. Blocking this feature ensures that voice commands and personal data are only accessible after the user unlocks the device. SHIELD enables this policy to reduce the risk of unauthorized access and protect user privacy. It’s like requiring someone to unlock the door before asking questions—keeping conversations secure and personal.

Learn More

Description: Specifies whether to allow toast notifications above the device lock screen. Most restrictive value is "Block".

Why It's Important: Toast notifications can display sensitive information—like email previews, calendar events, or messages—even when the device is locked. This creates a risk of exposing private data to anyone who can see the screen, especially in shared or public environments. SHIELD enables this policy to prevent data leakage and enforce the principle of least functionality. By blocking toast notifications above the lock screen, it ensures that sensitive alerts are only visible after proper authentication. It’s like keeping personal messages off a public bulletin board—secure, discreet, and privacy-focused.

Learn More

Description: This policy setting allows you to control whether a user can change the time before a password is required when a Connected Standby device screen turns off. If you enable this policy setting, a user on a Connected Standby device can change the amount of time after the device's screen turns off before a password is required when waking the device. The time is limited by any EAS settings or Group Policies that affect the maximum idle time before a device locks. Additionally, if a password is required when a screensaver turns on, the screensaver timeout will limit the options the user may choose. If you disable this policy setting, a user cannot change the amount of time after the device's screen turns off before a password is required when waking the device. Instead, a password is required immediately after the screen turns off. If you don't configure this policy setting on a domain-joined device, a user cannot change the amount of time after the device's screen turns off before a password is required when waking the device. Instead, a password is required immediately after the screen turns off. If you don't configure this policy setting on a workgroup device, a user on a Connected Standby device can change the amount of time after the device's screen turns off before a password is required when waking the device. The time is limited by any EAS settings or Group Policies that affect the maximum idle time before a device locks. Additionally, if a password is required when a screensaver turns on, the screensaver timeout will limit the options the user may choose.

Why It's Important: This policy is like automatically locking a door the moment it closes, without letting anyone delay it. By disabling user control over password timing, SHIELD ensures that devices are secured immediately when they enter standby. It prevents unauthorized access during idle periods and enforces consistent security behavior across all managed systems, especially in environments where data protection is critical.

Learn More

Description: This policy setting manages whether or not Windows is allowed to use standby states when putting the computer in a sleep state. If you enable or do not configure this policy setting, Windows uses standby states to put the computer in a sleep state. If you disable this policy setting, standby states (S1-S3) are not allowed.

Why It's Important: This policy is like choosing to fully lock down a system when it’s running on battery, rather than leaving parts of it lightly powered. By disabling standby states, SHIELD reduces the risk of sensitive data remaining in memory while the device is asleep. It helps protect against cold boot attacks and other threats that target residual data in RAM. This is especially important for mobile devices that may be more exposed to physical access risks when not plugged in.

Learn More

Description: This policy setting manages whether or not Windows is allowed to use standby states when putting the computer in a sleep state. If you enable or do not configure this policy setting, Windows uses standby states to put the computer in a sleep state. If you disable this policy setting, standby states (S1-S3) are not allowed.

Why It's Important: This policy is like choosing to fully shut down a system even when it’s plugged in, rather than leaving parts of it lightly powered. By disabling standby states, SHIELD helps prevent sensitive data from remaining in memory while the device is idle. It reduces the risk of cold boot attacks and other threats that target residual data in RAM. This is especially important for systems that handle sensitive information and must maintain strict security even when not actively in use.

Learn More

Description: This policy setting specifies whether or not the user is prompted for a password when the system resumes from sleep. If you enable or do not configure this policy setting, the user is prompted for a password when the system resumes from sleep. If you disable this policy setting, the user is not prompted for a password when the system resumes from sleep.

Why It's Important: This policy is like requiring a key to unlock your device after it’s been asleep. By prompting for a password when waking from sleep, SHIELD ensures that unattended devices remain secure, even if someone tries to access them while they’re idle. It protects sensitive data from unauthorized access and reinforces good security hygiene, especially for laptops and mobile devices that are more likely to be used in public or shared spaces.

Learn More

Description: This policy setting specifies whether or not the user is prompted for a password when the system resumes from sleep. If you enable or do not configure this policy setting, the user is prompted for a password when the system resumes from sleep. If you disable this policy setting, the user is not prompted for a password when the system resumes from sleep.

Why It's Important: This policy is like locking your screen even when your device is charging. By requiring a password when waking from sleep, SHIELD ensures that unattended systems remain secure, even in office or shared environments. It prevents unauthorized access to sensitive data and reinforces consistent security practices across all devices, whether mobile or stationary.

Learn More

Description: This policy setting controls whether a device will automatically sign in and lock the last interactive user after the system restarts or after a shutdown and cold boot. This only occurs if the last interactive user didn’t sign out before the restart or shutdown. If the device is joined to Active Directory or Azure Active Directory, this policy only applies to Windows Update restarts. Otherwise, this will apply to both Windows Update restarts and user-initiated restarts and shutdowns. If you don’t configure this policy setting, it is enabled by default. When the policy is enabled, the user is automatically signed in and the session is automatically locked with all lock screen apps configured for that user after the device boots. After enabling this policy, you can configure its settings through the ConfigAutomaticRestartSignOn policy, which configures the mode of automatically signing in and locking the last interactive user after a restart or cold boot. If you disable this policy setting, the device does not configure automatic sign in. The user’s lock screen apps are not restarted after the system restarts.

Why It's Important: Logging when a script starts and stops helps track how long commands run and when they were executed. It adds important timing details to PowerShell logs, which helps with auditing, troubleshooting, and detecting unusual behavior. SHIELD enables this policy to give security teams better visibility into PowerShell activity. It’s like marking the start and end of every task in a logbook—clear, traceable, and useful for investigations.

Learn More

Description: This policy setting enables logging of all PowerShell script input to the Microsoft-Windows-PowerShell/Operational event log. If you enable this policy setting, Windows PowerShell will log the processing of commands, script blocks, functions, and scripts - whether invoked interactively, or through automation. If you disable this policy setting, logging of PowerShell script input is disabled. If you enable the Script Block Invocation Logging, PowerShell additionally logs events when invocation of a command, script block, function, or script starts or stops. Enabling Invocation Logging generates a high volume of event logs. Note: This policy setting exists under both Computer Configuration and User Configuration in the Group Policy Editor. The Computer Configuration policy setting takes precedence over the User Configuration policy setting.

Why It's Important: This policy setting enables logging of all PowerShell script input to the Microsoft-Windows-PowerShell/Operational event log. If you enable this policy setting, Windows PowerShell will log the processing of commands, script blocks, functions, and scripts - whether invoked interactively, or through automation. If you disable this policy setting, logging of PowerShell script input is disabled. If you enable the Script Block Invocation Logging, PowerShell additionally logs events when invocation of a command, script block, function, or script starts or stops. Enabling Invocation Logging generates a high volume of event logs. Note: This policy setting exists under both Computer Configuration and User Configuration in the Group Policy Editor. The Computer Configuration policy setting takes precedence over the User Configuration policy setting.

Learn More

Description: Logging when a script starts and stops helps track how long commands run and when they were executed. It adds important timing details to PowerShell logs, which helps with auditing, troubleshooting, and detecting unusual behavior. SHIELD enables this policy to give security teams better visibility into PowerShell activity. It’s like marking the start and end of every task in a logbook—clear, traceable, and useful for investigations.

Why It's Important: [coming soon]

Learn More

Description: This policy setting decides if hibernate on the machine is allowed or not. Supported values: 0 – Disable hibernate. 1 (default) - Allow hibernate.

Why It's Important: While hibernate can be convenient, it also stores sensitive data—including memory contents—to disk, which can be a security risk if the device is lost or compromised. SHIELD blocks hibernate to prevent unauthorized access to saved sessions and reduce the risk of data leakage—like locking a secure room but leaving the blueprints on the table. This policy ensures that devices shut down cleanly and securely, maintaining the integrity of enterprise systems.

Learn More

Description: Enabling this policy hides "Hibernate" from appearing in the power button in the start menu.

Why It's Important: This policy hides the Hibernate option from the Start menu and power options. Disabling Hibernate reduces potential issues with memory persistence and helps ensure that devices fully shut down when not in use. It's important for environments where encryption, secure boot, or sensitive session data protection is required.

Learn More

Description: This policy setting allows you to hide the Switch User interface in the Logon UI, the Start menu and the Task Manager. If you enable this policy setting, the Switch User interface is hidden from the user who is attempting to log on or is logged on to the computer that has this policy applied. The locations that Switch User interface appear are in the Logon UI, the Start menu and the Task Manager. If you disable or do not configure this policy setting, the Switch User interface is accessible to the user in the three locations.

Why It's Important: This policy hides the Fast User Switching option to prevent multiple users from maintaining simultaneous active sessions on the same device. Disabling this feature helps reduce memory and resource use, prevents potential session hijacking, and ensures proper logoff behavior on shared or privileged systems.

Learn More

Description: This policy setting allows you to control whether users see the first sign-in animation when signing in to the computer for the first time. This applies to both the first user of the computer who completes the initial setup and users who are added to the computer later. It also controls if Microsoft account users will be offered the opt-in prompt for services during their first sign-in. If you enable this policy setting, Microsoft account users will see the opt-in prompt for services, and users with other accounts will see the sign-in animation. If you disable this policy setting, users will not see the animation and Microsoft account users will not see the opt-in prompt for services. If you do not configure this policy setting, the user who completes the initial Windows setup will see the animation during their first sign-in. If the first user had already completed the initial setup and this policy setting is not configured, users new to this computer will not see the animation. Note: The first sign-in animation will not be shown on Server, so this policy will have no effect.

Why It's Important: is policy disables the first logon animation and Microsoft account service prompts during initial sign-in. Turning off the animation streamlines user onboarding, reduces setup time, and eliminates consumer-oriented prompts that are unnecessary or undesirable in enterprise or managed deployments.

Learn More