Windows 11, version 25H2 security baseline
Microsoft is pleased to announce the security baseline package for Windows 11, version 25H2! You can download the baseline package from the Microsoft Security Compliance Toolkit, test the recommended configurations in your environment, and customize / implement them as appropriate. Summary of changes This release includes several changes made since the Windows 11, version 24H2 security baseline to further assist in the security of enterprise customers, to include better alignment with the latest capabilities and standards. The changes include what is depicted in the table below. Security Policy Change Summary Printer: Impersonate a client after authentication Add “RESTRICTED SERVICES\PrintSpoolerService” to allow the Print Spooler’s restricted service identity to impersonate clients securely NTLM Auditing Enhancements Enable by default to improve visibility into NTLM usage within your environment MDAV: Attack Surface Reduction (ASR) Add "Block process creations originating from PSExec and WMI commands" (d1e49aac-8f56-4280-b9ba-993a6d77406c) with a recommended value of 2 (Audit) to improve visibility into suspicious activity MDAV: Control whether exclusions are visible to local users Move to Not Configured as it is overridden by the parent setting MDAV: Scan packed executables Remove from the baseline because the setting is no longer functional - Windows always scans packed executables by default Network: Configure NetBIOS settings Disable NetBIOS name resolution on all network adapters to reduce legacy protocol exposure Disable Internet Explorer 11 Launch Via COM Automation Disable to prevent legacy scripts and applications from programmatically launching Internet Explorer 11 using COM automation interfaces Include command line in process creation events Enable to improve visibility into how processes are executed across the system WDigest Authentication Remove from the baseline because the setting is obsolete - WDigest is disabled by default and no longer needed in modern Windows environments Printer Improving Print Security with IPPS and Certificate Validation To enhance the security of network printing, Windows introduces two new policies focused on controlling the use of IPP (Internet Printing Protocol) printers and enforcing encrypted communications. The setting, "Require IPPS for IPP printers", (Administrative Templates\Printers) determines whether printers that do not support TLS are allowed to be installed. When this policy is disabled (default), both IPP and IPPS transport printers can be installed - although IPPS is preferred when both are available. When enabled, only IPPS printers will be installed; attempts to install non-compliant printers will fail and generate an event in the Application log, indicating that installation was blocked by policy. The second policy, "Set TLS/SSL security policy for IPP printers" (same policy path) requires that printers present valid and trusted TLS/SSL certificates before connections can be established. Enabling this policy defends against spoofed or unauthorized printers, reducing the risk of credential theft or redirection of sensitive print jobs. While these policies significantly improve security posture, enabling them may introduce operational challenges in environments where IPP and self-signed or locally issued certificates are still commonly used. For this reason, neither policy is enforced in the security baseline, at this time. We recommend that you assess your printers, and if they meet the requirements, consider enabling those policies with a remediation plan to address any non-compliant printers in a controlled and predictable manner. User Rights Assignment Update: Impersonate a client after authentication We have added RESTRICTED SERVICES\PrintSpoolerService in the “Impersonate a client after authentication” User Rights Assignment policy. The baseline already includes Administrators, SERVICE, LOCAL SERVICE, and NETWORK SERVICE for this user right. Adding the restricted Print Spooler supports Microsoft’s ongoing effort to apply least privilege to system services. It enables Print Spooler to securely impersonate user tokens in modern print scenarios using a scoped, restricted service identity. Although this identity is associated with functionality introduced as part of Windows Protected Print (WPP), it is required to support proper print operations even if WPP is not currently enabled. The system manifests the identity by default, and its presence ensures forward compatibility with WPP-based printing. Note: This account may appear as a raw SID (e.g., S-1-5-99-...) in Group Policy or local policy tools before the service is fully initialized. This is expected and does not indicate a misconfiguration. Warning: Removing this entry will result in print failures in environments where WPP is enabled. We recommend retaining this entry in any custom security configuration that defines this user right. NTLM Auditing Enhancements Windows 11, version 25H2 includes enhanced NTLM auditing capabilities, enabled by default, which significantly improves visibility into NTLM usage within your environment. These enhancements provide detailed audit logs to help security teams monitor and investigate authentication activity, identify insecure practices, and prepare for future NTLM restrictions. Since these auditing improvements are enabled by default, no additional configuration is required, and thus the baseline does not explicitly enforce them. For more details, see Overview of NTLM auditing enhancements in Windows 11 and Windows Server 2025. Microsoft Defender Antivirus Attack Surface Reduction (ASR) In this release, we've updated the Attack Surface Reduction (ASR) rules to add the policy Block process creations originating from PSExec and WMI commands (d1e49aac-8f56-4280-b9ba-993a6d77406c) with a recommended value of 2 (Audit). By auditing this rule, you can gain essential visibility into potential privilege escalation attempts via tools such as PSExec or persistence mechanisms using WMI. This enhancement helps organizations proactively identify suspicious activities without impacting legitimate administrative workflows. Control whether exclusions are visible to local users We have removed the configuration for the policy "Control whether exclusions are visible to local users" (Windows Components\Microsoft Defender Antivirus) from the baseline in this release. This change was made because the parent policy "Control whether or not exclusions are visible to Local Admins" is already set to Enabled, which takes precedence and effectively overrides the behavior of the former setting. As a result, explicitly configuring the child policy is unnecessary. You can continue to manage exclusion visibility through the parent policy, which provides the intended control over whether local administrators can view exclusion lists. Scan packed executables The “Scan packed executables” setting (Windows Components\Microsoft Defender Antivirus\Scan) has been removed from the security baseline because it is no longer functional in modern Windows releases. Microsoft Defender Antivirus always scans packed executables by default, therefore configuring this policy has no effect on the system. Disable NetBIOS Name Resolution on All Networks In this release, we start disabling NetBIOS name resolution on all network adapters in the security baseline, including those connected to private and domain networks. The change is reflected in the policy setting “Configure NetBIOS settings” (Network\DNS Client). We are trying to eliminate the legacy name resolution protocol that is vulnerable to spoofing and credential theft. NetBIOS is no longer needed in modern environments where DNS is fully deployed and supported. To mitigate potential compatibility issues, you should ensure that all internal systems and applications use DNS for name resolution. We recommend the following; test critical workflows in a staging environment prior to deployment, monitor for any resolution failures or fallback behavior, and inform support staff of the change to assist with troubleshooting as needed. This update aligns with our broader efforts to phase out legacy protocols and improve security. Disable Internet Explorer 11 Launch Via COM Automation To enhance the security posture of enterprise environments, we recommend disabling Internet Explorer 11 Launch Via COM Automation (Windows Components\Internet Explorer) to prevent legacy scripts and applications from programmatically launching Internet Explorer 11 using COM automation interfaces such as CreateObject("InternetExplorer.Application"). Allowing such behavior poses a significant risk by exposing systems to the legacy MSHTML and ActiveX components, which are vulnerable to exploitation. Include command line in process creation events We have enabled the setting "Include command line in process creation events" (System\Audit Process Creation) in the baseline to improve visibility into how processes are executed across the system. Capturing command-line arguments allows defenders to detect and investigate malicious activity that may otherwise appear legitimate, such as abuse of scripting engines, credential theft tools, or obfuscated payloads using native binaries. This setting supports modern threat detection techniques with minimal performance overhead and is highly recommended. WDigest Authentication We removed the policy "WDigest Authentication (disabling may require KB2871997)" from the security baseline because it is no longer necessary for Windows. This policy was originally enforced to prevent WDigest from storing user’s plaintext passwords in memory, which posed a serious credential theft risk. However, starting with 24H2 update, the engineering teams deprecated this policy. As a result, there is no longer a need to explicitly enforce this setting, and the policy has been removed from the baseline to reflect the current default behavior. Since the setting does not write to the normal policies location in the registry it will not be cleaned up automatically for any existing deployments. Please let us know your thoughts by commenting on this post or through the Security Baseline Community.Windows Server 2025, security baseline
Microsoft is pleased to announce the release of the security baseline package for Windows Sever 2025! Please download the content from the Microsoft Security Compliance Toolkit, test the recommended configurations, and customize / implement as appropriate. This release includes several changes to further assist in the security of enterprise customers, including changes to account lockout, Local Security Authority, LAPS, Kerberos, Microsoft Defender Antivirus, Windows Protected Print, Windows Update, and more. In an upcoming release planned for early 2025, we will include additional configuration settings to reflect the recently introduced baseline applied via OSConfig so that administrators will have more flexibility and control to fine-tune their configuration to better align with their specific security and operational needs. This enhancement aims to streamline the management process and ensure that the baseline settings are consistently applied across all systems. Although we do not have a specific date yet, users can look forward to benefiting from these improvements soon. Account lockout In this release, we have made several changes to account lockout policies that raise the security bar. Account lockout threshold: 3 attempts (previously 10 attempts). Account lockout duration: 15 minutes (remains the same). Reset account lockout counter after: 15 minutes (remains the same). Configure hash algorithms for certificate logon The policy Configure hash algorithms for certificate logon has been added for smart card crypto agility, located at System\KDC and System\Kerberos. This setting lets users configure the hash algorithm to be used in certificate-based smart card (PKINIT) authentication of Kerberos. With this configuration, customers have the option to prevent SHA-1 from being used. It’s important to note these settings are useful only if both the client and KDC (Windows Server 2025) are configured this way in the environment. Disabling SHA-1 for PKINIT is more secure for your environment. However, the authentication might fail if your domain controller does not support PKINIT SHA-2. For that reason, we leave the SHA-1 option as default in the baseline and suggest you test your own environment before making a decision. Delegated Managed Service Account (dMSA) logons The new policy Enable delegated Managed Service Account (dMSA) Logons controls dMSA logons for the machine, located at System\Kerberos. Delegated Managed Service Account (dMSA) is an Active Directory account designed for secure and efficient management of credentials, with automatic password management and device-specific access. If you enable this policy setting, dMSA logons will be supported by Kerberos client. Please review the prerequisites before adjusting the policy setting. By default, dMSA is disabled because the Domain Controller (DC) must also be upgraded to Windows Server 2025 for the feature to function properly. If the DC is running a version earlier than Windows Server 2025, the necessary schema updates for dMSA will not be present. If your DC has been upgraded to Windows Server 2025, we suggest enabling this policy on both the client and DC sides. When enabled, you may need to specify realms, i.e., which domains or parts of the directory can authenticate and access the dMSA account. A child domain on an older Windows Server version can still interact with the accounts while maintaining security boundaries. It allows for a smoother transition and coexistence of features across a mixed-version environment. For example, if you have a primary domain called corp.contoso.com running on Windows Server 2025 and an older child domain called legacy.corp.contoso.com running on an older version of Windows Server (e.g., Windows Server 2022), you may specify the realm as legacy.corp.contoso.com. To learn more, see Setting up delegated Managed Service Accounts (dMSA) in Windows Server 2025. Event Log service You can use the newly added policy Limit remote access to the Event Log Service, located at Windows Components\Event Log Service, to control which remote users will be allowed to connect to the Event Log service on the machine. This helps reduce the attack surface for an adversary to capture machine credentials when configured to limit access to Administrators on Domain Controllers and other systems where the machine credentials are trusted to remotely connect to other systems. We recommend you test everything thoroughly and provide clear guidance for users before enabling this policy to avoid compatibility risks and workflow disruption. For example, when the policy is set to limit access to Administrators, IT pros cannot view events from a machine remotely without actually logging in to that machine. This setting does not control access to individual logs. Once a remote connection is allowed, the account will still need access to the specific resources it is attempting to use. Local Administrator Password Solution (LAPS) In our ongoing effort to enhance security and streamline management for our customers, there is a series of new policies aimed at controlling Local Administrator Password Solution (LAPS). Size of Encrypted Password History allows administrators to define the number of previous encrypted passwords stored in Active Directory. By managing password history effectively, we enhance security by preventing the reuse of old passwords. Post-authentication Actions specifies the actions that should be taken after an authentication by the managed account. Administrators can choose to reset the password, log off the managed account, reboot the device, or terminate processes. A grace period can also be configured before these actions are executed, ensuring robust security measures are in place. Configure Automatic Account Management configures options for automatic account management, allowing administrators to specify the target account, whether it be the built-in admin account or a custom account. Administrators can define the name or prefix for the managed account and decide if the managed account should be enabled or disabled. Additionally, there is an option to add a random numeric suffix to the managed account name, enhancing security through complexity and uniqueness. With these new policies, we aim to provide you with more control and flexibility in managing your security settings, thereby ensuring a safer and more efficient environment. Local logon We have adjusted the configuration recommendation for the policy Allow log on locally, located under User Right Assignments in this version. For Domain Controllers (DCs), we now recommend you allow both the Administrators and Enterprise Domain Controllers groups to log on locally. We’re changing this recommendation to address an issue that arises when a component calls lsalogonuser() under the context of the machine account to update PKINIT machine credentials. LDAP server signing requirements for DC A new policy, Domain controller: LDAP server signing requirements Enforcement, has been introduced and overlaps the old one, Domain controller: LDAP server signing requirements. As a result, we’ve made an update on the baseline which is to leave the old policy as default and enforce the new one for domain controllers to ensure the capability still functions as expected to secure your environment. Local Security Authority The new policy Allow Custom SSPs and APs to be loaded into LSASS controls whether custom Security Support Providers (SSPs) and Authentication Packages (APs) are allowed to load into the Local Security Authority Subsystem Service (LSASS). In addition, you can also use the new policy, Configures LSASS to run as a protected process to control the configuration under which LSASS is run. For the most secure posture, enabling LSA protection with UEFI is the most secure option. However, locking with UEFI adds some dependencies and may cause some compatibility risks. For that reason, we highly recommend evaluating your environment carefully before enabling the policy with UEFI lock. To see more details, refer to this document. Microsoft Defender Antivirus Attack Surface Reduction (ASR) We recently added a rule specifically designed for server environments to the baseline. We strongly recommend that you thoroughly test this ASR rule in your environment before implementing it to ensure it aligns with your security needs and does not interfere with your operational processes. ASR Rule GUID Block Webshell creation for Servers a8f5898e-1dc8-49a9-9878-85004b8a61e6 We also removed certain Attack Surface Reduction (ASR) rules that are no longer applicable to the server side. These rules will now only be applicable to the client version. This adjustment ensures that our security measures are more accurately tailored to specific needs and environments. Please see those rules below. ASR Rule GUID Adobe Reader from creating child processes 7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c Block executable content from email client and webmail be9ba2d9-53ea-4cdc-84e5-9b1eeee46550 Block all Office applications from creating child processes d4f940ab-401b-4efc-aadc-ad5f3c50688a Block Office communication application from creating child processes 26190899-1602-49e8-8b27-eb1d0a1ce869 Block Office applications from creating executable content 3b576869-a4ec-4529-8536-b80a7769e899 Block Office applications from injecting code into other processes 75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84 Block Win32 API calls from Office macros 92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b Control the visibility of exclusions The settings Control whether exclusions are visible to local users and Control whether or not exclusions are visible to Local Admins in Microsoft Defender Antivirus policy determine whether local users and local administrators can view the list of configured exclusions. We recommend enabling both policies to prevent local administrators and users from seeing the exclusions in the Windows Security app or via PowerShell. When configured this way, only administrators with access to the management tools can view and manage these exclusions. This helps organizations ensure that only authorized personnel can view or modify these settings. Configure the update channel Microsoft Defender Antivirus has introduced three policies to select the update channel, tailored to different environments. These policies allow administrators to choose the channel for daily Security Intelligence updates, monthly Engine updates, and monthly Platform updates. We suggest configuring these three policies as below Select the channel for Microsoft Defender daily Security Intelligence updates - Current Channel (Broad) Select the channel for Microsoft Defender monthly Engine updates - Current Channel (Broad) Select the channel for Microsoft Defender monthly Platform updates - Current Channel (Broad) Device control Microsoft Defender Antivirus has introduced a suite of new device control policies to allow administrators to regulate access to peripheral devices such as USB drives, CDs, printers, and Bluetooth devices, effectively preventing data loss and malware infections. By integrating with BitLocker, device control can enforce encryption on removable media, ensuring that sensitive data remains protected even when transferred. You can find those policies at Windows Components\Microsoft Defender Antivirus\Device Control. Dynamic Signature dropped events You can determine whether to report events where dynamic signatures are dropped with the policy Configure whether to report Dynamic Signature dropped events. Dynamic signatures are used to detect and block new and emerging threats. When this policy is enabled, any dropped dynamic signature events are reported, allowing administrators to monitor and investigate why certain threats were not detected or blocked. If you leave it as default or configure this setting to disabled, Dynamic Signature dropped events will not be reported. EDR in block mode Endpoint detection and response (EDR) in block mode, also known as passive remediation, is a feature of Microsoft Defender for Endpoint that provides an additional layer of protection for devices. When enabled, it allows Microsoft Defender Antivirus to take action on post-breach, behavioral detections even if it is not the primary antivirus solution on the device. This means that if the primary antivirus misses a threat, EDR in block mode can step in to block and remediate malicious artifacts, helping to prevent further damage. To learn more, refer to Endpoint detection and response in block mode. Network Protection on Windows Server In Windows Server, network protection is controlled using the registry key AllowNetworkProtectionOnWinServer, which maps to the policy This setting controls whether Network Protection is allowed to be configured into block or audit mode on Windows Server. This policy ensures that users and applications are prevented from accessing dangerous websites by either blocking or auditing their access attempts. On the other hand, Windows client devices use the policy Prevent users and apps from accessing dangerous websites to achieve similar protection. Therefore, for the server baseline, Prevent users and apps from accessing dangerous websites is deprecated, and the policy This setting controls whether Network Protection is allowed to be configured into block or audit mode on Windows Server is set to Block for both domain controllers (DC) and member servers. Real-time protection The policy Configure real-time protection and Security Intelligence Updates during OOBE allows you to configure whether real-time protection and Security Intelligence Updates are enabled before OOBE (out of box experience) is complete. We recommend enabling this setting for both domain controllers and member servers to ensure that the device is secure and protected from the moment it is set up. Run and customize on-demand scans We recommend enabling the policy Scan excluded files and directories during quick scans so that all files and directories that are excluded from real-time protection using contextual exclusions are scanned during a quick scan. SMB and file server Audit capability To enhance the security capabilities of the Server Message Block (SMB) protocol, three new audit policy settings have been introduced in Windows Server 2025. Audit client does not support encryption ensures that the SMB server logs events when an SMB client does not support encryption. Audit client does not support signing enables the SMB server to log events when an SMB client does not support signing Audit insecure guest logon allows the SMB server to log events when a client logs on using a guest account. These new audit policies provide increased logging capabilities, helping to identify and mitigate potential security risks more effectively. We recommend enabling all three settings for both the domain controller and member server. Authentication rate limiter The new policy Enable authentication rate limiter lets you control whether the SMB server will enable or disable the authentication rate limiter. We recommend you enabling this policy. You can set the invalid authentication delay in milliseconds with the policy Set authentication rate limiter delay (milliseconds). The recommended delay value is 2000 milliseconds. Block NTLM To enhance robust protection against NTLM relay attacks while maintaining necessary compatibility with existing systems, two new security policies have been introduced for configuring SMB to block NTLM. These policies align with the ongoing effort to mitigate NTLM Relay Attacks including enabling Extended Protection for Authentication (EPA) and LDAP channel binding by default. Block NTLM provides administrators an option to configure SMB to block NTLM. When enabled, the SMB client will not use NTLM for remote connection authentication, thereby reducing the risk of NTLM-based attack. It’s not enabled by default. Block NTLM Server Exception List allows administrators to specify servers that can still use NTLM for remote connection authentication, even if the Block NTLM policy is enabled. This setting is useful for maintaining compatibility with legacy systems that require NTLM while still enforcing stricter security measures for other connections. To learn more about our effort of enabling NTLM Relay Attacks protection by default, see Mitigating NTLM Relay Attacks by Default | MSRC Blog | Microsoft Security Response Center Manage alternative ports To further enhance the security and flexibility of SMB client connections, Windows Server 2025 introduces new capabilities that allow you to establish SMB client connections using different ports than the well-defined defaults. The two new policies below enable you to manage the alternative ports. Enable Alternative Ports allows administrators to authorize the use of non-standard ports for SMB client communications, providing adaptability to various network configurations and needs while ensuring a robust security posture when needed. Alternative Port Mappings facilitates the detailed specification of alternative port mappings, allowing precise control over which ports and transport types the SMB client can use. Mandate the minimum version of SMB We recommend enforcing the minimum version of SMB to 3.0.0 by setting the policy Mandate the minimum version of SMB. Remote mailslots disabled by default In Windows Server 2025, SMB Remote Mailslots is disabled by default. You can enable it using the policy Enable remote mailslots, which we don’t recommend. Require encryption You can enforce encryption on all SMB clients by setting the policy Require Encryption. If enabled, the SMB client will require the SMB server to support encryption and encrypt the data (SMB 3.0 or later). If you disable or do not configure this policy setting, the SMB client will not require encryption. This policy is combined with per-share, per-server, and per-mapped-drive connection properties through which SMB encryption may be required. The SMB server must support and enable SMB encryption. For example, should this policy be disabled or not configured, the SMB client may still perform encryption if an SMB server share has required encryption. Virtualization Based Security While we don't explicitly enforce the two configurations mentioned below due to potential dependency issues, we highly recommend considering them in audit mode. This approach allows you to evaluate their impact before full enforcement, ensuring that you can leverage our advanced security capabilities without disrupting your existing setup. By doing so, you can enhance your security posture and make informed decisions about implementing these configurations. Machine Identity Isolation Configuration Kernel-mode Hardware-enforced Stack Protection In addition, for the most secure posture, enabling LSA protection with UEFI is the most secure option. However, locking with UEFI adds some dependencies and may cause some compatibility risks. For that reason, we highly recommend evaluating your environment carefully before enabling the policy with UEFI lock. Windows Protected Print Windows Protected Print (WPP) is the new, modern and more secure print for Windows built from the ground up with security in mind. WPP blocks 3 rd party drivers and hardens the entire print stack from attacks. WPP is designed to work with Mopria certified printers. While not yet configured in the security baseline, we recommend you consider the setting Printers\Configure Windows protected print as later versions of the baselines will look to enable this very important feature. You can learn more about the security benefits in our blog post.Security baseline for Windows Server 2025, version 2506
Microsoft is pleased to announce the June 2025 revision of the security baseline package for Windows Server 2025 (v2506)! You can download the baseline package from the Microsoft Security Compliance Toolkit, test the recommended configurations in your environment, and customize / implement them as appropriate. Starting with this release, we plan to revise the Windows Server baseline more frequently to keep pace with evolving threats, new Windows features, and community feedback. Summary of Changes in This Release (v2506) This release includes several changes made since the last release of the security baseline for Windows Server 2025 in January 2025 to further assist in the security of enterprise customers along with better aligning with the latest standards. The changes include what is now depicted in the table below. Security Policy Change Summary Deny log on through Remote Desktop Services Allow remote logon for non-admin local accounts on MS and add “BUILTIN\Guests” to both DC and MS. WDigest Authentication Remove from the baseline Allow Windows Ink Workspace Remove from the baseline Audit Authorization Policy Change Set to “Success” in both DC and MS Include command line in process creation events Enable in both DC and MS Control whether exclusions are visible to local users Moved to Not Configured as it is overridden by the parent setting. Deny log on through Remote Desktop Services We updated SeDenyRemoteInteractiveLogonRight on member servers to use S-1-5-114 (Local account and member of Administrators group) instead of S-1-5-113 (all local accounts) to strike a better balance between security and operational flexibility. This change continues to block remote RDP access for high-risk local admin accounts—our primary threat vector—while enabling legitimate use cases for non-admin local accounts, such as remote troubleshooting and maintenance during failover or domain unavailability. By allowing non-admin local accounts to log on interactively, we preserve a secure recovery path without weakening protection for privileged accounts. In addition, to strengthen the Remote Desktop Services (RDS) posture on both Windows Server 2025 Domain Controllers and Member Servers, we added the Guests group to the "Deny log on through Remote Desktop Services" policy. While the Guest account is disabled by default, explicitly denying its RDP access adds a defense-in-depth measure that helps prevent misuse if the group is ever enabled or misconfigured. This complements the existing restriction on Local Account logon for DCs and helps ensure a consistent security posture across server roles. WDigest Authentication We removed the policy "WDigest Authentication (disabling may require KB2871997)" from the security baseline because it is no longer necessary for Windows Server 2025. This policy was originally enforced to prevent WDigest from storing users plaintext passwords in memory, which posed a serious credential theft risk. However, starting with 24H2 update (KB5041160) for Windows Server 2022 and continuing into Windows Server 2025, the engineering teams have deprecated this policy. As a result, there is no longer a need to explicitly enforce this setting, and the policy has been removed from the baseline to reflect the current default behavior. Allow Windows Ink Workspace We removed the policy “Allow Windows Ink Workspace” from the Windows Server 2025 security baseline. This policy applies only to Windows client editions and is not available on Windows Server. Including it in the baseline caused confusion removing an unnecessary setting from the baseline reduces GPO processing time and helps ensure all recommended settings are applicable for the Windows Server environment. Audit Authorization Policy Change We set Audit Authorization Policy Change (Success) on the baseline for both Domain Controllers and Member Servers to ensure visibility into any changes that affect the system’s security posture, including modifications to user rights and audit policies. These changes directly impact how access is granted and how activity is monitored, making them critical to detect for both security and compliance purposes. Logging successful changes helps identify misconfigurations, unauthorized privilege assignments, or malicious tampering — especially in cases of lateral movement or privilege escalation. Because these events occur infrequently, they generate minimal log volume while offering high forensic and operational value. While Failure auditing is not set, it is available as an optional setting on both Domain Controllers and Member Servers for organizations that have the monitoring capability to interpret and act on failed attempts to modify security policies. This provides an added layer of visibility in high-assurance or tightly controlled environments. Include command line in process creation events We added Include command line in process creation events in the baseline to improve visibility into how processes are executed across the system. Capturing command-line arguments allows defenders to detect and investigate malicious activity that may otherwise appear legitimate, such as abuse of scripting engines, credential theft tools, or obfuscated payloads using native binaries. This setting supports modern threat detection techniques with minimal performance overhead and is widely recommended. Visibility of Microsoft Defender Antivirus Exclusions We updated the configuration for the policy "Control whether exclusions are visible to local users" (Computer Configuration\Windows Components\Microsoft Defender Antivirus) to Not Configured in this release. This change was made because the parent policy "Control whether or not exclusions are visible to Local Admins" is already set to Enabled, which takes precedence and effectively overrides the behavior of the former setting. As a result, explicitly configuring the child policy is unnecessary and may introduce confusion without impacting actual behavior. You can continue to manage exclusion visibility through the parent policy, which provides the intended control over whether local administrators can view exclusion lists. UEFI Lock and Virtualization-Based Protections In Windows, some security features are protected by Secure Boot and the TPM. When combined with firmware protections that lock UEFI configuration variables, these protections become tamper-resistant: Windows can detect and respond to unauthorized hardware changes or tamper attempts, making it significantly harder for attackers to disable key security features after deployment. In the Windows Server 2025 security baseline, two policy categories are configured to take advantage of UEFI lock: Virtualization-Based Security (VBS) — managed via the policy: System\Device Guard\Turn On Virtualization Based Security Local Security Authority (LSA) Protection — managed via the policy: System\Local Security Authority\Configure LSASS to run as a protected process While there are no changes to the recommended settings for these policies in this release, we want to highlight their role in strengthening system defenses and provide guidance to help you make informed deployment decisions. UEFI lock enforces these protections in a way that prevents local or remote tampering—even by administrators. This aligns with strong security requirements in sensitive or high-assurance environments. However, it also introduces important operational considerations: Some hardware platforms may not fully support UEFI lock Compatibility issues, reduced performance, or system instability may occur Once enabled, UEFI lock is difficult to reverse Please let us know your thoughts by commenting on this post or through the Security Baseline Community.
