An identity architect’s perspective on device trust, passwordless authentication, endpoint management and the migration choices that matter.
An employee can spend most of the working day in Microsoft 365 and browser applications while their Windows laptop still depends on an Active Directory domain. That arrangement can work well. It can also leave IT maintaining device dependencies that no longer match how people work.
From an identity architecture perspective, that is the reason to reconsider the join model. Microsoft Entra join connects a company Windows device directly to Microsoft Entra ID. Combined with a management platform such as Intune, it provides a foundation for provisioning and operating endpoints through cloud services.
My argument for the move centres on reducing dependencies, making access controls explicit and building a repeatable device lifecycle. The benefits become clearer when we look beyond the join operation itself.
Start with the device trust relationship
Three states are worth distinguishing:
AD joined: the Windows device belongs to an Active Directory domain.
Microsoft Entra hybrid joined: the device retains AD domain membership and also has an identity in Microsoft Entra ID.
Microsoft Entra joined: the device joins Microsoft Entra ID directly, without AD domain membership.
Device identity and user identity are separate decisions. An Entra joined device can be used by a person whose account is still synchronised from AD. Moving the laptop does not automatically change the user’s identity source or retire the directory. Microsoft’s join planning guidance explains these design considerations.
Management is another separate relationship. Entra join establishes device identity; Intune enrolment enables management. A device can be joined without having the applications, configuration or compliance policies it needs. Microsoft Entra join overview.
Reduce the endpoint’s dependency on the domain
With Entra join, the endpoint no longer needs an AD computer account and domain trust relationship for its Windows device identity. This removes a layer of domain membership administration from that device’s lifecycle.
For distributed organisations, the practical opportunity is substantial. New devices can be provisioned through cloud services, and Intune-managed applications and policies can reach devices over internet connectivity. Office location becomes less important to provisioning and ongoing management. Microsoft’s cloud-native endpoint guidance describes this operating model.
This does not make every workload independent of the corporate network. A laptop may still need a VPN for an internal application. The architectural gain is the ability to separate that application’s dependency from the device’s primary identity and management requirements.
Hybrid join remains useful where domain dependencies are real. I would give those dependencies an owner and an exit condition, so the device architecture evolves alongside the applications.
Understand how the Windows session supports cloud SSO
On a supported Entra joined Windows device, the Cloud Authentication Provider, or CloudAP, participates in obtaining a Primary Refresh Token during user authentication. The Windows Web Account Manager, or WAM, can use that PRT to request tokens for supported applications.
That is part of the mechanism behind single sign-on to Microsoft 365 and other integrated applications. It reduces repeated credential entry while allowing application access to remain subject to policy.
Where supported and available, the TPM protects cryptographic keys used to secure the PRT and its requests. This improves resistance to credential theft and replay; it does not make every application token immune to theft. Microsoft’s PRT documentation explains the protections and token flows.
PRTs and cloud SSO also work on supported hybrid joined devices. Entra join provides these capabilities without retaining the endpoint’s AD domain membership.
Make passwordless sign-in part of the design
Windows Hello for Business replaces password-based sign-in with an asymmetric credential bound to the device. The user unlocks that credential with a PIN or supported biometric gesture. The PIN stays on the device; it is not a reusable network password sent to an identity provider.
A TPM-backed deployment protects the private key in hardware. This gives employees a convenient sign-in experience while reducing reliance on a password that could be phished and reused elsewhere. Windows Hello for Business overview.
I would plan enrolment, credential recovery and replacement-device onboarding together. Passwordless authentication becomes operationally useful when the service desk can support the full lifecycle.
Windows Hello for Business also supports hybrid deployments. Moving to Entra join simplifies the surrounding device architecture; the credential and recovery policies still need deliberate configuration.
Make application access depend on evaluated device state
The useful security outcome comes from connecting several controls. Intune evaluates device configuration against compliance requirements. Microsoft Entra Conditional Access can then use the reported compliance state alongside other signals when deciding whether to grant application access.
For example, a policy design might require a compliant Windows device and phishing-resistant authentication for a sensitive application. The compliance policy supplies the device criteria; Conditional Access enforces the access decision. Joining the device alone supplies neither policy. Intune compliance overview; Conditional Access overview.
One detail deserves attention during deployment: how the tenant treats devices with no compliance policy assigned. Microsoft recommends treating them as noncompliant when compliance is used for Conditional Access. Otherwise, an unassigned device can be considered compliant without meeting your intended baseline.
These controls also need sequencing. A newly migrated device must be able to enrol and receive its policies before it can satisfy the intended access requirements. Test that transition in a pilot.
Conditional Access for cloud applications is not a universal control over Windows sign-in or unlock. Microsoft documents that Conditional Access is not evaluated at PRT issuance or renewal. Keep local sign-in policy and application access policy distinct. PRT behaviour.
Replace accumulated policy with an intentional baseline
An endpoint migration is an opportunity to review the configuration that the business still needs.
Microsoft Intune Group Policy analytics can import GPO reports, identify settings with MDM equivalents and highlight unsupported or deprecated settings. Supported settings can be moved into Settings Catalog policies. It is a useful starting point for assessing the work; it does not prove that the resulting configuration will behave identically. Group Policy analytics.
I would classify existing settings as retain, replace or retire. Essential controls need a tested target policy. Application-specific settings need an owner. Obsolete configuration should have a reason to survive the move.
The technical benefit is a more understandable management baseline, with clearer policy ownership and fewer overlapping sources of configuration. An in-place migration also needs checks for settings left behind by the previous management model.
Local administrator rights deserve a separate review. Some join workflows can grant the joining user local administrator membership. Configure the intended account type and privilege model explicitly. Managing local administrators on Entra joined devices.
Keep on-premises access where it is still required
An Entra joined device can still access supported AD-backed file shares, printers and applications using the user’s identity. Microsoft’s documented SSO model requires the relevant identity information to be synchronised and network connectivity to domain controllers. Remote access may therefore still require a VPN. On-premises SSO from Entra joined devices.
Windows Hello for Business cloud Kerberos trust provides a way to use passwordless credentials with supported on-premises resources. It requires Microsoft Entra Kerberos configuration and the relevant Windows, domain controller and policy prerequisites. Domain controllers still participate in the on-premises authentication path. Cloud Kerberos trust deployment guidance.
The distinction that often determines readiness is user authentication versus computer authentication. A file share using the user’s AD identity may remain accessible. An application or network access design that requires the endpoint’s AD computer account needs redesign, because that domain membership no longer exists.
I would therefore examine machine authentication, certificate issuance, Wi-Fi, VPNs, printing and privileged administration workflows before assigning a device to a migration wave. Device migration can proceed ahead of full AD retirement, provided those remaining dependencies are understood.
Prove the target state in a representative pilot
My acceptance criteria would cover identity, management, access and recovery.
For identity diagnostics, run the following in the affected user’s session:
dsregcmd /status
For an Entra joined device with the user’s cloud SSO established, look for these values in their respective output sections:
AzureAdJoined : YES
DomainJoined : NO
AzureAdPrt : YES
The first two describe the device’s join state. The third indicates that the signed-in user has a PRT. None proves that Intune enrolment or application access is healthy. Even an MDM URL in this output does not establish that the device is actually managed. Microsoft’s dsregcmd reference.
I would also verify that:
- Intune shows current check-in, expected policy assignments and the intended compliance result.
- Sign-in logs show the expected Conditional Access decisions for representative applications.
- Users can access their profile, business applications and required on-premises resources.
- Windows Hello, certificates, BitLocker recovery and local administrative recovery work as designed.
- Support can diagnose and recover a failed transition without improvising the procedure.
Include remote users and difficult application dependencies in the pilot. Measure interruption, support effort and successful recovery as well as the number of devices joined.
The budget should include application remediation, licensing, technician time, employee interruption and support. Intune management needs the appropriate entitlement; Conditional Access requires Entra ID P1, with P2 required for user- or sign-in-risk policies. Intune licensing; Conditional Access licensing.
Choose the migration method around the device
The target architecture can be consistent even when the migration methods differ across the fleet.
Option 1: Windows Autopilot for new devices and planned rebuilds
Windows Autopilot is a strong fit for new hardware and devices that should start from a clean configuration. It supports a repeatable provisioning experience with Entra join and Intune enrolment. For existing devices, the documented Autopilot workflow involves reinstalling Windows and provisioning again. Plan application deployment and user-data restoration accordingly. Autopilot overview; Autopilot for existing devices.
Registering a device in Autopilot does not convert its current join state. The specifically named Windows Autopilot Reset feature preserves an existing Entra join and does not support hybrid joined devices. It is a different operation from rebuilding a hybrid device and provisioning it as Entra joined. Autopilot Reset guidance.
Option 2: Manual migration for a small and controlled scope
Administrators can unjoin a device from AD and join it to Entra ID through Windows Settings. This can suit a lab, a limited pilot or a small number of exceptions. Prepare local administrative access and protect user data before making the transition. Microsoft’s Windows join guidance.
The join operation does not by itself reassociate the existing AD profile with the new Entra identity. Profile handling, application access, management enrolment and recovery remain separate work. At scale, the question becomes whether the manual process can deliver those outcomes consistently.
Option 3: In-place migration tooling including Opsole Migrate
In-place tooling is worth evaluating for healthy devices where retaining the installed applications and working profile matters. Opsole Migrate is one option in this category. Its documentation describes AD and hybrid joined device migration to Entra join while preserving the existing profile, applications and local files, without wiping Windows. It also supports device migration between Entra tenants. Opsole Migrate product information.
Opsole describes its approach as agentless: it does not require a persistent migration agent or an on-premises migration server. Components still execute locally to perform the transition. Its workflow documentation explains the profile transition and controlled restarts.
Profile preservation does not guarantee that every saved credential, certificate or application session remains usable. Evaluate the product’s prerequisites and known considerations, then validate application reauthentication, Windows Hello provisioning and management recovery in the pilot.
For any migration tool, I would assess supported scenarios, execution permissions, failure handling and the evidence it produces. Existing device health matters too: preserving a configuration is valuable only when it is a configuration the organisation wants to keep.
Option 4: Provisioning packages for specific deployment scenarios
Windows Configuration Designer provisioning packages offer another way to join eligible devices and enrol them in Intune. They are useful in suitable IT-prepared deployments, but a package alone is not a complete AD user-profile migration workflow. Microsoft bulk enrolment guidance.
Let the architecture determine the rollout
For suitable Windows fleets, I would favour Microsoft Entra join as the target and make the transition measurable. The benefits come from reducing endpoint domain dependencies, establishing reliable authentication and making management and access policies easier to operate.
Autopilot can serve new devices and planned rebuilds. Manual migration can cover limited exceptions. In-place tools such as Opsole Migrate can be evaluated where preserving a healthy working environment is important.
A successful migration leaves the employee able to work, the device manageable, access policies effective and recovery understood. That is the outcome worth designing for.
Top comments (0)