Security baseline for Microsoft Edge version 151
We are pleased to announce the enterprise-ready release of the security baseline for Microsoft Edge version 151! We have reviewed the settings in Microsoft Edge version 151 and updated our guidance with six new recommendations. We have also identified one additional setting that organizations should consider evaluating in their environments. A new Microsoft Edge security baseline package was just released to the Download Center. You can download the new package from the Security Compliance Toolkit. Enable Process Isolation (added) We are enforcing ‘Enable Process Isolation’ to help protect Microsoft Edge from unauthorized access, modification, and tampering by other applications running on the device. This setting strengthens browser process integrity and helps safeguard sensitive data used by Microsoft Edge. Organizations that encounter compatibility issues with software that depends on browser process injection should treat such configurations as exceptions requiring explicit risk acceptance and compatibility validation. Enable renderer in app container (added) We are enforcing the default and enabling ‘Enable renderer in app container’ to strengthen Microsoft Edge’s browser isolation protections by ensuring renderer processes run within the additional restrictions provided by AppContainer. This helps reduce the impact of browser-based attacks and limits the ability of exploited renderer processes to interact with system resources. Organizations that require this setting to be disabled due to incompatible software should treat such configurations as exceptions that require explicit risk acceptance. Enable the network service sandbox (added) We are enforcing the default and enabling ‘Enable the network service sandbox’ to ensure Microsoft Edge network-facing processes operate within sandbox isolation boundaries that help reduce the impact of exploitation and limit access to system resources. Because disabling the network service sandbox weakens a core browser security protection, organizations should treat any requirement to disable this setting as an exception scenario requiring explicit risk acceptance and compatibility validation. Configure browser process code integrity guard (added) We are enabling ‘Configure browser process code integrity guard setting’ with a value of ‘Enable code integrity guard enforcement in the browser process’. The setting strengthens protections against unauthorized code injection into Microsoft Edge browser processes. Some enterprise applications, extensions, accessibility tools, or security products may still rely on legacy injection techniques and require compatibility validation. We encourage organizations to fully test this setting in their environments and work with vendors to identify or remediate incompatible software. Enable Application Bound Encryption (added) We are enabling ‘Enable Application Bound Encryption’ to strengthen protections for browser-stored credentials, authentication tokens, and other sensitive data by binding encryption more closely to the browser process. This helps reduce the risk of unauthorized access to protected browser data by malware or other untrusted software. Because disabling this setting weakens an important protection boundary, organizations should treat any requirement to disable the feature as an exception requiring explicit risk review. Enhance the security state in Microsoft Edge (added) We are enabling ‘Enhance the security state in Microsoft Edge’ and configuring the setting to Balanced to provide additional protection against modern web-based attacks while maintaining compatibility for most enterprise users. In Balanced mode, Microsoft Edge applies additional mitigations such as disabling just-in-time (JIT) JavaScript compilation and enabling added operating system protections on processes used to load sites that users do not frequently visit, helping reduce the risk of memory-related vulnerabilities. Because these protections can introduce compatibility issues for some applications or workflows, organizations should validate critical business sites and applications during their normal testing process prior to broad deployment and configure exceptions as needed. Additional details can be found here. Configure Automatic HTTPS (worth considering) We previously released a blog discussing a new feature called Automatic HTTPS. This setting can automatically switch your connections to websites from HTTP to HTTPS on sites that are highly likely to support the more secure protocol. This option helps ensure that users' network traffic is more secure and less susceptible to SSL stripping attacks. The best part, the end user doesn’t get prompted, it just works! This new feature has two configuration options: Navigations delivered over HTTP are switched to HTTPS’ (UpgradeCapableDomains) and ‘All navigation delivered over HTTP are switched to HTTPS’ (AlwaysUpgrade). There are trade-offs for each configuration: the UpgradeCapableDomains option only upgrades to HTTPS if Microsoft believes the site is likely to work over HTTPS, and this setting is unavailable if you’ve disabled the ComponentUpdatesEnabled policy. The more secure AlwaysUpgrade option unconditionally updates all HTTP requests to HTTPS, which will result in a user-visible error page if the target site does not support HTTPS. We encourage organizations to consider implementing and testing Automatic HTTPS within their environment. Collectively, these changes continue our focus on strengthening browser isolation, sandboxing, process integrity, and protection of sensitive browser data while balancing enterprise compatibility requirements. Microsoft Edge version 151 introduced 4 new computer and user settings. We have included a spreadsheet listing the new settings in the release to make it easier for you to find them. 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 Baseline Community or in comments on this post.Security Review for Microsoft Edge version 152
We have reviewed the new settings in Microsoft Edge version 152 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 151 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 152 introduced 4 new Computer and User settings; we have included a spreadsheet listing the new settings to make it easier for you to find. Starting with version 152 Microsoft Edge is moving to a more frequent release cycle. To better align with the needs of the enterprise customers, the Microsoft Edge security baseline is expected to align with the Extended Stable Channel, which provides major feature updates on an eight-week cadence while continuing to receive security and quality updates between releases. This approach provides organizations with additional time to evaluate and deploy feature changes while ensuring security protections remain current. Why the change? Security baselines are intended to provide guidance for managing security relevant configuration settings, not to track every feature introduced in a browser release. With the move to a two-week release cadence, publishing baseline updates for every release would increase operational overhead while providing limited security benefit. The Extended Stable cadence offers a more practical balance for enterprise customers by allowing additional time for testing and evaluation, while continuing to receive security and critical fixes between major feature releases. By aligning with Extended Stable, we can update the baselines less frequently and focus on publishing them earlier in the release cycle, giving IT administrators more time to review and plan for upcoming changes. Our goal is to make security baseline adoption more predictable and easier to manage while continuing to provide timely security guidance. 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 150
We have reviewed the new settings in Microsoft Edge version 150 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 139 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 150 introduced 8 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.
Dynamic Code Setting in Version 139 Causing Printing Issues
Microsoft Edge security baseline version 139 via Intune sets the Dynamic Code value to 'Prevent the browser process from creating dynamic code'. The setting causes Microsoft Edge to close down / crash when trying to print. Reverting the setting value back to version 128 'Default dynamic code settings' resolves Microsoft Edge not closing down when trying to print.Security Review for Microsoft Edge version 149
We have reviewed the new settings in Microsoft Edge version 149 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 139 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 149 introduced 7 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 148
We have reviewed the new settings in Microsoft Edge version 148 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 139 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 148 introduced 16 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 147
We have reviewed the new settings in Microsoft Edge version 147 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 139 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 147 introduced 9 new Computer and User settings; we have included a spreadsheet listing the new settings to make it easier for you to find. Version 147 introduced the Control the availability of the XSLT feature policy (XSLTEnabled). This policy exists to support enterprise testing and transition scenarios while the Chromium project works toward deprecating and removing XSLT support from the browser due to security concerns associated with this legacy feature. XSLT support in modern browsers represents a disproportionate attack surface, and upstream Chromium has announced plans to disable and ultimately remove XSLT in a future release. As a result, organizations should treat continued reliance on client‑side XSLT as technical debt and plan migration accordingly. Additional details can be found here. Organizations are encouraged to proactively test setting XSLTEnabled = Disabled to identify application dependencies and remediation requirements ahead of any future default changes or removal of the feature. 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 146
We have reviewed the new settings in Microsoft Edge version 146 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 139 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 146 introduced 9 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 145
We have reviewed the new settings in Microsoft Edge version 145 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 139 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 145 introduced 11 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.
