Hybrid Autopilot as a Transition Strategy Toward Cloud-Native Endpoint Deployment
Hybrid Autopilot sometimes gets labeled as “legacy.” But in large enterprise environments, it can be a very practical transition architecture toward full cloud-native endpoint deployment. In one global rollout scenario I supported across multiple regions in a large enterprise environment, Hybrid Autopilot played exactly that role — helping modernize deployment while maintaining alignment with existing identity and infrastructure dependencies. Instead of treating Hybrid Autopilot as a long-term destination, we approached it as a controlled stepping stone toward Entra ID–only deployment. The challenge Many multinational environments still rely on: on-prem Active Directory legacy application dependencies region-specific provisioning constraints existing device naming standards network-dependent enrollment scenarios Moving directly to cloud-only join is often the goal - but not always realistic. Hybrid Autopilot helped bridge the gap. What worked well for us Several design decisions helped make Hybrid Autopilot scalable and predictable across regions. Machine-level secure connectivity before user sign-in One important enabler for Hybrid Autopilot in internet-based deployment scenarios was establishing machine-level secure connectivity before user authentication. Allowing devices to reach domain services during provisioning made it possible for offline domain join steps to complete successfully even when devices were deployed outside the corporate network. This supported direct-to-user deployment models without requiring traditional on-premises connectivity during setup, which becomes especially important in large enterprise global rollout scenarios. OEM hardware hash integration enabling deployment tagging and Zero Trust alignment Leveraging OEM-provided hardware hashes allowed devices to be pre-registered into Autopilot before shipment and associated with deployment group tags aligned to regional rollout logic. This enabled a consistent enrollment pipeline across distributed device shipments and created the foundation for automated targeting and naming alignment during provisioning. It also supported a stronger Zero Trust posture by ensuring that only officially procured and pre-registered corporate devices were allowed to enroll through the managed provisioning workflow. This helped reinforce device trust at the enrollment stage and reduced the risk of unauthorized or unmanaged endpoints entering the environment. Country-based deployment tagging Country group tagging then allowed hostname naming alignment to remain consistent with regional standards while enabling policy targeting and configuration logic to scale globally. This helped maintain predictable deployment behavior across regions while supporting large enterprise rollout consistency. Maintaining identity continuity during transition Hybrid join allowed compatibility with existing identity-dependent workflows to remain intact while preparing the environment for future Entra-native deployment approaches. Rather than forcing architectural change everywhere at once, this allowed transformation to proceed in controlled phases across regions. Why Hybrid Autopilot still matters? In large enterprise environments, endpoint modernization rarely happens in a single step. Hybrid Autopilot can support: modernization without disruption phased identity transition planning global rollout consistency alignment with existing provisioning standards preparation for cloud-native endpoint strategies When positioned correctly, it becomes part of the transition journey rather than technical debt. Curious how others are approaching this I’m interested to hear how others in large enterprise environments are using Hybrid Autopilot today. Are you treating it as a long-term deployment model, a transition architecture, or actively moving toward Entra ID–only deployment? It would be great to compare approaches and lessons learned across different enterprise rollout scenarios.Autopilot V1 vs “Device Preparation” (V2): Great direction — but is it enterprise-ready yet?
We evaluated Autopilot v2 but decided to stay on Autopilot v1 for large‑enterprise scale. Group Tags + dynamic groups are still essential for our device naming, segmentation, and governance model. We intentionally limit apps in EAS to speed up provisioning, so EAS‑based app deployment in v2 isn’t a compelling advantage for us. v2 looks promising, but until there’s stronger parity for enterprise‑scale targeting and naming, v1 remains the better fit. Curious how others at scale are balancing provisioning speed vs. segmentation without Group Tags.
Rethinking “Allow my organization to manage my device” Why opt‑in enrollment works better for Intune
By: Ramya B Sharma – Senior Software Engineer | Microsoft Intune A new public preview feature in Microsoft Intune, we’ve introduced a toggle that allows admins to block automatic mobile device management (MDM) enrollment during the modern app sign-in flow on Windows. This enhancement directly responds to frequent customer requests for greater control over device enrollment, specifically the ability to prevent automatic MDM enrollment on Windows devices during app sign-in. While Microsoft Entra generally recommends automatic enrollment by default, most Intune customers - especially those supporting bring your own device (BYOD), mixed ownership, or multi-tenant access scenarios - benefit from an opt-in enrollment model instead. Recommended best practice Keep “MDM user scope” set to All so enrollment is available when needed, but configure the new toggle “Disable MDM enrollment when adding a work or school account on Windows” to Yes so MDM enrollment is not automatically selected by default during app sign in. This ensures devices are enrolled into Intune only through intentional enrollment flows, reducing accidental enrollments, support burden, and difficult recovery scenarios. Learn more: Automatic MDM enrollment in the Intune admin center. Why this matters For years, Windows users signing into work or school apps have been presented with: “Allow my organization to manage my device.” In most environments, this option was selected by default or clicked through without full understanding. That single action could result in: Microsoft Entra device registration Automatic Intune MDM enrollment Immediate policy application to the device For IT teams, this often led to: Unintended device enrollments Personal or BYOD devices becoming fully managed Difficult unenrollment and recovery experiences The new public preview toggle directly addresses these long‑standing issues. How the modern app sign in enrollment flow works When a user signs into a Microsoft work or school app on Windows, Windows may start a device registration flow. Historically, if: Automatic enrollment was enabled, and The user was in the MDM user scope Then registration could immediately turn into full MDM enrollment, even though the user only intended to sign into an app. What the new toggle changes The new setting“Disable MDM enrollment when adding a work or school account on Windows”: Allows account registration Stops the flow before MDM enrollment Removes the “Allow my organization to manage my device” screen from the app sign-in flow Preserves intentional enrollment paths Important: This setting applies to modern app sign in flows, not Windows settings–based enrollment. Allowing enrollment versus forcing enrollment This distinction is critical. Allowing enrollment: MDM user scope is configured to “All” or “Some” Enrollment is available when needed Devices enroll through deliberate flows Forcing enrollment Enrollment triggered implicitly App sign in becomes an enrollment decision Users may not realize the device is managed Recovery is harder later The new toggle lets organizations separate these behaviors. Impact across common Windows enrollment scenarios Scenario Default behavior Opt-in recommended behavior BYOD / personal devices High risk of accidental enrollment App access without device takeover Microsoft Office / Teams sign in May initiate MDM enrollment No MDM enrollment unless user chooses Microsoft Entra hybrid join (corporate) Microsoft Entra joined Microsoft Entra joined Windows settings enrollment MDM enrollment MDM enrollment Windows Autopilot / provisioning MDM enrollment MDM enrollment Security and governance benefits Opt-in enrollment supports: Least surprise Explicit consent Cleaner BYOD posture Safer break glass scenarios Reduced support escalations It also aligns well with Conditional Access and app level protection strategies. When to use the default behavior Default automatic enrollment may still be appropriate for: Fully corporate owned device fleets Locked down environments Dedicated provisioning scenarios The key is that it should be a conscious decision, not an accidental one. Summary In conclusion, for most organizations, the modern best practice is: Allow enrollment everywhere - require intent. Using the new Intune toggle to make enrollment opt-in during app sign in reduces risk, improves user trust, and simplifies the device lifecycle - without sacrificing Intune’s management capabilities. Recommended reading: For a concrete example of the end‑user experience with this model, see Step 6: Understand Microsoft Edge for Business End User Experience for Windows, which walks through how opt‑in enrollment and app‑level management are presented to users in Microsoft Edge for Business. Understand Microsoft Edge for Business End User Experience for Windows. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam!Debunking the myth: Cloud-native Windows devices and access to on-premises resources
By: Roger Southgate - Sr. Product Manager | Microsoft Intune Myth vs reality Myth: Cloud-native Windows devices can’t access on-premises resources such as file shares or legacy applications. Reality: With minimal or no configuration, cloud-native devices can seamlessly access on-premises resources using NTLM or Kerberos. Introduction Microsoft’s vision for secure, productive workplaces is clear: adopt cloud-first services, integrate Zero Trust throughout, and deploy Windows 11 devices as cloud-native endpoints to stay agile and future-ready. If you’re yet to begin this journey, review the Set up and configure a cloud-native Windows endpoint with Microsoft Intune tutorial. For context, a cloud-native device is a Windows device, joined to Microsoft Entra and managed by Intune. No domain join, no group policy, and no Microsoft Configuration Manager required. Leveraging complementary services such as Windows Autopilot and Windows Autopatch enables users to self-provision their devices, work remotely, and remain secure by applying the latest Windows Updates. But what about user’s data, files, and applications that they require to be productive? Moving to the cloud is a common goal for many organizations, though practical realities can make this a gradual process. Legacy technology, operational constraints, complexity, and other challenges can hinder adoption. While the goal might be to migrate all data to cloud-friendly repositories such as SharePoint Online and OneDrive, and transition applications to SaaS solutions, these migrations don’t happen overnight. In many cases, data may remain scattered across internal servers and on-premises repositories, creating scenarios where cloud-native devices still need to connect to these resources. Accessing on-premises resources What happens when you take a cloud-native device and try to access an on-premises resource such as a file share? Similarly, what about access to an application that is located on-premises? While these are just two examples, they can be used interchangeably in this scenario since the process of getting access is the same, regardless of apps or files. This is a topic that is raised (and often misunderstood) when discussing the transition of Windows devices to the cloud. Cloud-native devices were designed to take this scenario into account and have seamless access to on-premises resources. Note: This assumes you have line-of-sight to an Active Directory Domain Controller and that your on-premises resources, such as file shares and applications, use Windows authentication. Like a domain-joined device, a cloud-native device won’t have line of sight by default unless it’s physically on-site (for example, in a corporate office). If you require this functionality, you may need to use a VPN or Zero Trust Network Access (ZTNA) solution to provide this connectivity to on-premises resources. More on this later, when we touch on Microsoft Entra Global Secure Access. Legacy applications and authentication When people talk about legacy applications in this context, they typically mean apps that can only do legacy (NTLM or Kerberos) authentication with Active Directory. The good news is that for users synchronized using Microsoft Entra Connect Sync, cloud-native devices can seamlessly authenticate using NTLM and Kerberos just like domain-joined devices. When an on-premises domain account is synchronized to Microsoft Entra ID via Microsoft Entra Connect Sync, Windows uses details from Microsoft Entra ID, such as the source Active Directory domain name and the user’s User Principal Name (UPN), to locate a Domain Controller the same way an Active Directory domain-joined device does. If the user has signed into Windows using a password, Windows sends the on-premises domain information and user credentials to the Domain Controller to obtain a Kerberos Ticket-Granting Ticket (TGT) or NTLM token, based on the protocol the on-premises resource or application supports. From that point onwards, the TGT is used to get session keys that grant access to resources. Refer to How SSO to on-premises resources works on Microsoft Entra joined devices for additional details on how this process works. Note: Windows 11, version 24H2 and later releases have removed the NTLMv1 protocol as part of Microsoft's broader initiative to phase out NTLM. Refer to the Microsoft support article on Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025 for additional details. Windows Hello for Business Passwordless authentication mechanisms such as FIDO2 and Windows Hello for Business are a cornerstone of Microsoft’s security vision. Adopting these authentication methods delivers stronger security and better, simpler user experiences. Windows Hello for Business provides phishing-resistant credentials as required by some security guidelines such as the Australian Cyber Security Centre ‘Essential Eight’. If you’re not already doing so, deploying cloud-native devices is a great opportunity to start using Windows Hello for Business, especially since it’s enabled by default on these devices. Windows Hello for Business is also a feature which results in a win-win scenario by enhancing security for IT, while also improving the user experience. While enabling Windows Hello for Business is a simple process, there’s some additional configuration required to enable single sign-on to on-premises Active Directory authenticated resources, and this is where we sometimes see customers running into issues. If username and password work successfully to access an on-premises resource, but Windows Hello for Business credentials don’t then ensure that you’ve setup Cloud Kerberos trust to enable single sign-on. Cloud Kerberos Trust removes much of the complexity once associated with configuring Windows Hello for Business, greatly simplifying the deployment process. When signing in with Windows Hello for Business, the device uses a partial Kerberos TGT issued by Microsoft Entra ID to obtain a full TGT from Active Directory, which in turn is used to get session keys to access resources. Refer to Microsoft Entra join authentication to Active Directory using cloud Kerberos trust for additional details. Zero Trust and modern connectivity On your Zero Trust journey, if you need to provide access to on-premises applications and services, consider replacing your traditional VPN with a modern solution, enabled by Microsoft Entra Private Access. Doing so will help you ensure secure, fine-grained access to private applications and resources, without exposing your full network - aligned with Microsoft’s three Zero Trust principles: verify explicitly, enforce least privilege, and assume breach. Review Zero Trust and Cloud-Native Windows for a deeper dive into this topic. On the subject of Zero Trust, did you know that Microsoft has developed a Zero Trust Workshop? By adopting Zero Trust, your organization can enhance its security posture and reduce risk and complexity while improving compliance and governance. Navigating the complexities of modern security is challenging and a Zero Trust strategy is the first step in providing clarity and direction. The Zero Trust Workshop is a guided framework to help you translate your Zero Trust strategy into actionable implementation steps which track your deployment progress and align with Microsoft recommendations. We’ve had many customers leverage the workshop to supercharge their Zero Trust journey and realize the full value of their existing security investments. The workshop can be run self-guided or in collaboration with your Microsoft account team or a partner and is vendor agnostic. Key takeaways If you aren’t already provisioning new Windows devices as cloud-native, check out Set up and configure a cloud-native Windows endpoint with Microsoft Intune and Cloud-native Windows endpoints: Begin by beginning to get started with a cloud-native Windows proof of concept today. Cloud-native doesn’t mean cloud only, these devices get the benefits of being cloud-first while maintaining the backward compatibility needed to access on-premises resources when necessary. Modern identity solutions such as Microsoft Entra ID, Windows Hello for Business, and Zero Trust Network Access can simultaneously enhance security and user experience. Be sure to check out our Zero Trust Workshop to help you plan and implement these and other technologies as part of your Zero Trust strategy. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam!
