Security Review for Microsoft Edge version 136
We are pleased to announce the security review for Microsoft Edge, version 136. We have reviewed the new settings in Microsoft Edge version 136 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 128 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 136 introduced 4 new Computer and User settings, we have included a spreadsheet listing the new settings to make it easier for you to find. As a friendly reminder, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here. Please continue to give us feedback through the Security Baselines Discussion site or this post.Security Review for Microsoft Edge version 135
We are pleased to announce the security review for Microsoft Edge, version 135. We have reviewed the new settings in Microsoft Edge version 135 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 128 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 135 introduced 5 new Computer and User settings, we have included a spreadsheet listing the new settings to make it easier for you to find. As a friendly reminder, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here. Please continue to give us feedback through the Security Baselines Discussion site or this post.Security Review for Microsoft Edge version 134
We have reviewed the new settings in Microsoft Edge version 134 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 128 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 134 introduced 12 new Computer and User settings and we have included a spreadsheet listing the new settings to make it easier for you to find. There are however two settings we would like to highlight Configure Edge Scareware Blocker Protection This is an important new feature for combatting the most prevalent social-engineering attacks on the web. While we are not ready to enforce this setting yet, organizations should consider its impact and determine if it is right for their environments. In a future baseline, this will be set to a value of Enabled. Additional details can be found here. JavaScript optimization settings These v8 JavaScript engine policies (located under Microsoft Edge\Content settings) control whether Edge will perform JIT-compilation of JavaScript code on websites. Disabling JIT-compilation improves security against many memory-safety vulnerabilities but can slow website performance on script-heavy sites. These policies control only JavaScript compilation and do not impact Web Assembly (WASM) compilation, which remains enabled by default unless Edge’s Enhanced Security Mode (ESM) is in use. Disabling the optimizer disables the two JIT optimizing compilers (Maglev and Turbofan) but WASM can continue to use JIT compiler (LiftOff). The disablement of these two compilers reduces the browser’s attack surface significantly. These policies are an addition to the existing ESM policies. If the Enterprise has set the ESM policies, then ESM policy takes precedence over V8 optimizer disablement. As a friendly reminder, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here. Please continue to give us feedback through the Security Baselines Discussion site or this post.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 review for Microsoft Edge version 133
We are pleased to announce the security review for Microsoft Edge, version 133. We have reviewed the new settings in Microsoft Edge version 133 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 128 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 133 introduced 13 new Computer and User settings and we have included a spreadsheet listing the new settings to make it easier for you to find. As a friendly reminder, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here. Please continue to give us feedback through the Security Baselines Discussion site or this post.Security Baseline for M365 Apps for enterprise v2412
Microsoft is pleased to announce the release of the recommended security configuration baseline settings for Microsoft 365 Apps for enterprise, version 2412. Please download the content from the Microsoft Security Compliance Toolkit, test the recommended configurations, and implement as appropriate. This baseline builds on the previous Office baseline we released June 2023. The highlights of this baseline include: Added a new setting to Microsoft Project around blocking macros from the internet The recommended settings in this security baseline correspond with the administrative templates version 5473, released on 10/10/2024. Deployment options for the baseline IT Admins can apply baseline settings in different ways. Depending on the method(s) chosen different registry keys will be written and they will be observed in order of precedence: Office cloud policies will override ADMX/Group Policies which will override end user settings in the Trust Center. Cloud policies may be deployed with the Office cloud policy service for policies in HKCU. Cloud policies apply to a user on any device accessing files in Office apps with their AAD account. In Office cloud policy service, you can create a filter for the Area column to display the current Security Baselines, and within each policy's context pane the recommended baseline setting is set by default. Learn more about Office cloud policy service. ADMX policies may be deployed with Microsoft Endpoint Manager (MEM) for both HKCU and HKLM policies. These settings are written to the same place as Group Policy, but managed from the cloud in MEM. There are two methods to create and deploy policy configurations: Administrative templates or the settings catalog. Group Policy may be deployed with on premise AD DS to deploy Group Policy Objects (GPO) to users and computers. The downloadable baseline package includes importable GPOs, a script to apply the GPOs to local policy, a script to import the GPOs into Active Directory Group Policy, updated custom administrative template (SecGuide.ADMX/L) file, all the recommended settings in spreadsheet form and a Policy Analyzer rules file. GPOs included in the baseline Most organizations can implement the baseline’s recommended settings without any problems. However, there are a few settings that will cause operational issues for some organizations. We've broken out related groups of such settings into their own GPOs to make it easier for organizations to add or remove these restrictions as a set. The local-policy script (Baseline-LocalInstall.ps1) offers command-line options to control whether these GPOs are installed. "MSFT Microsoft 365 Apps v2412" GPO set includes “Computer” and “User” GPOs that represent the “core” settings that should be trouble free, and each of these potentially challenging GPOs: “DDE Block - User” is a User Configuration GPO that blocks using DDE to search for existing DDE server processes or to start new ones. “Legacy File Block - User” is a User Configuration GPO that prevents Office applications from opening or saving legacy file formats. "Legacy JScript Block - Computer" disables the legacy JScript execution for websites in the Internet Zone and Restricted Sites Zone. “Require Macro Signing - User” is a User Configuration GPO that disables unsigned macros in each of the Office applications. Block macros from running in Office files from the internet Microsoft Project now supports a configurable setting to block macros from running in Office files from the internet. To maintain consistency across applications the security baseline will enforce the default of Enabled. If you have questions or issues, please let us know via the Security Baseline Community or this post.
