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 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 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.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.🆕 Microsoft Q&A Platform Update
We’re excited to introduce a new capability on Microsoft Q&A that provides contributors with greater visibility into their activity and impact. 📊 Contributor Analytics Dashboard The Contributor Analytics Dashboard is now available on Microsoft Q&A within Microsoft Learn, offering a self-serve experience to track contributions and engagement. This new experience was built to improve transparency and make it easier for contributors to understand the value of their participation across the platform. 🔎 How to access Click your Learn profile avatar Select Analytics 📈 What you can track The dashboard surfaces key metrics to help you measure your impact: Number of answers provided Acceptance rate Views and votes Activity trends over time Content engagement signals These insights allow contributors to better understand performance and track progress over time. ✅ Who can use it The dashboard is currently available to contributors who have answered at least one question on Microsoft Q&A. 💡 Why this matters This update brings: Increased visibility into your contributions A centralized view of your activity (no more manual tracking) Better understanding of your impact across the community Stronger recognition and motivation for continued contributions 🔄 What’s next The experience will continue to evolve, with additional enhancements planned based on contributor feedback. 🙌 For Product Champions This dashboard is especially valuable as you: Track your growth within the program Measure impact for recognition and rewards Monitor your contribution consistency across product tracks As our program grows, transparency like this helps ensure that quantity transforms into quality and that your contributions are clearly recognized.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.Writing High‑Quality Answers on Microsoft Q&A
Overview High‑quality answers are the foundation of Microsoft Q&A. They help resolve issues faster, support learners at every level, and play a key role in recognition within the Product Champions Program. This article highlights practical, proven practices that help contributors write answers that are clear, useful, and more likely to be accepted—so your expertise has real impact across the community. What Makes a High‑Quality Answer? Great answers do more than respond—they guide. Strong answers on Microsoft Q&A are: ✅ Clear and Focused Directly address the question being asked Explain the solution in straightforward, easy‑to‑follow language Stay focused on the issue without speculation or unrelated details ✅ Actionable Include clear steps, examples, or configuration guidance Explain why a solution works when context adds value Reference official Microsoft documentation when helpful ✅ Accurate Align with the product, scenario, and context of the question Stay within scope and avoid assumptions beyond what’s provided Answer vs. Comment: Knowing the Difference Choosing the right response type keeps Q&A threads clean and effective. Answer — Use when you’re providing a solution or clear resolution Comment — Use when you need clarification, logs, or additional details This helps accepted answers stand out and makes threads easier to follow. How to Structure an Effective Answer Well‑structured answers are easier to read—and more likely to be accepted. Aim to include: A brief explanation of the issue Clear, step‑by‑step guidance Optional links or next steps for deeper learning Simple structure goes a long way. Tags and Product Alignment Microsoft Q&A uses a structured tagging system to connect questions with the right experts. Your answer should always align with the product and scenario defined by the selected tag to ensure accuracy and relevance. Why This Matters for Product Champions Consistently high‑quality answers: Are more likely to be accepted Help contributors progress through Champion levels Increase visibility, credibility, and community impact Every strong answer helps learners—and strengthens the Q&A ecosystem. Additional Learning To continue building your skills as a contributor, explore the official Microsoft Q&A Contributor Guide, which covers best practices, standards, and additional tips for success.Security baseline for Windows Server 2025, version 2602
Microsoft is pleased to announce the February 2026 Revision (v2602) of the security baseline package for Windows Server 2025! 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 in This Release This release includes several changes made since the Security baseline for Windows Server 2025, version 2506 to further assist in the security of enterprise customers along with better aligning with the latest capabilities and standards. The changes include what is now depicted in the table below. Security Policy Change Summary Configure the behavior of the sudo command Configured as Enabled: Disabled on both MS and DC Configure Validation of ROCA-vulnerable WHfB keys during authentication Configured as Enabled: Block on DC to block Windows Hello for Business (WHfB) keys that are vulnerable to the Return of Coppersmith's attack (ROCA) Disable Internet Explorer 11 Launch Via COM Automation Configured as Enabled to prevent legacy scripts and applications from programmatically launching Internet Explorer 11 using COM automation interfaces Do not apply the Mark of the Web tag to files copied from insecure sources Configured as Disabled on both MS and DC Network security: Restrict NTLM: Audit Incoming NTLM Traffic Configured as Enable auditing for all accounts on both MS and DC Network security: Restrict NTLM: Audit NTLM authentication in this domain Configured as Enable all on DC Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers Configured as Audit all on both MS and DC NTLM Auditing Enhancements Already enabled by default to improve visibility into NTLM usage within your environment Prevent downloading of enclosures Remove from the baseline as it is not applicable for Windows Server 2025. It depends on IE – RSS feed Printer: Configure RPC connection settings Enforce the default, RPC over TCP with Authentication Enabled, on both MS and DC Printer: Configure RPC listener settings Configure as RPC over TCP | Kerberos on MS Printer: Impersonate a client after authentication Add RESTRICTED SERVICES\PrintSpoolerService to allow the Print Spooler’s restricted service identity to impersonate clients securely Configure the behavior of the sudo command Sudo for Windows can be used as a potential escalation of privilege vector when enabled in certain configurations. It may allow attackers or malicious insiders to run commands with elevated privileges, bypassing traditional UAC prompts. This is especially concerning in environments with Active Directory or domain controllers. We recommend to configuring the policy Configure the behavior of the sudo command (System) as Enabled with the maximum allowed sudo mode as Disabled to prevent the sudo command from being used. Configure Validation of ROCA-vulnerable WHfB keys during authentication To mitigate Windows Hello for Business (WHfB) keys that are vulnerable to the Return of Coppersmith's attack (ROCA), we recommend enabling the setting Configure Validation of ROCA-vulnerable WHfB keys during authentication (System\Security Account Manager) in a Block mode in domain controllers. To ensure there are no incompatible devices/orphaned/vulnerable keys in use that will break when blocked, please see Using WHfBTools PowerShell module for cleaning up orphaned Windows Hello for Business Keys - Microsoft Support. Note: A reboot is not required for changes to this setting to take effect. Disable Internet Explorer 11 Launch Via COM Automation Similar to the Windows 11 version 25H2 security baseline, 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. Do not apply the Mark of the Web tag to files copied from insecure sources We have included the setting Do not apply the Mark of the Web tag to files copied from insecure sources (Windows Components\File Explorer) configured as Disabled, which is consistent with Windows 11 security baseline. When this configuration is set to Disabled, Windows applies the Mark of the Web (MotW) tag to files copied from locations classified as Internet or other untrusted zones. This tag helps enforce additional protections such as SmartScreen checks and Office macro blocking, reducing the risk of malicious content execution. NTLM Auditing As part of our ongoing effort to help customers transition away from NTLM and adopt Kerberos for a more secure environment, we introduce new recommendations to strengthen monitoring and prepare for future NTLM restrictions on Windows Server 2025. Configure Network security: Restrict NTLM: Audit Incoming NTLM Traffic (Security Options) to Enable auditing for all accounts on both member servers and domain controllers. When enabled, the server logs events for all NTLM authentication requests that would be blocked once incoming NTLM traffic restrictions are enforced. Configure Network security: Restrict NTLM: Audit NTLM authentication in this domain (Security Options) to Enable all on domain controllers. This setting logs NTLM pass-through authentication requests from servers and accounts that would be denied when NTLM authentication restrictions are applied at the domain level. Configure Outgoing NTLM traffic to remote servers (Security Options) to Audit all on both member servers and domain controllers to log an event for each NTLM authentication request sent to a remote server, helping identify servers that still receive NTLM traffic. In addition, there are two new NTLM auditing capabilities enabled by default that were recently introduced in Windows Server 2025 and Windows 11 version 25H2. 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. Prevent Downloading of Enclosures The policy Prevent downloading of enclosures (Windows Components\RSS Feeds) has been removed from the Windows Server 2025 security baseline. This setting is not applicable to Windows Server 2025 because it depends on Internet Explorer functionality for RSS feeds. Printer security enhancements There are two new policies in Windows Server 2025 designed to significantly improve security posture of printers: Require IPPS for IPP printers (Printers) Set TLS/SSL security policy for IPP printers (Printers) Enabling these policies may cause operational challenges in environments that still rely on IPP or use self-signed or locally issued certificates. For this reason, these policies are not ter enforced in the Windows Server 2025 security baseline. However, we do recommend customers transition out of IPP or self-signed certificates and restricting them for a more secure environment. In addition, there are some changes to printer security Added RESTRICTED SERVICES\PrintSpoolerServiceto the Impersonate a client after authentication (User Rights Assignments) policy for both member servers and domain controllers, consistent with security baseline for Windows 11 version 25H2. Enforced the default setting for Configure RPC connection settings (Printers) to always use RPC over TCP with Authentication Enabled on both member servers and domain controllers. This prevents misconfiguration that could introduce security risks. Raised the security bar of the policy Configure RPC listener settings (Printers) from Negotiate (default) to Kerberos on member servers. This change encourages customers to move away from NTLM and adopt Kerberos for a more secure environment. Secure Boot certificate update To help organizations deploy, manage, and monitor the Secure Boot certificate update, Windows includes several policy settings under Administrative Templates\Windows Components\Secure Boot. These settings are deployment controls and aids. Enable Secure Boot Certificate Deployment allows an organization to explicitly initiate certificate deployment on a device. When enabled, Windows begins the Secure Boot certificate update process the next time the Secure Boot task runs. This setting does not override firmware compatibility checks or force updates onto unsupported devices. Automatic Certificate Deployment via Updates controls whether Secure Boot certificate updates are applied automatically through monthly Windows security and non‑security updates. By default, devices that Microsoft has identified as capable of safely applying the updates will receive and apply them automatically as part of cumulative servicing. If this setting is disabled, automatic deployment is blocked and certificate updates must be initiated through other supported deployment methods. Certificate Deployment via Controlled Feature Rollout allows organizations to opt devices into a Microsoft‑managed Controlled Feature Rollout for Secure Boot certificate updates. When enabled, Microsoft assists with coordinating deployment across enrolled devices to reduce risk during rollout. Devices participating in a Controlled Feature Rollout must have diagnostic data enabled. Devices that are not enrolled will not participate. Secure Boot certificate updates depend on device firmware support. Some devices have known firmware limitations that can prevent updates from being applied safely. Organizations should test representative hardware, monitor Secure Boot event logs, and consult the deployment guidance at https://aka.ms/GetSecureBoot for detailed recommendations and troubleshooting information. SMB Server hardening feature SMB Server has been susceptible to relay attacks (e.g., CVE-2025-55234), and Microsoft has released multiple features to protect against the relay attacks including SMB Server signing, which can be enabled with the setting of Microsoft network server: Digitally sign communications (always) (Security Option) SMB Server extended protection for authentication (EPA), which can be enabled with the setting of Microsoft network server: Server SPN target name validation level (Security Option) To further support customers to adopt these SMB Server hardening features, in the September 2025 Security Updates, Microsoft has released support for Audit events, across all supported in-market platforms, to audit SMB client compatibility for SMB Server signing as well as SMB Server EPA. These audit capabilities can be controlled via the two policies located at Network\Lanman Server Audit client does not support signing Audit SMB client SPN support This allows you to identify any potential device or software incompatibility issues before deploying the hardening measures that are already supported by SMB Server. Our recommendation is For domain controllers, the SMB signing is already enabled by default so there is no action needed for hardening purposes. For member servers, first enabling the two new audit features to assess the environment and then decide whether SMB Server Signing or EPA should be used to mitigate the attack vector. Please let us know your thoughts by commenting on this post or through the Security Baseline Community.
