I'm trying to replicate the old on-premises Active Directory behavior where each user is limited to signing in from assigned devices. For example, User A should be able to access Microsoft 365 apps and resources only from Computer A, Laptop A, and Cell Phone A, while being blocked everywhere else.
Conditional Access with device filters seems like the obvious approach, but it currently blocks access entirely rather than allowing the approved devices. Sign-in logs also suggest that device information is not always being reported reliably, especially for browser sessions and some Windows sign-ins. Our users have a mix of Microsoft 365 Basic, Standard, and Premium licenses, while Business Premium is not available for everyone. Is there a reliable way to enforce per-user device restrictions for all users?
4 Answers
There may not be a dependable Microsoft 365 control that perfectly reproduces a workstation-level Active Directory restriction across every browser, phone, desktop app, and license tier. Conditional Access is generally better suited to requirements such as requiring registered or compliant devices, approved locations, or strong authentication. Confirm that every affected user has the licensing needed for the specific Conditional Access and device-management features before designing the policy around them.
Conditional Access can restrict access to registered or compliant devices, but limiting every user to exactly one or two individually assigned devices is a much more demanding setup. It requires accurate device registration, suitable licensing, careful testing across each app and client type, and ongoing administration whenever devices are replaced or reissued.
Automated assistants can help review a Conditional Access configuration, but they are not a substitute for checking the actual sign-in records. The decisive information is whether each client session includes a usable device ID, device state, and join or registration status. If those values are inconsistent, the practical solution may involve standardizing enrollment and supported clients rather than adding more policy conditions.
First check the Entra sign-in logs before changing the policy. Look at the device information for both successful and failed sign-ins. If the device ID or device state is missing, Entra cannot match the sign-in to the device filter, so the policy may block the session completely. Test with the policies disabled, confirm that the devices are properly registered or joined, and then build the policy gradually.
That appears to be the main issue here. Device identification can be inconsistent in browsers, and some Windows sign-ins may initially fail to provide the expected device details. The policy can be configured correctly and still be unreliable if the client does not report the device state.
The organization already had this kind of restriction with on-premises Active Directory and wants to keep it after moving fully to the cloud. The business still needs users limited to their assigned equipment, even though maintaining the device assignments may be cumbersome.