Description: When you enable this setting, planned password expiration longer than password age dictated by "Password Settings" policy is NOT allowed. When such expiration is detected, password is changed immediately and password expiration is set according to policy. When you disable or not configure this setting, password expiration time may be longer than required by "Password Settings" policy.

Why It's Important: This setting helps keep devices secure by making sure that admin passwords don’t stay active longer than allowed. If a password is supposed to expire after a certain number of days, this policy forces it to follow that rule—even if something tries to extend it. It’s like setting a firm deadline for changing the password, which helps prevent old or potentially compromised passwords from sticking around too long and becoming a security risk.

Learn More

Description: Enables management of password for local administrator account If you enable this setting, local administrator password is managed If you disable or not configure this setting, local administrator password is not managed.

Why It's Important: This setting makes sure that the password for the built-in admin account on every device is regularly updated and securely stored, instead of being left the same or manually managed. It helps prevent unauthorized access by rotating passwords automatically and keeping them out of reach from users or attackers. Think of it like having a smart lock that changes its code regularly and only trusted IT systems know the new code—keeping devices safer without needing manual effort.

Learn More

Description: Configures password parameters Password complexity: which characters are used when generating a new password Default: Large letters + small letters + numbers + special characters Password length Minimum: 8 characters Maximum: 64 characters Default: 14 characters Password age in days Minimum: 1 day Maximum: 365 days Default: 30 days.

Why It's Important: This policy makes sure that passwords used by local admin accounts are strong and regularly updated. It prevents weak passwords like “admin123” and ensures that passwords include a mix of letters, numbers, and symbols, making them harder to guess. It also sets a time limit so passwords don’t stay the same forever, reducing the risk of someone gaining long-term access. Overall, it helps keep devices secure by enforcing smart password habits automatically.

Learn More

Description: Remote host allows delegation of non-exportable credentials When using credential delegation, devices provide an exportable version of credentials to the remote host. This exposes users to the risk of credential theft from attackers on the remote host. If you enable this policy setting, the host supports Restricted Admin or Remote Credential Guard mode. If you disable or do not configure this policy setting, Restricted Administration and Remote Credential Guard mode are not supported. User will always need to pass their credentials to the host.

Why It's Important: This setting helps protect user credentials when connecting to another computer using Remote Desktop. Normally, credentials are sent to the remote machine, which could be risky if that machine is compromised. By enabling this policy, the system uses secure methods that don't send actual credentials—making it much harder for attackers to steal them. It’s like letting someone borrow your identity for a task without ever giving them your actual ID card.

Learn More

Description: This policy setting determines whether a user will be prompted on the client computer to provide credentials for a remote connection to an RD Session Host server. If you enable this policy setting, a user will be prompted on the client computer instead of on the RD Session Host server to provide credentials for a remote connection to an RD Session Host server. If saved credentials for the user are available on the client computer, the user will not be prompted to provide credentials. Note: If you enable this policy setting in releases of Windows Server 2008 R2 with SP1 or Windows Server 2008 R2, and a user is prompted on both the client computer and on the RD Session Host server to provide credentials, clear the Always prompt for password check box on the Log on Settings tab in Remote Desktop Session Host Configuration. If you disable or do not configure this policy setting, the version of the operating system on the RD Session Host server will determine when a user is prompted to provide credentials for a remote connection to an RD Session Host server. For Windows Server 2003 and Windows 2000 Server a user will be prompted on the terminal server to provide credentials for a remote connection. For Windows Server 2008 and Windows Server 2008 R2, a user will be prompted on the client computer to provide credentials for a remote connection.

Why It's Important: This setting improves security by making sure users prove who they are before the remote connection even starts. Instead of waiting until they’re connected to the remote system, they’re asked to log in right away on their own device. It’s like checking someone’s ID before they enter a building, rather than after they’re already inside—helping prevent unauthorized access and making the login process more secure and consistent.

Learn More

Description: This security setting determines whether the local Administrator account is enabled or disabled. Notes If you try to reenable the Administrator account after it has been disabled, and if the current Administrator password does not meet the password requirements, you cannot reenable the account. In this case, an alternative member of the Administrators group must reset the password on the Administrator account. For information about how to reset a password, see To reset a password. Disabling the Administrator account can become a maintenance issue under certain circumstances. Under Safe Mode boot, the disabled Administrator account will only be enabled if the machine is non-domain joined and there are no other local active administrator accounts. If the computer is domain joined the disabled administrator will not be enabled. Default: Disabled.

Why It's Important: Disabling the default Administrator account helps reduce the risk of unauthorized access. This account is well-known and often targeted by attackers because it has full control over the system. If left enabled and not properly secured, it can become a major vulnerability. By disabling it, you force users to rely on named accounts with more traceable activity and better access control. It’s like locking away a master key that’s too powerful to leave lying around.

Learn More

Description: User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode This policy setting controls the behavior of the elevation prompt for administrators. The options are:

Why It's Important: This setting adds an extra layer of protection by making sure that when an admin tries to do something important, they must clearly approve it—and it happens in a secure environment that malware or other apps can’t mess with. It helps prevent accidental changes and stops malicious software from silently making system-level changes. Think of it like a locked door that only opens when the admin says “yes,” and no one else can sneak in while it’s happening.

Learn More

Description: User Account Control: Use Admin Approval Mode for the built-in Administrator account This policy setting controls the behavior of Admin Approval Mode for the built-in Administrator account. The options are:

Why It's Important: This setting adds a safety check for the built-in Administrator account, which normally has full access to everything. By enabling Admin Approval Mode, we make sure that even this powerful account has to confirm before making big changes—like installing software or changing system settings. It helps prevent mistakes and blocks malware from silently using admin powers, making the system more secure without removing control from IT.

Learn More

Description: Encryption Oracle Remediation This policy setting applies to applications using the CredSSP component (for example: Remote Desktop Connection). Some versions of the CredSSP protocol are vulnerable to an encryption oracle attack against the client. This policy controls compatibility with vulnerable clients and servers. This policy allows you to set the level of protection desired for the encryption oracle vulnerability. If you enable this policy setting, CredSSP version support will be selected based on the following options: Force Updated Clients: Client applications which use CredSSP will not be able to fall back to the insecure versions and services using CredSSP will not accept unpatched clients. Note: this setting should not be deployed until all remote hosts support the newest version. Mitigated: Client applications which use CredSSP will not be able to fall back to the insecure version but services using CredSSP will accept unpatched clients. See the link below for important information about the risk posed by remaining unpatched clients. Vulnerable: Client applications which use CredSSP will expose the remote servers to attacks by supporting fall back to the insecure versions and services using CredSSP will accept unpatched clients. For more information about the vulnerability and servicing requirements for protection.

Why It's Important: This policy is like requiring secure ID badges for remote access. By enforcing updated CredSSP versions, SHIELD ensures that remote desktop connections are protected from known vulnerabilities. It prevents attackers from exploiting weak encryption during authentication and helps maintain secure communication between clients and servers. Choosing the right level of enforcement balances compatibility with security, but the safest option is to block outdated and vulnerable connections entirely.

Learn More

Description: Remote host allows delegation of non-exportable credentials When using credential delegation, devices provide an exportable version of credentials to the remote host. This exposes users to the risk of credential theft from attackers on the remote host. If you enable this policy setting, the host supports Restricted Admin or Remote Credential Guard mode. If you disable or do not configure this policy setting, Restricted Administration and Remote Credential Guard mode are not supported. User will always need to pass their credentials to the host.

Why It's Important: This policy is like letting someone verify your identity without handing over your ID. By enabling support for non-exportable credential delegation, SHIELD ensures that sensitive login information isn’t exposed to remote systems. It protects users from credential theft, especially in environments where remote access is common. This is a key safeguard for maintaining secure authentication practices across enterprise networks.

Learn More

Description: This policy setting allows you to manage whether the Windows Remote Management (WinRM) service will not allow RunAs credentials to be stored for any plug-ins. If you enable this policy setting, the WinRM service will not allow the RunAsUser or RunAsPassword configuration values to be set for any plug-ins. If a plug-in has already set the RunAsUser and RunAsPassword configuration values, the RunAsPassword configuration value will be erased from the credential store on this computer. If you disable or do not configure this policy setting, the WinRM service will allow the RunAsUser and RunAsPassword configuration values to be set for plug-ins and the RunAsPassword value will be stored securely. If you enable and then disable this policy setting,any values that were previously configured for RunAsPassword will need to be reset.

Why It's Important: [coming soon]

Learn More

Description: This policy setting controls whether administrator accounts are displayed when a user attempts to elevate a running application. By default, administrator accounts are not displayed when the user attempts to elevate a running application. If you enable this policy setting, all local administrator accounts on the PC will be displayed so the user can choose one and enter the correct password. If you disable this policy setting, users will always be required to type a user name and password to elevate.

Why It's Important: Disabling this policy helps keep administrator account names hidden, which reduces the risk of targeted attacks like brute-force or credential guessing. It also makes elevation a more deliberate action, requiring users to know and enter credentials manually. SHIELD enforces this policy to protect privileged access and minimize exposure in shared or multi-user environments. It’s like removing name tags from a secure door—only those who know the right credentials can get through.

Learn More

Description: This policy setting determines whether a user will be prompted on the client computer to provide credentials for a remote connection to an RD Session Host server. If you enable this policy setting, a user will be prompted on the client computer instead of on the RD Session Host server to provide credentials for a remote connection to an RD Session Host server. If saved credentials for the user are available on the client computer, the user will not be prompted to provide credentials. Note: If you enable this policy setting in releases of Windows Server 2008 R2 with SP1 or Windows Server 2008 R2, and a user is prompted on both the client computer and on the RD Session Host server to provide credentials, clear the Always prompt for password check box on the Log on Settings tab in Remote Desktop Session Host Configuration. If you disable or do not configure this policy setting, the version of the operating system on the RD Session Host server will determine when a user is prompted to provide credentials for a remote connection to an RD Session Host server. For Windows Server 2003 and Windows 2000 Server a user will be prompted on the terminal server to provide credentials for a remote connection. For Windows Server 2008 and Windows Server 2008 R2, a user will be prompted on the client computer to provide credentials for a remote connection.

Why It's Important: Prompting for credentials on the client side helps keep login information secure. It reduces the risk of credentials being intercepted on the remote host and supports a consistent, secure authentication flow. SHIELD enables this policy to make sure credentials are handled in a trusted context. It’s like asking for ID before you leave home, not after you arrive—safer, more predictable, and easier to manage.

Learn More

Description: This policy setting prevents users from adding new Microsoft accounts on this computer. If you select the "Users can’t add Microsoft accounts" option, users will not be able to create new Microsoft accounts on this computer, switch a local account to a Microsoft account, or connect a domain account to a Microsoft account. This is the preferred option if you need to limit the use of Microsoft accounts in your enterprise. If you select the "Users can’t add or log on with Microsoft accounts" option, existing Microsoft account users will not be able to log on to Windows. Selecting this option might make it impossible for an existing administrator on this computer to log on and manage the system. If you disable or do not configure this policy (recommended), users will be able to use Microsoft accounts with Windows.

Why It's Important: Microsoft accounts are designed for personal use and can bypass enterprise identity controls, leading to potential data leakage, unauthorized cloud sync, or policy conflicts. SHIELD enforces this policy to ensure that only corporate-managed identities are used on enterprise devices—like requiring employees to use company-issued badges instead of personal IDs to access secure areas. This helps maintain centralized control, enforce compliance, and prevent mixing of personal and business data.

Learn More

Description: This security setting determines whether the local Administrator account is enabled or disabled. Note if you try to reenable the Administrator account after it has been disabled, and if the current Administrator password does not meet the password requirements, you cannot reenable the account. In this case, an alternative member of the Administrators group must reset the password on the Administrator account. Disabling the Administrator account can become a maintenance issue under certain circumstances. Under Safe Mode boot, the disabled Administrator account will only be enabled if the machine is non-domain joined and there are no other local active administrator accounts. If the computer is domain joined the disabled administrator will not be enabled. Default: Disabled.

Why It's Important: The built-in Administrator account is a common target for attackers because it has elevated privileges and is often left enabled by default. Disabling it reduces the risk of unauthorized access, especially in cases where credentials are compromised or brute-force attacks are attempted. SHIELD enforces this policy to eliminate a high-risk entry point and ensure that administrative access is granted only through managed, auditable accounts. It’s like locking away a master key that’s too powerful to leave lying around—security improves when access is tightly controlled.

Learn More

Description: This security setting determines if the Guest account is enabled or disabled. Default: Disabled. Note: If the Guest account is disabled and the security option Network Access: Sharing and Security Model for local accounts is set to Guest Only, network logons, such as those performed by the Microsoft Network Server (SMB Service), will fail.

Why It's Important: Guest accounts provide minimal security and are often used without passwords, making them a common target for unauthorized access. SHIELD disables this account to eliminate a low-security entry point and ensure that all access to enterprise systems is authenticated and traceable. It’s like removing a spare key that anyone could use—convenient, but risky. This policy helps maintain strict access control and prevents misuse of unmanaged accounts in secure environments.

Learn More

Description: Accounts Limit local account use of blank passwords to console logon only This security setting determines whether local accounts that are not password protected can be used to log on from locations other than the physical computer console. If enabled, local accounts that are not password protected will only be able to log on at the computer's keyboard. Default: Enabled.

Why It's Important: Blank passwords are a major security risk, especially when remote access is possible. This policy ensures that any local account without a password cannot be used to log in remotely—helping prevent unauthorized access over the network. SHIELD enforces this to reduce the attack surface and protect systems from simple but dangerous intrusion methods. It’s like allowing access to a building only through a guarded front door, not through unsecured back entrances. This policy reinforces password hygiene and protects against opportunistic attacks on poorly secured endpoints.

Learn More

Description: Devices: Prevent users from installing printer drivers when connecting to shared printers. For a computer to print to a shared printer, the driver for that shared printer must be installed on the local computer. This security setting determines who is allowed to install a printer driver as part of connecting to a shared printer. If this setting is enabled, only Administrators can install a printer driver as part of connecting to a shared printer. If this setting is disabled, any user can install a printer driver as part of connecting to a shared printer. Default on servers: Enabled. Default on workstations: Disabled Note this setting does not affect the ability to add a local printer. This setting does not affect Administrators.

Why It's Important: Printer drivers can be exploited to introduce vulnerabilities or malicious code into a system. Allowing users to install drivers—especially from shared or unknown sources—can bypass security controls and introduce risk. SHIELD enforces this policy to ensure that only trusted administrators can install drivers, reducing the chance of driver-based attacks. It’s like requiring a certified technician to install hardware in a secure facility—no unauthorized parts, no surprises. This policy helps maintain control over device configurations and protects against potential exploits hidden in printer software.

Learn More

Description: Interactive logon: Machine inactivity limit. Windows notices inactivity of a logon session, and if the amount of inactive time exceeds the inactivity limit, then the screen saver will run, locking the session. Default: not enforced.

Why It's Important: Automatically locking a device after a period of inactivity helps prevent unauthorized access when a user steps away. It ensures that sensitive data and systems aren’t left exposed on an unattended screen. SHIELD enforces this policy to reduce the risk of physical access breaches—like locking a door when no one’s in the room. It’s a simple but effective way to maintain security hygiene and protect enterprise assets from casual snooping or malicious activity.

Learn More

Description: Interactive logon: Smart card removal behavior This security setting determines what happens when the smart card for a logged-on user is removed from the smart card reader. The options are: No Action Lock Workstation Force Logoff Disconnect if a Remote Desktop Services session If you click Lock Workstation in the Properties dialog box for this policy, the workstation is locked when the smart card is removed, allowing users to leave the area, take their smart card with them, and still maintain a protected session. If you click Force Logoff in the Properties dialog box for this policy, the user is automatically logged off when the smart card is removed. If you click Disconnect if a Remote Desktop Services session, removal of the smart card disconnects the session without logging the user off. This allows the user to insert the smart card and resume the session later, or at another smart card reader-equipped computer, without having to log on again. If the session is local, this policy functions identically to Lock Workstation.

Why It's Important: Smart cards are often used for secure authentication, and removing one during a session should immediately revoke access. SHIELD enforces Force Logoff to ensure that once the smart card is removed, the session ends completely—preventing unauthorized access or lingering sessions. It’s like pulling the key out of a secure terminal and having the system shut down access instantly. This policy helps protect sensitive data and systems from being accessed after the authorized user has left, especially in high-security environments.

Learn More

Description: Microsoft network client: Digitally sign communications (always) This security setting determines whether packet signing is required by the SMB client component. The server message block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with an SMB server is permitted. If this setting is enabled, the Microsoft network client will not communicate with a Microsoft network server unless that server agrees to perform SMB packet signing. If this policy is disabled, SMB packet signing is negotiated between the client and server. Default: Disabled. Important For this policy to take effect on computers running Windows 2000, client-side packet signing must also be enabled. To enable client-side SMB packet signing, set Microsoft network client: Digitally sign communications (if server agrees). Note all Windows operating systems support both a client-side SMB component and a server-side SMB component. On Windows 2000 and later operating systems, enabling or requiring packet signing for client and server-side SMB components is controlled by the following four policy settings:

Why It's Important: Unsigned SMB traffic is vulnerable to tampering and interception, especially in environments where sensitive data is shared across the network. By enforcing digital signing, SHIELD ensures that all SMB communications are authenticated and protected from manipulation—like sealing every envelope with a tamper-proof stamp before sending it through the mail. This policy helps safeguard file transfers, remote management sessions, and other network operations from unauthorized interference.

Learn More

Description: Microsoft network client: Send unencrypted password to connect to third-party SMB servers If this security setting is enabled, the Server Message Block (SMB) redirector is allowed to send plaintext passwords to non-Microsoft SMB servers that do not support password encryption during authentication. Sending unencrypted passwords is a security risk. Default: Disabled.

Why It's Important: Sending passwords in plaintext is a serious security risk—it’s like shouting your password across a crowded room. If intercepted, these credentials can be used to gain unauthorized access to systems and data. SHIELD disables this behavior to ensure that all authentication is encrypted and secure, even when connecting to non-Microsoft SMB servers. This policy helps prevent credential theft and enforces strong security standards across all network interactions.

Learn More

Description: Microsoft network server: Digitally sign communications (always) This security setting determines whether packet signing is required by the SMB server component. The server message block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with an SMB client is permitted. If this setting is enabled, the Microsoft network server will not communicate with a Microsoft network client unless that client agrees to perform SMB packet signing. If this setting is disabled, SMB packet signing is negotiated between the client and server. Default: Disabled for member servers. Enabled for domain controllers. Note all Windows operating systems support both a client-side SMB component and a server-side SMB component. On Windows 2000 and later, enabling or requiring packet signing for client and server-side SMB components is controlled by the following four policy settings:

By default, server-side SMB signing is enabled only on domain controllers. If server-side SMB signing is enabled, SMB packet signing will be negotiated with clients that have client-side SMB signing enabled. SMB packet signing can significantly degrade SMB performance, depending on dialect version, OS version, file sizes, processor offloading capabilities, and application IO behaviors. Important For this policy to take effect on computers running Windows 2000, server-side packet signing must also be enabled. To enable server-side SMB packet signing, set the following policy: Microsoft network server: Digitally sign communications (if server agrees) For Windows 2000 servers to negotiate signing with Windows NT 4.0 clients, the following registry value must be set to 1 on the Windows 2000 server: HKLM\System\CurrentControlSet\Services\lanmanserver\parameters\enableW9xsecuritysignature.

Why It's Important: Unsigned SMB traffic is vulnerable to tampering and interception, especially in environments where sensitive data is shared across the network. By enforcing digital signing, SHIELD ensures that all SMB communications are authenticated and protected from manipulation—like requiring a verified seal on every package before it’s accepted into a secure facility. This policy helps safeguard file transfers, remote management sessions, and other network operations from unauthorized interference, ensuring data integrity and trust between systems.

Learn More

Description: Network access: Do not allow anonymous enumeration of SAM accounts This security setting determines what additional permissions will be granted for anonymous connections to the computer. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. This security option allows additional restrictions to be placed on anonymous connections as follows: Enabled: Do not allow enumeration of SAM accounts. This option replaces Everyone with Authenticated Users in the security permissions for resources. Disabled: No additional restrictions. Rely on default permissions. Default on workstations: Enabled. Default on server:Enabled.

Why It's Important: Allowing anonymous users to list account names can expose valuable information to attackers, helping them identify targets for brute-force or phishing attacks. SHIELD enforces this policy to prevent unauthorized discovery of user accounts—like removing name tags from a secure facility to keep identities private. This helps reduce the risk of reconnaissance-based attacks and strengthens identity protection across enterprise systems.

Learn More

Description: Network access: Do not allow anonymous enumeration of SAM accounts and shares This security setting determines whether anonymous enumeration of SAM accounts and shares is allowed. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. If you do not want to allow anonymous enumeration of SAM accounts and shares, then enable this policy. Default: Disabled.

Why It's Important: Allowing anonymous enumeration of accounts and shares gives attackers a map of potential targets and resources—making it easier to plan and execute attacks. SHIELD enforces this policy to shut down that visibility, ensuring only authenticated users can query system accounts or shared folders. It’s like keeping your building directory and storage room list behind a locked door—only trusted personnel should know what’s inside. This policy helps prevent reconnaissance and strengthens the overall security posture of enterprise systems.

Learn More

Description: Network access: Restrict anonymous access to Named Pipes and Shares When enabled, this security setting restricts anonymous access to shares and pipes to the settings for: Network access: Named pipes that can be accessed anonymously Network access: Shares that can be accessed anonymously Default: Enabled.

Why It's Important: Named pipes and shared folders are common communication channels in Windows systems. If left open to anonymous access, they can be exploited to gather information or launch attacks without authentication. SHIELD enforces this policy to ensure that only authenticated users can access these resources—like requiring ID badges to enter secure areas instead of leaving doors unlocked. This helps prevent unauthorized access, data leakage, and lateral movement within the network.

Learn More

Description: Network access: Restrict clients allowed to make remote calls to SAM. This policy setting allows you to restrict remote rpc connections to SAM. If not selected, the default security descriptor will be used. This policy is supported on at least Windows Server 2016.

Why It's Important: Allowing unrestricted remote access to SAM can expose sensitive account data and increase the risk of privilege escalation or identity-based attacks. SHIELD enforces this policy to tightly control who can access account information remotely—like limiting access to a personnel file room to only HR managers. This helps prevent unauthorized queries, protects identity data, and reinforces least-privilege principles across the network.

Learn More

Description: Network security: Allow PKU2U authentication requests to this computer to use online identities. This policy will be turned off by default on domain joined machines. This would prevent online identities from authenticating to the domain joined machine.

Why It's Important: PKU2U authentication is designed for peer-to-peer scenarios and online identity use, which are not appropriate in tightly controlled enterprise environments. Allowing it could enable external or unmanaged identities to interact with domain-joined systems, potentially bypassing corporate identity protections. SHIELD blocks this to ensure that only trusted, domain-managed identities are used—like requiring company-issued credentials to access secure systems, not personal logins. This policy helps prevent unauthorized access and enforces strict identity boundaries.

Learn More

Description: Network security: Do not store LAN Manager hash value on next password change This security setting determines if, at the next password change, the LAN Manager (LM) hash value for the new password is stored. The LM hash is relatively weak and prone to attack, as compared with the cryptographically stronger Windows NT hash. Since the LM hash is stored on the local computer in the security database the passwords can be compromised if the security database is attacked. Default on Windows Vista and above: Enabled Default on Windows XP: Disabled. Important Windows 2000 Service Pack 2 (SP2) and above offer compatibility with authentication to previous versions of Windows, such as Microsoft Windows NT 4.0. This setting can affect the ability of computers running Windows 2000 Server, Windows 2000 Professional, Windows XP, and the Windows Server 2003 family to communicate with computers running Windows 95 and Windows 98.

Why It's Important: Hashes are easily cracked and represent a significant security risk if stored on a system. SHIELD enforces this policy to ensure that only strong, modern password hashes are used—like upgrading from a flimsy padlock to a high-security vault lock. By eliminating LM hashes, this policy helps protect credentials from being compromised in the event of a system breach or offline attack on the password database.

Learn More

Description: Network security LAN Manager authentication level This security setting determines which challenge/response authentication protocol is used for network logons. This choice affects the level of authentication protocol used by clients, the level of session security negotiated, and the level of authentication accepted by servers as follows:

Why It's Important: Legacy authentication protocols like LM and NTLM are outdated and insecure, making them easy targets for attackers. SHIELD enforces the use of NTLMv2 only to ensure that all authentication is performed using modern, cryptographically secure methods—like upgrading from a flimsy lock to a biometric scanner. This policy helps protect credentials during network logons and prevents attackers from exploiting weak authentication mechanisms.

Learn More

Description: Minimum session security for NTLM SSP based (including secure RPC) clients This security setting allows a client to require the negotiation of 128-bit encryption and/or NTLMv2 session security. These values are dependent on the LAN Manager Authentication Level security setting value. The options are:

Default: Windows XP, Windows Vista, Windows 2000 Server, Windows Server 2003, and Windows Server 2008: No requirements. Windows 7 and Windows Server 2008 R2: Require 128-bit encryption.

Why It's Important: Weak encryption and outdated authentication protocols leave systems vulnerable to interception and tampering. By requiring NTLM and 128-bit encryption, SHIELD ensures that all client communications are protected with strong cryptographic standards—like insisting on armored vehicles for transporting sensitive documents. This policy helps prevent data leaks, man-in-the-middle attacks, and unauthorized access during network sessions.

Learn More

Description: Network security: Minimum session security for NTLM SSP based (including secure RPC) servers This security setting allows a server to require the negotiation of 128-bit encryption and/or NTLMv2 session security. These values are dependent on the LAN Manager Authentication Level security setting value. The options are: Require NTLMv2 session security: The connection will fail if message integrity is not negotiated. Require 128-bit encryption. The connection will fail if strong encryption (128-bit) is not negotiated. Default: Windows XP, Windows Vista, Windows 2000 Server, Windows Server 2003, and Windows Server 2008: No requirements. Windows 7 and Windows Server 2008 R2: Require 128-bit encryption.

Why It's Important: Weak encryption and outdated authentication protocols expose servers to data interception and manipulation. By requiring NTLM and 128-bit encryption, SHIELD ensures that all server-side communications are protected with strong cryptographic standards—like requiring secure tunnels for sensitive conversations. This policy helps prevent man-in-the-middle attacks, ensures message integrity, and enforces a high standard of security for all incoming connections.

Learn More

Description: Network security: Restrict NTLM: Incoming NTLM traffic This policy setting allows you to deny or allow incoming NTLM traffic. If you select "Allow all" or do not configure this policy setting, the server will allow all NTLM authentication requests. If you select "Deny all domain accounts," the server will deny NTLM authentication requests for domain logon and display an NTLM blocked error, but allow local account logon. If you select "Deny all accounts," the server will deny NTLM authentication requests from incoming traffic and display an NTLM blocked error. This policy is supported on at least Windows 7 or Windows Server 2008 R2. Note: Block events are recorded on this computer in the "Operational" Log located under the Applications and Services Log/Microsoft/Windows/NTLM.

Why It's Important: NTLM is an outdated authentication protocol that lacks modern security protections and is vulnerable to replay and relay attacks. By denying all incoming NTLM traffic, SHIELD ensures that only secure, modern authentication methods like Kerberos are used—like refusing to accept handwritten notes in a digital security system. This policy helps eliminate legacy protocol risks and enforces a stronger, more resilient authentication posture across enterprise systems.

Learn More

Description: User Account Control: Behavior of the elevation prompt for standard users This policy setting controls the behavior of the elevation prompt for standard users. The options are:

Why It's Important: Allowing standard users to elevate privileges—even with a prompt—can lead to accidental or intentional misuse of administrative functions. SHIELD enforces automatic denial to prevent privilege escalation and reduce help desk calls from users attempting actions they shouldn’t. It’s like preventing guests from entering restricted areas in a secure building—no exceptions, no confusion. This policy helps maintain strict role-based access control and ensures that only authorized personnel can perform sensitive operations.

Learn More

Description: User Account Control: Detect application installations and prompt for elevation This policy setting controls the behavior of application installation detection for the computer. The options are:

Why It's Important: Application installations often require elevated privileges, which can be exploited to introduce malicious software or make unauthorized system changes. SHIELD enforces this policy to ensure that installation attempts are flagged and require explicit approval—like requiring a supervisor’s sign-off before installing new equipment in a secure facility. This helps prevent unauthorized software from being installed and maintains control over what runs on enterprise devices.

Learn More

Description: User Account Control: Only elevate executable files that are signed and validated This policy setting enforces public key infrastructure (PKI) signature checks for any interactive applications that request elevation of privilege. Enterprise administrators can control which applications are allowed to run by adding certificates to the Trusted Publishers certificate store on local computers. The options are:

Why It's Important: Unsigned or tampered executables can be used to escalate privileges and compromise a system. By requiring digital signatures, SHIELD ensures that only verified, trusted applications can run with elevated permissions—like allowing only certified contractors to access secure areas. This policy helps prevent malware from gaining administrative access and reinforces the integrity of privileged operations across enterprise devices.

Learn More

Description: This policy setting controls whether applications that request to run with a User Interface Accessibility (UIAccess) integrity level must reside in a secure location in the file system. Secure locations are limited to the following:

Why It's Important: UIAccess applications can interact with other apps and simulate user input, which makes them a potential target for abuse. SHIELD enforces this policy to ensure that only trusted, properly installed applications can request elevated UI interaction—like allowing only certified tools to operate inside a secure control room. This prevents malicious software from gaining elevated access through insecure paths and helps maintain the integrity of user interactions and system controls.

Learn More

Description: User Account Control: Turn on Admin Approval Mode This policy setting controls the behavior of all User Account Control (UAC) policy settings for the computer. If you change this policy setting, you must restart your computer. The options are:

Why It's Important: Running administrators in Admin Approval Mode adds an extra layer of protection by requiring confirmation before executing privileged actions. SHIELD enforces this to prevent malware or unauthorized scripts from silently gaining elevated access—like requiring a second key to open a secure vault, even if you’re the manager. This policy helps reduce the risk of privilege abuse and ensures that all elevated actions are deliberate and traceable.

Learn More

Description: User Account Control: Switch to the secure desktop when prompting for elevation This policy setting controls whether the elevation request prompt is displayed on the interactive user's desktop or the secure desktop. The options are:

Why It's Important: Displaying elevation prompts on the secure desktop protects users from malicious software that might try to mimic or hijack the prompt to gain elevated access. SHIELD enforces this policy to ensure that privilege escalation requests are handled in a secure, tamper-proof environment—like moving sensitive conversations into a soundproof room. This helps prevent social engineering attacks and reinforces the integrity of administrative actions.

Learn More

Description: User Account Control: Virtualize file and registry write failures to per-user locations This policy setting controls whether application write failures are redirected to defined registry and file system locations. This policy setting mitigates applications that run as administrator and write run-time application data to %ProgramFiles%, %Windir%, %Windir%\system32, or HKLM\Software. The options are:

Why It's Important: Some older applications attempt to write data to system-level locations that are protected in modern Windows environments. Without virtualization, these apps would fail unless run with elevated privileges—posing a security risk. SHIELD enables this policy to allow such applications to run safely in a user context, redirecting their writes to secure, user-specific areas. It’s like giving each employee a personal drawer instead of letting them store files in the company vault. This maintains compatibility while preserving system integrity and minimizing unnecessary privilege escalation.

Learn More

Description: When you enable this setting, planned password expiration longer than password age dictated by "Password Settings" policy is not allowed. When such expiration is detected, password is changed immediately and password expiration is set according to policy. When you disable or not configure this setting, password expiration time may be longer than required by "Password Settings" policy.

Why It's Important: This policy ensures that the expiration time for local administrator passwords managed by LAPS cannot exceed the limit defined in the organization’s password age policy. Enforcing this prevents stale credentials, ensures regular password rotation, and maintains alignment with enterprise security compliance requirements.

Learn More

Description: Enables management of password for local administrator account If you enable this setting, local administrator password is managed If you disable or not configure this setting, local administrator password is not managed.

Why It's Important: This policy activates Windows LAPS to automatically manage the local administrator account password. It helps prevent credential reuse across devices, mitigates lateral movement attacks, and ensures every managed endpoint maintains a unique, securely stored administrator password.

Learn More

Description: Configures password parameters Password complexity: which characters are used when generating a new password Default: Large letters + small letters + numbers + special characters Password length Minimum: 8 characters Maximum: 64 characters Default: 14 characters Password age in days Minimum: 1 day Maximum: 365 days Default: 30 days.

Why It's Important: This policy enables centralized management of password parameters for accounts managed by Windows LAPS. It ensures local administrator passwords are strong, complex, and rotated regularly. improving protection against credential theft and reuse attacks. By enforcing length, complexity, and rotation frequency, it helps maintain compliance with enterprise security standards.

Learn More

Description: This policy setting controls the behavior of the elevation prompt for administrators. The options are:

Why It's Important: This policy enforces that administrators must enter their credentials on the secure desktop whenever elevated privileges are required. It helps protect against malware or unauthorized programs attempting to spoof elevation prompts by ensuring that all elevation requests occur in an isolated, secure interface controlled by Windows.

Learn More

Description: This policy setting controls the behavior of Admin Approval Mode for the built-in Administrator account. The options are:

Why It's Important: This policy requires the built-in Administrator account to operate in Admin Approval Mode, where elevation requests must be explicitly approved before executing privileged actions. Enabling it prevents automatic privilege escalation and ensures all administrative operations require confirmation, reducing the risk of unauthorized system changes or malware executing with full rights.

Learn More

Description: [coming soon]

Why It's Important: [coming soon]

Learn More

Description: [coming soon]

Why It's Important: [coming soon]

Learn More