How Unsupported Devices Can Bypass Microsoft Entra Conditional Access Policies 

I’ve been helping organizations harden Microsoft Entra ID for the last 5 years and given multiple talks on finding holes in Conditional Access. This month, I did some research into Device Platforms, testing a misconfiguration I find in almost every tenant.

In my testing, a sign-in with an unclassified platform fell outside every Conditional Access policy scoped to a named device platform. My recommendation is to add a report-only block policy that includes Any device and excludes only the platforms your organization supports. This closes the gap, but it should complement device compliance or app-protection controls because the platform signal can be spoofed.

The fix is well documented but it’s buried among the ever growing Microsoft Learn articles. 

Entra Conditional Access: Any Device != All Devices

When configuring the Device Platforms condition, selecting “Any device” is not the same as checking every device platform in the list. This causes issues because Conditional Access is additive. There is no default “deny-all” rule like a firewall. A login, whose Device Platform can’t be classified, matches none of the selected platforms. So, a policy simply doesn’t apply. Unmatched isn’t denied, it’s unjudged and allowed through. This isn’t a bug, it’s an assumption mismatch around how policy evaluation works.

Device Platforms are evaluated based on the user-agent string supplied during sign-in. For example, the user-agent string from the sign-in logs when logging in from my Windows desktop is: 

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36

However, multiple tools exist that can spoof a user-agent string from the client’s desktop. From that same Windows desktop, I generated a sign-in log showing both of these user-agents: 

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36

Mozilla/5.0 (X11; CrOS x86_64 14541.0.0) AppleWebKit/537.36

Entra identified the first as a Linux OS and every Conditional Access policy targeting the Linux Device Platform applied as expected. The second shows an empty OS and it fell outside the scope of every Conditional Access policy targeting a specific Device Platform. Interesting that just a few characters means the difference between an unsuccessful and successful login.

The remediation blueprint to establish a fail-closed model

The first step is laying the foundation by establishing the devices your organization supports. This is accomplished by adding a new Conditional Access policy that blocks unknown and unsupported device platforms. Create a Block rule to include “Any device” and exclude all platforms you support. Microsoft outlines the steps in their best practice guide. This changes the fail-open behavior to a fail-closed model.

Deploy the policy in report-only mode first and evaluate sign-in logs for any unknown devices failing that policy. Determine if they require an exclusion or further investigation. Of course, the break-glass accounts should also be excluded to prevent tenant lockout.

With unknown devices denied, per-platform policies properly take shape. For example, maybe you want to require device compliance for macOS, require Microsoft Entra hybrid joined device for Windows, or require app protection policy for Android and iOS.

Device platforms are not a security boundary

The takeaway here is not “how to use Device Platforms”, there’s a bigger lesson. As shown previously, Device Platforms are based on user-agent, which is a client-asserted string. Because the client chooses what they want to claim to be, it’s best to view Device Platforms as more of an organizational control rather than a security boundary. Controls around device compliance, device filters, authentication strengths, and token protection do more to withstand adversary tradecraft. Which of your Conditional Access policies hold up if the client lies about who they are?