Compliant Device Bypass, Oh My!

Happy New* Year, everyone! Over the holiday break, we learned that Conditional Access policies related to device compliance no longer offer the protection they once did. The technique is alarmingly easy to reproduce and works to bypass both device compliance as well as hybrid join requirements in Conditional Access policies.

Does this mean that you should abandon all such policies?

No. And we’ll explain why shortly.

However, you should absolutely check for policies that enforce only ONE selected control, where you have multiple requirements, such as a policy that requires multi-factor authentication OR a compliant device. This configuration would leave you needlessly exposed.

To ensure that you have coverage across your cloud applications and user actions, see my article: But have you turned multifactor authentication ALL the way on?

Here also is a summary checklist of a minimum policy set to ensure you have MFA enforced for all users & user actions:

• Block legacy authentication
• Require MFA for all users (use authentication strength rather than the MFA option)
• Require MFA for administrators (again using auth strength)
• Protect security info registration (& enable TAP)
• Require MFA for guest users
• Require MFA for device registration
• Require MFA for Intune enrollment

Of course there are additional recommended CA policies everyone should consider, but I would say this list is essential for every deployment no matter what. This will help mitigate the potential vulnerability of having only a device compliance requirement standing between an attacker and your tenant.

Moving to phish-resistant methods

I would also suggest that now is the time to consider increasing your default authentication strength. To prepare, first create a custom authentication strength to include the phish-resistant methods of authentication PLUS Temporary Access Pass (TAP) to enable bootstrapping and admin rescue scenarios (remember that TAP means you need a solid procedure in place for requesting TAPs from admins, including a verification process).

Moving people over to phish-resistant methods does require a bit of planning. You have to decide which method(s) you want to use, distribute the instructions to users, and make sure people have enough time to register their new phish-resistant methods before you adjust your CA policies to enforce the new requirements.

The reason this is important is that phish-resistant methods are hardware-dependent, meaning that an attacker would need to have physical access to the device/authentication method that you have enrolled. We used to have a similar assurance with device compliance, but no longer.

Therefore, if you have been dragging your feet on moving up the authentication bar, so to speak, think hard about prioritizing this task in 2025. If you are keeping score: we already had some MFA bypass techniques out there, and now device compliance bypass is here as well, so your old “backstop” will not be able to save you as it has in the past.

Is Device Compliance worthless now?

The answer is no. It is not worthless to enforce device compliance. Even though there is now a bypass available, not every attack scenario is going to employ it. Furthermore, it can still be a good way to ensure that your own users have enrolled, managed devices that you know are kept to a certain standard. So those benefits (i.e., inventory & control of assets), are still in place.

As I said before, the main vulnerability that I see, is that many organizations have previously put in place a more relaxed MFA policy such as “Require MFA or a complaint device,” meaning that only one of those has to be true in order to gain access to company resources. Don’t forget: this is a templated policy available from Microsoft, and I know there are many folks out there who chose to deploy based on these templates.

Instead, you want to ensure that folks are always challenged for MFA when accessing company resources or registering/enrolling devices, and preferably using stronger auth methods (or a TAP when registering said methods).

One more option and closing thoughts

Another option is to enforce the “Require compliant networks” policy, but this requires that you first set up Global Secure Access (which involves distributing a client to all the managed devices), and at least configure the Microsoft 365 traffic profile.

The downside to this policy is that it cannot be used on third-party apps (just the Microsoft 365 ones as of today). It could stand as another barrier, however, that is similar to requiring managed devices (but in this case it is requiring devices that are configured with the GSA client to route their traffic via Microsoft’s secure edge service).

I guess it was only a matter of time before someone figured out how to get around the “compliant device/hybrid device” control. It remains to be seen whether Microsoft will develop a fix for this, or if it is indeed a “fatal flaw” that simply is what it is.

Either way, I think this lesson highlights that multiple barriers and stronger methods are to be preferred wherever possible. For example, making sure MFA is required everywhere, and that we consider layering other policies on top of that requirement. Given that other MFA bypass techniques exist, we may also suggest that the so-called “Phish-resistant” methods aren’t just for highly sensitive accounts or strict-security environments anymore. It’s 2025, and now is the time for the masses to adapt.

*I meant to get this post out a few days ago, sorry about that!