Public Preview: Custom WAF Block Status & Body for Azure Application Gateway
Introduction Azure Application Gateway Web Application Firewall (WAF) now supports custom HTTP status codes and custom response bodies for blocked requests. This Public Preview feature gives you more control over user experience and client-side handling, aligning with capabilities already available on Azure Front Door WAF. Why this matters Previously, WAF returned a fixed 403 response with a generic message. Now you can: Set a custom status code (e.g., 403, 429) to match your app logic. Provide a custom response body (e.g., a friendly error page or troubleshooting steps). Ensure consistency across all blocked requests under WAF policy. This feature improves user experience (UX), helps with compliance, and simplifies troubleshooting. Key capabilities Custom Status Codes: Allowed values: 200, 403, 405, 406, 429, 990–999. Custom Response Body: Up to 32 KB, base64-encoded for ARM/REST. Policy-level setting: Applies to all blocked requests under that WAF policy. Limit: Up to 20 WAF policies with custom block response per Application Gateway. Configure in the Azure Portal Follow these steps: Sign in to the https://portal.azure.com. Navigate to your WAF Policy linked to the Application Gateway. Under Settings, select Policy settings. In the Custom block response section: Block response status code: Choose from allowed values (e.g., 403 or 429). Block response body: Enter your custom message (plain text or HTML). Save the policy. Apply the policy to your Application Gateway if not already associated. Configure via CLI az network application-gateway waf-policy update \ --name MyWafPolicy \ --resource-group MyRG \ --custom-block-response-status-code 429 \ --custom-block-response-body "$(base64 custompage.html)" Configure via PowerShell Set-AzApplicationGatewayFirewallPolicy ` -Name MyWafPolicy ` -ResourceGroupName MyRG ` -CustomBlockResponseStatusCode 429 ` -CustomBlockResponseBody (Get-Content custompage.html -Encoding Byte | [System.Convert]::ToBase64String) Tip: For ARM/REST, the body must be base64-encoded. Best practices Use meaningful status codes (e.g., 429 for rate limiting). Keep the response body lightweight and informative. Test thoroughly to ensure downstream systems handle custom codes correctly. Resources Configure Custom Response code Learn more about Application Gateway WAFSecurity Review for Microsoft Edge version 141
We have reviewed the new settings in Microsoft Edge version 141 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 141 introduced 6 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.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.Prescaling in Azure Firewall is now generally available
Azure Firewall protects your applications and workloads with cloud-native network security that automatically scales based on your traffic needs. Today, we’re excited to announce the general availability of prescaling in Azure Firewall – a new capability that gives you more control and predictability over how your firewall scales. Why pre-scaling? Today, Azure Firewall automatically scales in response to real-time traffic demand. For organizations with predictable traffic patterns – such as seasonal events, business campaigns, holidays, or planned migrations – the ability to plan capacity in advance can provide greater confidence and control. That’s where prescaling comes in. With prescaling, you can: Plan ahead– Set a baseline number of firewall capacity units to ensure capacity is already in place before demand rises. Stay flexible – Define both minimum and maximum capacity unit values, so your firewall always has room to grow while staying within your chosen bounds. See clearly – Monitor capacity trends with a new observed capacity metric and configure alerts to know when scaling events occur. You can think of it as adding extra checkout counters before a holiday rush – when the customers arrive, you’re already prepared to serve them without delays or bottlenecks. Example scenarios E-commerce sales events – Scale up before a holiday shopping promotion to handle the surge in online buyers. Workload migrations – Ensure sufficient capacity is ready during a large data or VM migration window. Seasonal usage – For industries like education, gaming, or media streaming, pre-scale ahead of known peak seasons. Getting started in Azure Portal Navigate to your Azure Firewall resource in the Azure Portal. Select Scaling options in settings. By default, every Azure Firewall starts in autoscaling mode. To enable prescaling, simply switch to pre-scaling mode in the Azure Portal and configure your desired capacity range: Minimum capacity: 2 or higher. Maximum capacity: up to 50, depending on your needs. Monitor the scaling behavior with the observed capacity metric. Billing and availability Pre-scaling uses a new Capacity Unit Hour meter. Charges apply based on the number of firewall instances you configure. Standard: $0.07 per capacity unit hour Premium: $0.11 per capacity unit hour ✨ Next steps Prescaling gives you predictable performance and proactive control over your firewall, helping you confidently handle the traffic patterns that matter most to your business. 🚀 Try prescaling today and share your feedback with the team. Learn more about how to configure and monitor this feature in the Azure Firewall prescaling documentation.Security baseline for Microsoft Edge version 139
We have reviewed the settings in Microsoft Edge version 139 and updated our guidance with the addition of one setting and the removal of one setting. 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. Allow software WebGL fallback using SwiftShader (Added) The EnableUnsafeSwiftShaderpolicy controls whether SwiftShader is used as a fallback for WebGL when hardware GPU acceleration is disabled or unavailable. SwiftShader, a software-based renderer, was used to enable WebGL support in environments lacking GPU acceleration, such as virtual machines. However, its continued use poses potential risks, whereby malicious web content could exploit vulnerabilities in the renderer. Due to the potential risks, we have decided to enforce the default and disable this setting. Edge for Business Connectors (Worth Mentioning) The new Edge for Business security connectors feature introduces a powerful framework that integrates the browser directly with your organization’s existing security stack covering authentication, data loss prevention (DLP), and reporting. By enabling real-time device trust validation, seamless DLP enforcement, and unified browser-based telemetry, these connectors help close critical gaps in enterprise security while extending the value of your current investments. Additional information can be found on the landing page. The following settings have been removed due to deprecation: Microsoft Edge/Private Network Request Settings/Specifies whether to allow websites to make requests to any network endpoint in an insecure manner. Microsoft Edge version 139 introduces 6 new computer settings and 6 new 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.Optimize Azure Firewall logs with selective logging
A common question from customers is whether Azure Firewall supports filtering or selecting which logs are sent to a Log Analytics workspace. This concern usually stems from the high cost of storing large volumes of data — especially in environments where the firewall inspects substantial amounts of network traffic. Azure Firewall now supports ingestion-time transformation of logs in Azure Log Analytics. This capability introduces selective and advanced filtering, giving customers more control over what data is collected and analyzed. In this blog post, we’ll explore a major new capability: Azure Firewall now supports ingestion-time transformations in Log Analytics — enabling flexible, cost-efficient logging through selective data collection. Why does it matter? For many enterprise customers, the cost of ingesting Azure Firewall logs into Log Analytics — especially at scale — can be significant. Depending on the logging mode (Basic or Analytics), ingestion costs can be substantial, potentially making it challenging to expand logging coverage across additional workloads. With ingestion-time transformations, users can filter logs by rows, columns, timestamps, and more — and apply transformations before ingestion. This ensures that only relevant and critical data is stored, helping reduce costs while retaining the necessary telemetry for analysis, threat detection, and compliance. Customer benefits Security monitoring: Log only suspicious traffic for more targeted threat detection. Cost optimization: Avoid ingesting and storing unnecessary data. Compliance: Use DCR (data collection rules) to filter and route logs to meet audit/reporting needs. Incident response: Focus on logs that matter, accelerating investigation time. Custom alerts: Build insights on top of curated, high-value logs. What are transformations in Azure Monitor? Ingestion-time transformations in Azure Monitor allow you to filter or modify incoming telemetry before it reaches your Log Analytics workspace. This happens in the cloud pipeline — after the data source (such as Azure Firewall) sends its logs, but before those logs are ingested and stored. Transformations are defined using DCR and written in Kusto Query Language (KQL). Each transformation runs against incoming records individually, letting you precisely control what gets stored – and what doesn’t. For example, you might collect only entries where the action column contains the word “deny”. That filter can be applied at ingestion time, so only those critical logs are stored. The diagram below shows how this works end-to-end, from data source to filtered ingestion. To learn more and estimate potential processing charges, refer to the official documentation. Transforming Azure Firewall logging In this section, we’ll walk through a few real-world use cases shared by customers — including how to create a DCR based on specific filtering criteria. Important: Ingestion-time transformations for Azure Firewall logs are supported only when using resource-specific logs. If you’re using legacy diagnostic settings, this capability is not available. To enable transformations, ensure your firewall is configured to send logs using the Azure Firewall resource-specific log schema. First, navigate to your Log Analytics workspace and locate the table where your Azure Firewall logs are stored (e.g., AZFWApplicationRule). Click the three-dot menu (…) on the right and select “Create transformation”. Creating a transformation is a 3 steps-process. Step 1 – Basics: Create a DCR to define how incoming data is processed and specify where it should be stored. Step 2 – Schema and transformation: Use the Transformation Editor to write a KQL query that filters the incoming data based on your criteria. Step 3 – Review: Review the table name, DCR name, and KQL query before clicking “Create”. This summary ensures everything is configured correctly. For more information on how to create a DCR, refer to the official documentation. Use case 1: Excluding alerts from low priority IDPS signatures This DCR transformation filters and reshapes incoming Azure Firewall IDPS logs before they're ingested into a Log Analytics workspace. source | where Action !contains "alert" and Severity != 3 | project TimeGenerated, Protocol, SourceIp, SourcePort, DestinationIp, DestinationPort, Action, SignatureId, Description, Severity Here's a breakdown of what it does: source: This refers to the incoming data stream — in this case, the AZFWIdpsSignature table (intrusion detection/prevention logs from Azure Firewall). | where Action !contains "alert" and Severity != 3: This line filters out any log entries where the Action contains "alert" (non-blocking detection events). Any entries where Severity equals 3 (which represents low severity events). The result: We’re keeping only more actionable or higher-severity entries that don’t just raise alerts but may involve blocks or higher-severity behaviors (e.g., deny actions, critical or warning severities). | project ...: The project statement selects and forwards only the specified columns to the Log Analytics workspace. When you run a query in your Log Analytics workspace, you’ll notice that only the specific columns defined in your transformation’s project statement are available — and they appear in the exact order specified in the query. Use case 2: Filtering out unnecessary logs (trusted or testing networks) This DCR transformation filters out log entries from specific source IP address ranges before they're ingested into Azure Monitor. In this scenario, the 10.0.200.x and 10.0.300.x ranges might represent trusted or test network segments that generate high volumes of traffic — traffic that don’t need to be logged. By excluding these IPs at ingestion time, you can significantly reduce unnecessary log volume and associated costs. source | where not( SourceIp startswith "10.0.200." or SourceIp startswith "10.0.300." ) | project TimeGenerated, Protocol, SourceIp, SourcePort, DestinationIp, DestinationPort, Action, ActionReason, Policy, RuleCollection, Rule Here's a breakdown of what it does: source: This refers to the incoming data stream — in this case, the AZFWNetworkRule table. | where not (…): Applies a filter to exclude logs that match the criteria inside. SourceIp startswith "10.0.200." and SourceIp startswith "10.0.300.": These conditions match any log where the SourceIp address falls within the 10.0.200.0/24 or 10.0.300.0/24 subnets (i.e., IPs like 10.0.200.1, 10.0.200.45, etc.). | project ...: The project statement selects and forwards only the specified columns to the Log Analytics workspace. Conclusion By leveraging ingestion-time transformations through DCR, organizations gain full control over which Azure Firewall logs are ingested in Log Analytics. This selective logging capability helps reduce noise, cut costs, and retain only high-value data for security, compliance, and operational insights. As Azure Firewall evolves these enhancements offer greater flexibility and efficiency for managing cloud-native network telemetry. Resources Azure updates | Microsoft Azure Monitoring data reference for Azure Firewall | Microsoft Learn Transformations Azure Monitor - Azure Monitor | Microsoft Learn Create a transformation in Azure Monitor - Azure Monitor | Microsoft LearnSecurity Review for Microsoft Edge version 138
We have reviewed the new settings in Microsoft Edge version 138 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 128 security baseline, which can be downloaded from the Microsoft Security Compliance Toolkit, continues to be our recommended configuration. Microsoft Edge version 138 introduces 6 new Computer and User settings and we have included a spreadsheet listing the new settings. There are two settings we would like to highlight for consideration as they enabling previewing behavior that will be enabled by default in a future release. Control whether TLS 1.3 Early Data is enabled in Microsoft Edge This setting allows enterprises to control whether the browser uses TLS 1.3 Early Data, a performance feature that sends HTTPS requests in parallel with the TLS handshake. This setting allows for faster use of secure connections. Enterprise customers are encouraged to test to identify any compatibility issues prior to the enablement. Specifies whether to block requests from public websites to devices on a user's local network This setting helps prevent malicious websites from probing or interacting with internal resources (i.e. printers, routers, or internal APIs), reducing the risk of lateral movement or data exposure. Enterprise customers are encouraged to test for any intentional requests from public to local devices. One thing to note on this policy setting is you may see a deprecation claim in the setting title. This was in error and will be corrected in a subsequent release. 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 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.Security Review for Microsoft Edge version 137
We have reviewed the new settings in Microsoft Edge version 137 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 137 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.
