Preparing for end of support for CNAME auto-discovery in Windows MDM-only enrollment
Today, some organizations use an EnterpriseEnrollment DNS CNAME record to automatically direct devices to the Microsoft enrollment service during Windows MDM-only enrollment. Starting January 15, 2027, as part of our ongoing efforts to simplify and modernize enrollment experiences, Microsoft Intune will end support for CNAME-based auto-discovery in Windows MDM-only enrollment scenarios. This change reduces dependency on DNS-based discovery while providing a more consistent enrollment experience moving forward. After this change, users may need to enter the Microsoft enrollment server URL if it’s not already provided by the enrollment experience: https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc Who this change affects Your organization may be affected if: You use Windows MDM-only enrollment. You have configured an EnterpriseEnrollment DNS CNAME record. Your enrollment process depends on DNS record to automatically discover the enrollment service. You likely aren't affected if you exclusively use: Microsoft Entra join enrollment Microsoft Entra hybrid join enrollment Other enrollment methods that don't rely on EnterpriseEnrollment CNAME discovery How the user experience will change Today, in affected environments, a user can begin Windows MDM-only enrollment, and the enrollment service is automatically discovered using the organization’s EnterpriseEnrollment DNS CNAME record. The user doesn’t need to provide the enrollment server information. After this change, CNAME-based auto-discovery will no longer be used for these Windows MDM-only enrollment scenarios. If the enrollment service URL isn't already provided by the enrollment experience, the user will need to enter it when prompted. Enrollment can then continue using the Microsoft enrollment service URL. For example: Identifying affected environments Review your organization's DNS configuration and Windows MDM-only enrollment documentation.In particular, look for an EnterpriseEnrollment DNS record similar to: EnterpriseEnrollment.contoso.com If your organization configured the EnterpriseEnrollment record to support Windows MDM-only enrollment discovery, you should prepare for this change. You should also review and update documentation that assumes enrollment service discovery happens automatically through DNS, including: Internal enrollment guides Help desk procedures Device deployment instructions Provisioning documentation User onboarding materials Actions to take if you’re affected To prepare for this change we recommend the following actions: 1. Identify impacted enrollment workflows Review all Windows MDM-only enrollment scenarios used within your organization and determine whether they depend on EnterpriseEnrollment DNS discovery. 2. Update enrollment documentation Update user guides, knowledge base articles, onboarding materials, and other instructions to reflect the new enrollment process. 3. Prepare support teams Ensure help desk and deployment teams understand the change and know when the enrollment service URL may need to be provided. 4. Test enrollment scenarios Validate affected enrollment workflows before the change takes effect. Identify any required updates and determine where users may be prompted to enter the enrollment service URL. 5. Communicate with impacted users If users will need to enter the enrollment service URL, provide updated instructions before the change takes effect. Frequently asked questions Does this affect existing enrolled devices? No. Existing enrolled devices remain enrolled and aren’t affected by this change. Is Windows MDM-only enrollment being retired? No. Windows MDM-only enrollment remains supported. Only CNAME-based auto-discovery will become unsupported. Do I need to remove my EnterpriseEnrollment DNS record? Review your environment and DNS configuration requirements. This change only affects use of the record for Windows MDM-only enrollment auto-discovery. Will every user need to enter the enrollment service URL? Not necessarily. Some enrollment experiences may already provide enrollment server information. Manual entry is only required when the enrollment experience doesn’t provide it automatically. Should we begin testing now? Yes. We strongly recommend validating enrollment scenarios as early as possible and updating relevant documentation before this change takes effect. Next steps Review your Windows MDM-only enrollment processes and identify any dependencies on EnterpriseEnrollment DNS CNAME records. Update enrollment guidance, deployment instructions, onboarding materials, and help desk procedures that assume the enrollment service will be discovered automatically through DNS. Stay tuned to this blog for updates. If you have any questions, leave a comment below.
Proposal: Microsoft Motion – Core 2D Animation Studio for M365
Dear Microsoft Team, Following Microsoft Canvas, I propose Microsoft Motion: an independent core application for native 2D animation and motion graphics in Microsoft 365. Key Architecture: Ultra-Lightweight Core: Low-resource engine for fast keyframe animation, GIFs, and educational graphics. Modular Add-ons: Optional power tools for creators (2D character rigging, pixel animation, VFX). Seamless Canvas Integration: One-click asset pipeline between Canvas and Motion. This creates a unified, high-performance creative ecosystem for M365 without system bloat. Contact for technical discussions: email address removed for privacy reasons Best regardsProposal: Microsoft Canvas - Unified Creative Tool
Proposal: Unified Creative Suite & Performance Solutions The Concept ("Microsoft Canvas"): A lightweight application for Microsoft 365 that unifies Pixel Art, Vector Graphics, and Freehand Painting in a single engine. Designed for indie game developers, content creators, and designers. Technical & Structural Solutions: Custom Workspaces: Users select their target drawing style (Pixel, Vector, or Hybrid) at startup. The app loads only the required rendering engine, saving memory and CPU resources. Modular Packages: Keep the base app light and install extra toolsets/modules as on-demand packages. The "Fullness" Concept: A smart fill system that applies multi-toned textures, shading, and gradients as a cohesive object in one step. Impact: Bridges the gap between productivity and creative game/art design in M365, driving adoption among indie creators. Contact for feedback or technical discussions: [email address removed for privacy reasons]Introducing device association for Windows Autopilot device preparation
By: Maggie Dakeva, Senior Product Manager - Microsoft Intune We’ve heard organizations want Windows deployment to be simple for employees and predictable for IT admins. But before a device enrolls, how does the organization know that the device is really one of its own - and how can IT make sure the right experience and policy reach that device regardless of who signs in? Today, we're announcing device association for Windows Autopilot device preparation, a new way to bind a physical Windows 11 device to your organization before enrollment begins. Device association uses hardware-backed attestation to create a trusted relationship between the device and your tenant at the start of the provisioning journey. That relationship helps Windows Autopilot device preparation recognize the device during the out-of-box experience (OOBE), automatically treat it as corporate-owned, and apply the experience and policy intended for that specific device. The result is a more secure, more consistent, and more device-centric onboarding flow. Start with the device, not just the user Windows Autopilot device preparation already gives IT teams a straightforward way to configure new Windows devices with the apps, scripts, and policies employees need. Device association extends that experience by allowing IT to target a device preparation policy directly to a device before it enrolls. This is especially valuable when the deployment experience needs to follow the hardware rather than the person signing in. For example, one employee can enroll multiple devices that serve different purposes, and each device can receive its own device preparation policy. When both device-based and user-based assignments are available, the device-based assignment takes precedence. That gives administrators greater confidence that the correct configuration reaches the correct device from the beginning of its lifecycle. Create a simpler out-of-box experience Because an associated device is recognized before enrollment, IT can configure more of the Windows setup experience in advance. Device association enables organizations to: Configure Language and region. Automatically configure the keyboard and skip the keyboard selection page. When the device uses a Wi-Fi network connection during OOBE, the language and keyboard selection screens aren't hidden. Hide the Microsoft Software License Terms page. Hide privacy settings during OOBE. Apply a device name template that uses the serial number or a randomized value. Hide account-change options on company sign-in and domain error pages. These controls reduce the number of decisions an employee must make while setting up a device and help create a consistent, organization-ready experience from the first screen. Strengthen trust before enrollment Device association isn't only an experience improvement. It establishes device trust earlier in the deployment process. The association uses hardware-based attestation and TPM-backed cryptographic validation to verify the device's identity. Tenant affinity is stored in the device's UEFI firmware, where it persists across a Windows reset, operating system reinstallation, or removal of enrollment. This durable, hardware-backed relationship helps ensure that the device presenting itself for preparation is the device the organization intended to onboard. Associated devices are also automatically marked as corporate-owned. If your organization blocks personally owned Windows devices with Intune enrollment restrictions, device association can be used instead of uploading a separate corporate identifier. You can continue to use corporate identifiers where they fit your process, but an associated device doesn't need both. How the device association flow works Device association is designed as a clear workflow that starts with IT and finishes automatically during OOBE: Create the device preparation policy. Configure the apps, scripts, deployment settings, OOBE experience, and optional device name template that should apply. Export the device information. During OOBE, a technician opens the Autopilot menu and exports the DeviceLink CSV with the device information required for pre-association to a USB. For an existing device, the same information can be collected from Autopilot diagnostic logs. Figure 1. The Windows Autopilot menu with Assign device association selected. ormation was exported to a removable drive. Pre-associate the device in Intune. In the Microsoft Intune admin center, go to Devices > Enrollment > Device association > Devices, upload the CSV, and optionally assign a device preparation policy directly to the device. Complete association. When the device connects to a network in OOBE, it finds the pre-association record and completes association automatically. A technician can also trigger this step manually from the Autopilot menu. Enroll and prepare the device. The device receives the applicable device-targeted policy, is marked as corporate-owned, and presents the configured OOBE experience. Monitor the deployment. Administrators can review association state and assigned policy in the Device association blade and filter devices by state, policy, manufacturer, or model. The device association lifecycle consists of the following states: Pre-associated: The device was added on the service side and is waiting to complete association in OOBE. Associated: The device completed association by writing the tenant affinity to UEFI and is ready for enrollment. This happens automatically when a pre-associated device syncs with an MDM provider. Pending removal: A request to remove the pre-association is being processed. A device's association can be removed by an administrator or partner with physical access to the device who manually runs a local script that clears the tenant affinity information stored in the device's UEFI. This action should be performed only when the device should no longer be associated with the organization, such as when it is sold, recycled, or transferred. Manage the full device lifecycle The association remains with the device through reset and reinstallation, helping preserve the organization's intended provisioning path when a device is redeployed internally. When a device permanently leaves the organization - for example, when it's sold, recycled, or transferred—the association should be removed as part of decommissioning. Because the tenant affinity is stored on the device, clearing a completed association can be performed via script locally on the physical device, without access to the service. This lifecycle model is intentional: association is durable during normal reuse inside the organization, while permanent removal can be completed by an admin or partner who has control of the physical device. Designed to work alongside your existing Windows Autopilot strategy Device association is part of Windows Autopilot device preparation and can coexist with traditional Windows Autopilot deployments in the same organization. For a device already registered with Windows Autopilot, the association state determines which deployment runs. If the device isn't associated, its Windows Autopilot registration takes precedence. If it is associated, the Windows Autopilot device preparation deployment takes precedence. This gives organizations a practical path to introduce device association while continuing to support existing Windows Autopilot investments. Get started To use device association, you'll need a supported physical Windows 11 device with TPM 2.0 enabled and in a healthy state. Virtual machines aren't supported because device association relies on hardware-backed identity verification. Start by reviewing the Windows Autopilot device association requirements, then create or update your Windows Autopilot device preparation policy. From there, export the device information, pre-associate the device in Intune, and let Windows complete the trusted association during OOBE. With device association, Windows Autopilot device preparation moves device trust, targeting, and customization earlier in the deployment journey - before enrollment and before the employee reaches the desktop. That means fewer setup decisions for users, more predictable deployments for IT, and stronger confidence that the right device is joining the right organization with the right configuration. Learn more Overview of Windows Autopilot device association Requirements for Windows Autopilot device association Set up Windows Autopilot device preparation with device associationMoving from Windows Autopilot to Windows Autopilot device preparation
By: Maggie Dakeva, Senior Product Manager - Microsoft Intune Organizations have spent years refining Windows Autopilot deployments. Profiles, Enrollment Status Page settings, group tags, dynamic groups, application assignments, and support processes all work together to deliver a familiar provisioning experience. Windows Autopilot device preparation is a re-architecture of Windows Autopilot designed around the customer asks we hear most often: simpler configuration, faster and more reliable setup, clearer progress for users, and near real-time deployment reporting for administrators. A single device preparation policy brings deployment and the out-of-box experience (OOBE) settings together, enrollment time grouping (ETG) places devices into the right security group during enrollment, and granular application and PowerShell script status makes troubleshooting easier. Autopilot device preparation is now the recommended solution for user-driven scenarios. Future engineering investments will focus on Windows Autopilot device preparation, enabling organizations to benefit from ongoing improvements to provisioning, reliability, reporting, and support. Moving eligible deployments positions your organization to benefit from those ongoing improvements while reducing the complexity of provisioning and support. So how do you move without disrupting devices that are already working - or forcing every deployment scenario to transition at once? The answer is a phased approach. Windows Autopilot and Windows Autopilot device preparation can coexist in the same organization. You can move eligible user-driven Microsoft Entra join populations in controlled waves, validate the full experience, and keep scenarios that still require Windows Autopilot on their existing path. The result is a practical way to adopt a simpler provisioning model while protecting the investments and workflows your organization still depends on. Start with the outcome, not a one-for-one migration Windows Autopilot device preparation brings enrollment settings, OOBE, device naming, required applications, PowerShell scripts, and enrollment-time targeting into a more coherent policy flow. The device preparation page, which replaces the Enrollment status page, gives users clearer progress and gives administrators more detailed deployment status for troubleshooting. Windows Autopilot device preparation includes two complementary capabilities: Device preparation policy defines the deployment experience, including OOBE settings, applications, scripts, naming, and ETG. Device association optionally binds a physical device to your organization before enrollment. It can establish corporate ownership and tenant affinity, enable associated-device OOBE settings, and support direct per-device policy assignment. Based on organizational needs, customers can choose to use device preparation policy, device association, or both. Device preparation policy provides the deployment configuration and experience, while device association adds pre-enrollment device affinity and device-based capabilities. Organizations can adopt each capability where it adds value to their provisioning model. But moving to that model shouldn't mean recreating every Windows Autopilot object exactly as it exists today. Instead, begin with the outcome each device population needs. Identify the required OOBE behavior, applications, scripts, naming, assignments, and support experience. Then design the device preparation policy and ETG model that delivers that outcome. This approach reduces inherited complexity and helps ensure that the new deployment is designed for Windows Autopilot device preparation and not constrained by the architecture it replaces. Choose what moves - and what stays Windows Autopilot device preparation is the recommended path for eligible user-driven provisioning scenarios, including: Corporate-owned Windows 11 devices User-driven Microsoft Entra join Windows 365 Continue using Windows Autopilot for scenarios that aren't supported or recommended for transition, including: Pre-provisioning Self-deploying mode Hybrid Microsoft Entra join Autopilot into co-management This isn't an all-or-nothing decision. The right transition plan deliberately separates eligible populations from valid exceptions. Translate the provisioning model Several familiar Windows Autopilot concepts have a corresponding role in Windows Autopilot device preparation: Windows Autopilot Concept Windows Autopilot Device Preparation Model Deployment profile Device preparation policy Enrollment Status Page profile Device preparation policy Enrollment Status Page in OOBE Device preparation page in OOBE Windows Autopilot registration Optional device association Profile and dynamic group-based targeting based on group tags Granular device preparation policy assignment with enrollment time grouping (ETG) using Microsoft Entra static security groups Device name template defined in the Autopilot deployment profile Device name template defined in the device preparation policy Windows Autopilot deployments report Windows Autopilot device preparation deployments report The goal is to preserve the required customer and administrator experience - not every historical configuration object. How the transition flow works A controlled transition can follow eight steps: Define the eligible population: Start with corporate-owned Windows 11 devices using user-driven Microsoft Entra join. Exclude scenarios that should remain on Windows Autopilot. Design enrollment time grouping (ETG): Create assigned, static Microsoft Entra security groups for populations that genuinely differ by location, role, device type, or required configuration. Don't build the new design around a group tag or a device object that must exist before enrollment. Create device preparation policy equivalents: Inventory each deployment profile and Enrollment Status Page pairing. Map the required OOBE settings, naming, applications, PowerShell scripts, blocking requirements, and dependencies into the new device preparation policy. Evaluate whether device association is required for all scenarios. For user-targeted deployments that don't need pre-enrollment tenant affinity or per-device policy selection, the organization can use the device preparation policy without device association and simplify the setup and management of device onboarding. For devices that need automatic corporate ownership, OOBE customization settings, or stronger pre-enrollment trust, continue with step 5. Pre-associate eligible devices. For existing registered or enrolled devices, collect the pre-association information by collecting the diagnostics logs, then exporting the DeviceLink CSV file found in the logs. Upload the CSV in the Associated devices blade in Intune and assign a device preparation policy to the device. Assignment can be done during the CSV upload process or after. Confirm that the device reaches the Pre-associated state before its planned reset or refresh. Note: Device pre-association is only available for devices that meet the minimum OS and hardware requirements , including TPM 2.0. Pilot the complete OOBE experience. Start with new devices or reset a small, representative set of devices. Validate policy selection, ETG placement, applications, scripts, naming, progress reporting. Expand and pre-associate remaining devices. Pre-associate additional populations in controlled waves. You do not need to force resets to all existing enrolled devices but simply pre-associate to prepare them so they enroll via the Windows Autopilot device preparation flow whenever each device next undergoes a natural or required reset. Retire registered flows. Retire deployment profiles, Enrollment Status Page profiles, groups, registrations, and processes only after reporting confirms that no active or planned population still depends on them. Pre-association doesn’t reset the device or disrupt its current use. The device remains enrolled and productive until its next natural or required reset, when Windows Autopilot device preparation takes effect. Don't remove the Windows Autopilot registration early. Doing so can remove Autopilot properties and affect dynamic-group membership that supports the device's current configuration. The next time the device enters OOBE, Windows recognizes the association and follows the Windows Autopilot device preparation path. If a device is both registered and associated, association takes precedence. Plan the pilot around this behavior rather than expecting an automatic fallback to Windows Autopilot. OEM and partner note: Device association uploads are currently only supported through Intune. OEM and partner pre-association scenarios aren't supported yet, but they’re on the roadmap. What this means for your organization You can prepare existing devices for transition while they remain enrolled and in use. You can move one eligible population at a time instead of committing to an organization-wide cutover. You can preserve Windows Autopilot for scenarios that still require it. You can use the transition to simplify assignment and provisioning logic rather than carry every legacy object forward. You can retire the old configuration gradually - after validation and dependency checks confirm that nothing still relies on it. A sample customer pilot setup scenario Consider a multinational organization, Contoso, that uses group tags to distinguish devices in the United Kingdom and Germany and to identify different device use cases. Dynamic groups use those tags to determine which deployment profile, Enrollment Status Page configuration, applications, policies, scope tags, and naming rules apply. The organization wants to move its eligible user-driven Windows 11 populations to Windows Autopilot device preparation without reproducing the same pre-created record and dynamic-group dependencies. The Contoso deployment team transitions to Autopilot device preparation with the following steps: Create static security groups for each required configuration. The team creates assigned Microsoft Entra security groups such as User Devices UK and User Devices Germany. It creates separate groups only when location, role, device type, scope, or required configuration differs. Create a device preparation policy for each population. The team creates a policy such as User Devices UK DPP and User Devices Germany DPP. Each policy contains the required OOBE settings, applications, PowerShell scripts, blocking behavior, and device name template, and identifies the corresponding enrollment time grouping (ETG) security group. Assign the device preparation policies to each population. The team assigns each device preparation policy to the respective sets of devices at time of pre-association or later. During enrollment, the device joins the group selected by the device preparation policy. For example, devices assigned the User Devices UK DPP join the User Devices UK group and receive the apps and policies assigned to that group. Configure scope through the static groups. The team assigns the appropriate regional scope tag to each ETG security group. The device receives the associated scope tag when it joins the group during enrollment. Set a naming template for each device preparation policy. The organization uses a naming convention where devices start with a prefix indicating their location. The team sets UK-%SERIAL% in User Devices UK DPP and DE-%SERIAL% in User Devices Germany DPP. Pre-associate pilot devices without disruption. Selected devices can be pre-associated while they remain enrolled and in use. The team collects diagnostics logs via script, extracts the DeviceLink CSV files, imports them in Intune, confirms the devices reach the Pre-associated state, and keeps the Windows Autopilot registration in place until the approved reset or refresh window. Validate the end-to-end experience with representative devices. The admin team uses test devices representing each target population to verify policy assignment, static group membership, scope tags, naming, applications, scripts, reporting, and successful completion of the device preparation flow. Existing devices can remain in service until their next natural or required reset. Seven-step regional Windows Autopilot device preparation rollout workflow, from creating security groups and device preparation policies through regional configuration, pilot association, and device validation. This scenario is illustrative, not a completed deployment or a measured customer outcome. It shows the transition pattern: define the supported scope, replace group-tag dependencies with ETG, move Enrollment Status Page and deployment profile settings to the device preparation policy, decide where device association adds value, validate end to end, and expand in controlled waves. Get started Begin with one eligible user-driven Microsoft Entra join population. Map its current Windows Autopilot outcomes to enrollment time grouping (ETG) and a device preparation policy. Pre-associate a representative pilot, validate the complete reset-to-desktop experience, and expand only when the results meet your deployment and support criteria. Moving to Windows Autopilot device preparation doesn't require a forced cutover. It requires a clear boundary, a deliberately redesigned assignment model, and evidence from each wave. That gives IT a controlled path toward simpler provisioning while keeping every device population on the experience that supports it best. Learn more Windows Autopilot device preparation overview Compare Windows Autopilot device preparation and Windows Autopilot Windows Autopilot device preparation user-driven Microsoft Entra join workflow Windows Autopilot device preparation requirements We’d love to hear your feedback! Share your thoughts in the comments below, follow us on LinkedIn or reach out to us on X @IntuneSuppTeam or @MSIntune.Microsoft Intune Settings Catalog updated to support Windows 11, version 26H2
10.06.26 Update: The Windows security baseline for Windows 11, version 26H2 is now available for all customers in Microsoft Intune. This baseline reflects current Microsoft security recommendations and is the latest available Windows security baseline in Intune. Windows 11, version 26H2 is now available, and Microsoft Intune provides day zero support for validated Windows policy settings in the settings catalog. We continue to invest in the settings catalog infrastructure to ensure timely support for new Windows policy settings. This enables organizations to adopt new OS versions and features without delay and maintain secure, compliant, and well-managed environments. Settings catalog support for Windows 11, version 26H2 As part of Windows 11, version 26H2 settings catalog support, the settings catalog now includes all newly released settings and updates to existing settings introduced with the latest Windows 11, version 26H2 release. The following table highlights settings that are now available for configuration in the settings catalog and ready to use in device configuration profiles for Windows endpoints. While this update aligns with Windows 11, version 26H2 support, not every setting listed is a new 26H2 feature; some are existing Windows settings that are now available for management through the settings catalog. Category Policy Name Friendly Name Above Lock ConfigureAudioOnLockScreen Configure Audio On Lock Screen Application Management EnableMsixAllowedZones Enable MSIX Allowed Zones Device Lock ClearTextPassword Clear Text Password Device Lock RelaxMinimumPasswordLengthLimits Relax Minimum Password Length Limits Printers ConfigureWindowsReadyPrintDriverRanking Configure Windows Ready Print Driver Ranking Privacy LetAppsAccessForegroundText Let Apps Access Foreground Text Privacy LetAppsAccessForegroundText_ForceAllowTheseApps Let Apps Access Foreground Text – Force Allow These Apps Privacy LetAppsAccessForegroundText_ForceDenyTheseApps Let Apps Access Foreground Text – Force Deny These Apps Privacy LetAppsAccessForegroundText_UserInControlOfTheseApps Let Apps Access Foreground Text – User In Control Of These Apps Windows Update IgnoreWindowsUpdateGroupPolicies Ignore Windows Update Group Policies Windows Update SetMaxPauseDays Set Max Pause Days What this means for administrators Administrators can find the new settings within the settings catalog in the Microsoft Intune admin center under Devices > Manage devices > Configuration > Create > New policy. Select Windows 10 and later for the platform and settings catalog for the profile type. Before deploying Windows 11, version 26H2: Review the new and updated settings that apply to your organization. Test configuration profiles with a representative device group. Confirm that the targeted Windows edition and version support each setting. Monitor profile deployment and device status after assignment. Windows 11, version 26H2 security baseline Windows 11 version 26H2 security baseline will also be made available shortly in Intune. We are validating the final recommendations and plan to make the updated baseline available over the coming days following the Windows 11, version 26H2 release. The current baseline includes: A new recommendation for Configure Windows Ready Print driver ranking. An updated Turn off encryption support recommendation that changes the supported Transport Layer Security versions from TLS 1.1 and 1.2 to TLS 1.2 and 1.3. Configure NetBIOS settings - This setting is pending availability in the settings catalog and will be added to the baseline in a future update. Learn more Create a policy using settings catalog in Microsoft Intune Windows 11 - release information Learn about Intune security baselines for Windows devices We welcome your feedback. If you have questions about these settings or Windows 11, version 26H2 management in Intune, leave a comment on this post or follow us on LinkedIn or @MSIntune and @IntuneSuppTeam on X to continue the conversation. Post updates: 10/06/26: The Windows security baseline for Windows 11, version 26H2 is now available in Microsoft Intune. We’ve also updated this post with the Settings Catalog additions introduced as part of Windows 11, version 26H2 support.Windows 11, version 26H2 security baseline
Update: The Windows 11, version 26H2 security baseline has been updated to reflect the general availability of Administrator protection. An updated v2 package is now available, and organizations should review and test the existing Administrator protection configuration as appropriate for their environment. 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 since the Security baseline for Windows 11, version 25H2 to further strengthen enterprise security and align the baseline with current platform capabilities and industry standards. Security Policy Change Summary Printer\Configure Windows Ready Print driver ranking Configured as “Enabled” to reduce reliance on third-party print drivers in the stack, narrowing the overall print driver attack surface. Internet Explorer\Internet Control Panel\Advanced Page\Turn off encryption support Updated from TLS 1.1 and TLS 1.2 to TLS 1.2 and TLS 1.3 to align with current security standards. User Account Control: Configure type of Admin Approval Mode (updated) Configured as “Admin Approval Mode with Administrator protection” to enable Administrator protection. User Account Control: Behavior of the elevation prompt for administrators running with Administrator protection (updated) Configured as “Prompt for credentials on the secure desktop” to require credential verification for administrative elevation. Windows Ready Print driver ranking Configure Windows Ready Print driver ranking" is the newly added setting under Administrative Templates\Printers to control whether Windows prefers the modern inbox IPP class driver over third-party OEM drivers when installing new printers. We recommend enabling this policy to reduce reliance on third-party print drivers in the stack, narrowing the overall print driver attack surface. Note that driver ranking applies when printers are installed via a connection method that supports IPP, such as USB or network multicast discovery. In those cases, if the printer supports IPP, Windows will install using the class driver even if a vendor V3/V4 driver is available. If the printer doesn't support IPP, or is installed directly as a TCP/IP printer, there's no change in behavior. Encryption Support We have updated the policy "Turn off encryption support" to allow only TLS 1.2 and TLS 1.3. Previous baseline releases permitted TLS 1.1 and TLS 1.2; however, TLS 1.1 is now considered obsolete and is no longer recommended for enterprise environments. This change aligns the security baseline with modern cryptographic standards while maintaining compatibility with widely deployed services that support current TLS versions. Administrator Protection (update) Administrator protection is now generally available. Organizations can enable it through Microsoft Intune or Group Policy. Important: Organizations should review and test their existing configuration and adjust these settings as appropriate for their environment. The security baselines for Windows 11, versions 24H2, 25H2, and 26H2 include settings that enable Administrator protection. The following policies are part of the security baseline: User Account Control: Configure type of Admin Approval Mode User Account Control: Behavior of the elevation prompt for administrators running with Administrator protection An updated v2 package has been published for Windows 11, version 26H2, to reflect this change. Please let us know your thoughts by commenting on this post or through the Security Baseline Community.Windows Update certificate rotation in 2027
Some certificates used to establish trusted connections to Windows Update will expire on May 17 and June 19, 2027. While Microsoft is delivering solutions for most devices through normal monthly updates, some Windows versions will need IT action. Read the announcement and recommendations: Prepare for Windows Update certificate rotation in 2027. Questions? Leave us a comment below.
