Our healthcare organization works closely with another organization, and many people have accounts in both Entra ID tenants. Cross-tenant access has been configured between the environments, including device compliance and hybrid join trust settings. In the past, users could sign in to computers joined to either on-premises Active Directory domain, but we now use cloud-only, Entra-joined Windows devices.
I need to confirm whether a user whose account belongs to Tenant B can interactively sign in to a Windows device joined only to Tenant A. The sign-in failure appears to occur because the device object exists in Tenant A but not in the user's home tenant. Can cross-tenant access or device trust features support this type of Windows logon, or are they intended only for accessing applications and resources? Has anyone implemented this successfully, or is the scenario unsupported by design?
2 Answers
Cross-tenant access and B2B trust are primarily for applications and resources. Interactive Windows sign-in on an Entra-joined device still depends on the user's home tenant and the device's relationship with that tenant. If the computer exists only in Tenant A, a Tenant B user generally cannot complete the sign-in flow because Windows cannot obtain the required home-tenant authentication context or PRT.
For users who need a full desktop in both environments, practical options include a Cloud PC or VDI hosted in the other tenant, or a separate device joined to that tenant. B2B access from the Tenant A device can still provide access to services such as Teams and SharePoint, but it does not turn the device into a sign-in endpoint for Tenant B accounts.
The home tenant remains the trust boundary for Windows device authentication, much like the domain boundary was for traditional domain-joined computers. Cross-tenant synchronization and device trust settings do not generally change that boundary for the Windows lock screen.
If users need a complete desktop experience under the second organization, a VDI or Cloud PC in that tenant is the safer supported design. Otherwise, keep the physical device joined to Tenant A and use cross-tenant access for applications and resources.
I am collecting confirmation before we change our users' workflow, and this supports the conclusion that the current behavior is expected rather than a configuration mistake.
That matches the error I am seeing. It sounds like the device would need to be registered or joined in the user's home tenant for interactive sign-in to work.