Registry Inventory in Microsoft Intune: Verifying What’s on Your Devices
By: Madison Cooks, Product Manager | Microsoft Intune IT admins need a reliable way to confirm how Windows devices are configured, especially when troubleshooting, validating compliance, or investigating security posture. Policy assignment alone doesn’t always show what’s present on the device and getting registry visibility at scale has often required custom discovery or remediation scripts that take time to build, test, and maintain. With Microsoft Intune’s July (2607) release, device inventory will include Windows registry data, helping IT admins verify a device’s actual configuration, not just the policy assigned. With a new Device inventory property for registry keys, you define the keys you care about in the properties catalog, and Intune collects them for you. There’s no collection logic to build or keep running. This makes registry-based configuration checks easier to operationalize across managed Windows devices, so teams can spend less time maintaining scripts and more time acting on the data. Figure 1: Microsoft Intune device inventory profile creation screen showing the Properties picker with the Registry category selected for inventory data collection. What registry data you collect Registry data collection is configured through the existing properties catalog. For each entry, provide a registry key path and, when needed, a value name. For every targeted device, the device agent attempts collection and reports: Registry key path Value name Value type Value data Microsoft Intune device inventory profile configuration page showing registry key collection settings, including registry path, collection pattern options, and value name fields. The initial release supports the following collection patterns designed for common admin scenarios that use HKEY_LOCAL_MACHINE (HKLM) paths. Single value Specify a registry path and value name to collect one value from that path. For example, collect Secure Boot certificate servicing status from HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot by using values such as UEFICA2023Status, UEFICA2023Error, or UEFICA2023ErrorEvent. All values under a path, non-recursive Specify a registry path to collect all values directly under that path. This pattern doesn't include subkeys. For example, collect values directly under a Windows Update configuration path to help validate expected settings. Same value across subkeys Specify a base registry key path and a value name to collect that value from each immediate subkey. For example, collect DHCP status across network interface subkeys under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces. Where registry inventory data appears After collection, registry inventory data will be available in Device inventory at initial release. We’ll expand access to registry data in the coming months, including support in additional reporting and exploration experiences. Microsoft Intune Device Inventory page displaying collected Windows registry data for a device, including registry key paths, values, collection status, and timestamps. This makes registry data available alongside other inventory signals, so admins can use familiar tools to investigate configuration, validate device state, and support troubleshooting without building separate collection scripts. How admins use this You can collect registry data and view it per device in Device inventory - a verified record of each endpoint’s actual configuration and a key source of settings data on each endpoint. This helps answer questions like: Is a setting actually enabled on the device? Which app, version, or configuration is installed? Did a policy apply correctly? Why is this device behaving differently from the rest? Registry data collection in Device inventory is included with Microsoft Intune Plan 1. Collection results and limits If a registry value exists but doesn’t contain data, collection succeeds and the value appears as empty. If the registry path or value name doesn’t exist on a device, that device reports Not found for the collection result. Collection continues for all other devices, so one missing value won’t block results from devices where the value exists. Registry inventory includes safeguards to keep collection focused and manageable. Each collected registry value is capped at 6 KB, and each device can collect up to 100 registry keys. If a value or device exceeds these limits, collection skips the excess data and reports the applicable result for that device. These limits help manage data volume, maintain service performance, and reduce the risk of over-collection. Registry inventory is designed for configuration visibility and troubleshooting, not for collecting sensitive or confidential data. Built-in heuristic detection helps identify and prevent ingestion of values that may contain secrets, credentials, authentication tokens, certificates, private keys, connection strings, or other data that could grant access if exposed. If a value is flagged as potentially sensitive, it isn’t collected. Collection is limited to HKEY_LOCAL_MACHINE (HKLM) paths. This keeps inventory focused on device-level configuration and avoids user-specific registry contexts. Summary Registry inventory in Microsoft Intune helps admins collect Windows registry data in a native, declarative way. Instead of maintaining custom scripts for common inventory scenarios, admins can configure registry collection in the properties catalog and query the results through familiar Intune reporting experiences. Use registry inventory for configuration visibility and troubleshooting across managed Windows devices. As you plan your collection strategy, focus on device-level HKLM data, avoid sensitive values, and remember collection limits to keep inventory targeted and manageable. If you have any feedback or questions, leave a comment below or reach out to us on X @IntuneSuppTeam.
Issues around our administratio email on school.onmiscrosoft.com
This page collects the issues (and related solutions/workarounds) linked to the administration account of the Microsoft 365 tenant http://school.onmicrosoft.com/. Context Tenant: my.name@myhttp://school.onmicrosoft.com/ Involved account: admin email address (specify which one, if needed) me and my administrator cannot access since jan 2026 Issues encountered Problem description Symptoms: my email amd my administrator email does not access the domani anymore Error message (if any): When it happens (frequency/time): no wayy to access other theachers have not this issue with the same domain Impact Who is blocked / which services are affected (Outlook, Teams, Entra ID, etc.) Urgency: Attempts already made [no way ] Password reset [ no way] Check MFA / sign-in methods [no way ] Try signing in from another browser / incognito [ ] Check Microsoft service status Next steps [ ] Collect screenshots and error codes see upper image [ ] Check sign-in logs (Entra ID) and any blocks (Conditional Access) [ ] Open a Microsoft support ticket (if needed) Notes / references Useful links: Last updated date:Windows 11 24H2 Sec Baseline → Broken SSO to on‑prem (Root cause: PKINIT SHA‑1 baseline)
Hi all, I ran into an issue with Entra-joined devices using Windows Hello for Business (Cloud Kerberos Trust) that might help others working with Windows 11 24H2 security baselines. Scenario Windows 11 25H2 devices Entra-joined (not hybrid) Intune-managed Windows Hello for Business (WHfB) enabled Cloud Kerberos Trust configured On-prem AD (Windows Server 2019/2022 DCs) Access to SMB shares / on-prem applications Symptoms SSO to on-prem resources fails Users get credential/PIN prompt instead of SSO Error message: “The system cannot contact a domain controller to service the authentication request” Client-side observations: klist → no tickets (initially) After enabling Cloud Kerberos Trust: klist get krbtgt → works klist get cifs/server.domain → fails Error: 0xc000a100 / 0x3bc4 Hash generation for the specified version and hash type is not enabled on server Root Cause The issue was caused by a Windows 11 24H2 security baseline setting related to Kerberos/PKINIT. The 24H2 baseline introduces a policy for configuring hash algorithms for certificate-based Kerberos authentication (PKINIT). This setting allows environments to disable SHA-1 and require SHA-2 algorithms. [applepie.se] Important detail: This configuration only works if the domain controllers fully support PKINIT with SHA-2, which effectively requires Windows Server 2025 domain controllers across the environment. If SHA-1 is disabled while running: Windows Server 2019 or 2022 DCs Mixed environments then PKINIT authentication fails, which directly impacts: Windows Hello for Business Cloud Kerberos Trust Any passwordless Kerberos-based authentication Why this is difficult to troubleshoot Cloud Kerberos Trust appears correctly configured AzureADKerberos object exists PRT is valid Network connectivity is fine However: Kerberos tickets are not issued correctly Service tickets (CIFS, HTTP, etc.) fail Errors are misleading and point to KDC/hash issues No explicit warning is provided in baseline guidance that mixed environments will break Resolution Revert the baseline change and allow SHA-1 for PKINIT again. Policy location: Computer Configuration → System → Kerberos / KDC → Configure hash algorithms for certificate logon Ensure: SHA-1 is set to Allowed/Default After reverting: Kerberos ticket issuance works SSO to on-prem resources is restored Recommendation Do not disable SHA-1 for PKINIT unless: All domain controllers are Windows Server 2025, and PKINIT SHA-2 support has been fully validated Treat this setting as future hardening, not production-safe for mixed environments today. Takeaway If you experience: WHfB + Cloud Kerberos Trust SSO failures klist get errors with hash generation issues Missing or failing Kerberos service tickets check the PKINIT hash configuration from the 24H2 security baseline first.Unpacking Endpoint Management is back - and we’ve got a lot to talk about
If you've been missing real, candid conversations about endpoint management, good news! Unpacking Endpoint Management is officially back. This series is all about what actually works. No fluff, just practical tips, proven strategies, and honest discussions to help you optimize and simplify the way you manage and secure endpoints today (and prepare for what's next). We're bringing together people from across Microsoft Intune, Security, and Customer Experience engineering and product teams, along with guest practitioners, to share what's worked, what hasn't, and what we've learned along the way. And yes…we're absolutely here for the tough questions. A quick update on the hosts Danny Guillory, a familiar face to the community and a Product Manager for Intune and Configuration Manager, will continue to host the series. He's joined this season by Rachelle Blanchard as co‑host, bringing a strong community and discovery lens to the series. Rachelle focuses on surfacing real customer questions and guiding conversations toward practical outcomes, helping ensure each episode reflects how endpoint management works in the real world. Up next What should we cover? Drop ideas below in the comments. Sign in to the Tech Community and follow this post for the latest updates on upcoming episodes. Catch up on demand You may have missed them, but you don't have to miss out on the learnings. Watch and learn when it's convenient for you. Policy: from hybrid to cloud-native Device security with Microsoft Intune Trends in endpoint management (live from Tech Takeoff 2026) Not sure where to start? Watch our most recent episode, App management at scale with Intune, now on demand! What's the format? This web series is streamed live on Tech Community, LinkedIn, YouTube, and X. In addition to open discussion, we answer your questions so sign in (or sign up for) the Tech Community and RSVP to submit questions early and throughout the live show. How do I join? There's no call or meeting to join. Simply head to aka.ms/JoinUEM. Show up at start time, watch live, and jump into the discussion with us. Help shape the series This series is for you - so tell us what you want to hear. Drop a comment below with: Topics you'd like us to cover Tough questions you want answered Speakers you'd love to hear from We can't wait to get started - and even more excited to hear from you along the way. Join the Community to get early insight into what's coming for Intune, connect with experts, and share real-world feedback that helps shape the product. 👉 aka.ms/JoinIntuneCommunityBuild a patch strategy for today’s threat pace with Microsoft
AI-accelerated vulnerability discovery and remediation are changing how organizations manage risk. As discussed in Pavan Davuluri’s recent blog, Microsoft is investing across the vulnerability lifecycle to help organizations identify, validate, and respond faster. For IT and security teams, one challenge lies downstream: deploying fixes quickly across endpoints to reduce exposure. Each update needs to be evaluated, piloted, monitored, and enforced across a mixed fleet of devices and apps. Some parts of the estate can move quickly; others cannot because of compliance requirements, approved change windows, and business-critical dependencies. As organizations adopt AI tools and agents across their environment, maintaining a current and hardened endpoint estate becomes increasingly important. In this context, patching becomes an ongoing operational discipline that combines OS, app, and driver updates with compliance enforcement, access control, and security baseline hardening. To keep pace, organizations need a patch strategy that helps in 3 stages: Mitigate: automate updates that can move quickly Assess: prioritize risk based on exposure and severity Contain: enforce compliance and limit exposure Operationalizing a patch strategy requires coordinated capabilities across endpoint management and security tools. Microsoft Intune brings these capabilities together in a single admin center, alongside the broader Microsoft security ecosystem, and is available with qualifying Microsoft 365 subscriptions 1 . In this post, we show how organizations can use these capabilities to build a patch strategy that helps reduce the time between update release and deployment across their endpoint estate. 1. Mitigate: automate updates that can move quickly A patch strategy is not about pushing every update everywhere at once. It’s about identifying the parts of your estate that can move quickly, then using automation, rings, monitoring, and enforcement to help those updates move with confidence. Regulations, approved change windows, validation needs, and business dependencies will shape what’s possible, but the strategy starts by separating repeatable update work from the exceptions that need deeper review. For OS, app, and driver updates that can move quickly, modern tools can help shorten the time between update release and deployment; without manual rollouts, ticket-driven packaging, or reboot disruption. Operationalize in Intune Windows Autopatch orchestrates ring-based update rollouts to reduce manual effort and keep Windows devices current. To help monitor risk, the Autopatch report visualizes how quickly devices apply updates based on the configured deployment cadence. In this report, devices are categorized as current within three days of update release, at risk between three and seven days, and at critical risk beyond seven days, based on the reporting model used by Windows Autopatch. Learn more about ring-based rollout updates or how to reassess Windows OS updates using this report. Hotpatch (enabled by default for 24H2+ in Intune) applies critical updates without requiring a reboot, helping reduce security gaps while keeping users productive. Figure 1: Watch the latest Microsoft Mechanics episode to see how Windows Autopatch and Hotpatch help organizations accelerate update deployment, reduce operational overhead, and keep devices secure. Intune Enterprise App Management (EAM) supports keeping Windows apps current through auto-updates, including the guided upgrade supersedence reporting, which surfaces outdated versions or version changes. EAM auto-updates are now generally available; details are included in the June Intune What’s new blog. Figure 2: Watch how Intune helps you move from update release to deployment to accelerate responses to vulnerabilities with Windows app management. The enhanced application inventory in the All apps page shows the app version installed on each managed Windows device, refreshed multiple times per day on most active devices, helping teams target app-specific vulnerabilities and confirming when fixes have been applied. The Vulnerability Remediation Agent in Security Copilot uses data from Defender Vulnerability Management to prioritize Common Vulnerabilities and Exposures (CVEs) across Intune-managed Windows devices and apps, and provides recommended remediation actions within Intune. The Vulnerability Remediation Agent is currently in public preview, read the blog to learn more. Figure 3: Watch this video to see how the Vulnerability Remediation Agent in Security Copilot, within Microsoft Intune, helps make agentic security easier to adopt and use. Extend across your endpoint estate Apple devices can be configured for automatic OS updates on managed devices, including enforcing updates to the latest version and deploying Background Security Improvement patches through the settings catalog. App updates can be managed by configuring volume-purchased App Store apps to update automatically and deploy updated app packages to keep apps current across macOS, iPhone, and iPad devices. Android devices can be managed using built-in update policies in Intune, including configuring install windows and freeze periods. For corporate Android fleets, Intune also integrates with OEM firmware management solutions - including Zebra LifeGuard Over-the-Air and Samsung E-FOTA - to enable more granular update control. Managed Google Play also supports configurable app auto-update modes, allowing admins to define whether updates install automatically, on Wi-Fi only, or manually. 2. Assess: prioritize risk based on exposure and severity The first step is reducing exposure across the parts of your estate that can move quickly. But not every system, application, or vulnerability can be addressed through broad update deployment. Teams also need a way to determine which risks require immediate action and which ones can be addressed over time. A calendar-based approach can treat every CVE equally. However, it doesn’t account for severity, exposure, or business impact. As AI accelerates vulnerability discovery, this can lead to effort being spent on lower-risk updates while higher-risk updates remain unaddressed. Risk-based service level objectives (SLOs) help bring prioritization to address this challenge. Instead of patching on a fixed schedule, IT and security teams can align response timeframes by severity, moving quickly on actively exploited or critical vulnerabilities, and applying a more measured approach where risk or impact is lower. This stage creates a clearer prioritization of remediation and helps bridge the view between the security teams that identify threats and the IT teams that act on them. Operationalize in Intune and Microsoft Defender The security update status dashboard in Intune provides an aggregated view of update compliance across Windows clients, Windows servers, and Microsoft 365 Apps. It shows overall counts of devices in different states across Intune-endpoints and helps teams identify where remediation should be focused. These status categories reflect how quickly devices apply updates based on a configured deployment cadence and internal SLOs. Figure 4: Security update dashboard showing patch status for Windows clients, servers, and Microsoft 365 apps. Microsoft Defender Vulnerability Management surfaces CVEs, affected devices, vulnerable software, and recommended remediation actions, offering a shared view of risk and progress across IT and security teams. Translate Defender recommendations into targeted Intune actions described in the mitigate section, such as updating software or moving devices through expedited remediation workflows so teams can focus on vulnerabilities that are actively exploited or most likely to affect an organization. Extend across your endpoint estate For Apple devices, use the Apple software update report in Intune to monitor update status across macOS, iOS, and iPadOS. For Android, compliance reporting surfaces devices that fall behind on OS version or security patch level. 3. Contain: enforce patch compliance and limit exposure Even with automated deployments and prioritized triage, gaps can remain. Some devices are unsupported, fall behind, operate on slower deployment rings, and others can’t be patched quickly. A patch strategy needs to focus on including containment for those surfaces. Compliance controls, conditional access, and device hardening act as an always-on safety net that limits risks that can fall through gaps. Compliance policies and Conditional Access can use a patch state as a signal for resource access, preventing non-compliant devices from accessing corporate resources. Security baselines reduce the attack surface by limiting risky defaults and common attack patterns. Together, these controls shift enforcement from a periodic activity to a continuous condition across a fleet. Operationalize in Intune and Defender Use compliance policies in Intune to define what "current" means, including minimum OS build, required update levels, risk status, and encryption state. Use Conditional Access (managed in Microsoft Entra, accessible from the Intune admin center) to control access to company resources based on user and device health. Combined with threat signals from Microsoft Defender, these policies help prevent non-compliant devices from accessing corporate resources. Use Microsoft Defender Vulnerability Management and Microsoft Security Exposure Management insights to identify exposed assets, prioritize remediation, and apply recommended protections where patching must move more slowly. Apply Intune security baselines to establish Microsoft-recommended configurations on Windows devices, such as disabling risky defaults, blocking common attack techniques, and reducing configuration drift. Watch this demo on security baselines being applied in the Zero Trust workshop. Use attack surface reduction policies in Intune to deploy Microsoft Defender for Endpoint protections, such as ASR rules and network protection, that help block common attack techniques on devices that can't be patched right away. Figure 5: Watch this Demo on how you can manage devices and implement Conditional Access with Intune. Extend across your endpoint estate Compliance policies and Conditional Access controls apply across Windows, macOS, iOS/iPadOS, and Android. Intune app protection policies extend compliance requirements and data protections to managed apps used for work on personal devices and add an additional layer of data protection on corporate devices. Use the settings catalog and configuration profiles to apply the same hardening intent on macOS, iOS/iPadOS, and Android, reducing configuration drift across platforms. Stay ahead with a patch strategy As vulnerability discovery and response continue to accelerate, organizations need an operational strategy that balances speed, risk, and resilience. By automating updates where possible, prioritizing remediation based on exposure, and limiting exposure through compliance and security controls, teams can reduce risk across their endpoint estate. Intune helps simplify this approach by bringing these capabilities together alongside the rest of your Microsoft security tools and ecosystem. Get started with Microsoft Secure Now to assess risk across your digital estate. Explore the new security update status dashboard in Intune. Harden the admin plane and review the best practices for securing Microsoft Intune. 1 Licensing and requirements Feature availability and included capabilities vary by Microsoft 365 subscription plan and feature. Some Microsoft capabilities referenced in this post may require specific licenses or additional enablement. Advanced Microsoft Intune capabilities are now included in Microsoft 365 E5, with select capabilities available in Microsoft 365 E3 as part of updates effective July 1, 2026. Existing customers will receive a 30-day notice in the Microsoft Admin Center prior to availability, with access beginning by August 2026. Microsoft Security Copilot and related AI capabilities may require separate licensing, learn more here. Stay up to date! Bookmark the Microsoft Intune Blog and follow us on LinkedIn or @MSIntune and @IntuneSuppTeam on X to continue the conversation.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.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.
