Securing BYOD – The different options when signing in to M365 Apps

With the end of Windows Information Protection (and with it App Protection for Windows devices), I wanted to take a look at the best way of securing data on a BYOD machine with the tools currently available (at the time of writing this article).

For the tests, I used a freshly imaged Win11 22H2 device logged in with a personal Microsoft account with a checkpoint applied prior to any Teams/Web logins. I also cleared any device details from Azure AD between tests.

I have also left my Intune tenant completely unlocked, in reality you would want to block Personal Devices from enrolling before doing anything else (screenshot at the bottom)

Before any tests, I looked at Endpoint DLP, but that was immediately ruled out as it requires devices to be onboarded and I can’t see that sitting well on personal machines (Link)

One other thing to note (thanks to David in the comments), both tests 2 and 3 will attempt to escrow bitlocker keys to Azure AD which isn’t ideal for personal devices!

Test 1

The first test was logging into MS Teams with the “Sign in to this app only” option

As expected, this didn’t create any AzureAD device objects:

Or anything in Intune

It also allowed me to do pretty much anything I liked, I can download files, copy and paste text, pretty much anything, not ideal!

As a test, I deployed a Conditional Access policy to block non-corporate devices:

Which worked as expected, but stops BYOD pretty much completely

Test 2

For this one, I unticked the box, but allowed Sign-In to all apps

This does create an Azure AD object, but not an Intune one

Even though it’s AAD registered, that’s it, it turns on SSO for other M365 apps, but you’re still free to do as you please.

Testing the CA policy gave a different error, but still blocked (as expected)

Test 3

For this test, I ticked the box to allow my organisation to manage the device

My MDM/MAM scopes are set as default so this enrols into the WIP service, great for Android and iOS, now useless for Windows

On login I was prompted to Use Windows Hello as my policy is set globally

The device was displayed in Azure AD, but not in Intune so no compliance policy and therefore no access with the CA policy applied (and a different error again):

Teams was, again, completely unlocked and I could do what I wanted.

So far, no good, the extra tick box is literally just forcing Windows Hello

How to block

We’ve established that blocking access to data via the installed app doesn’t work, but what about the web apps?

For this I configured a Defender for Cloud Apps policy using Conditional Access App Control to block downloads when using the web application.

I also configured two Conditional Access policies.

The first is set to Block Downloads on All Cloud Apps using App control:

The second blocks non-web based apps completely on un-managed devices:

When logging into Teams I am presented with:

And when using the web browser, if I try to download:

You’ll notice on the Teams Message it suggests adding via work or school, to block that, set your Intune Enrollments to block Personal Devices

Hopefully this has been of some use!

11 thoughts on “Securing BYOD – The different options when signing in to M365 Apps”

  1. One important point to mention, is the Bitlocker topic as this is not well documented by Microsoft.
    If a user doesn‘t use a cloud account on their personal device and they simply click „OK“ instead of „No, sign in to this app only“, the Bitlocker recovery key of the device is being uploaded to the Azure AD of the company which is a nightmare. This can lead to some odd situations, if users left the company and so on and so on.

  2. Perhaps the issues with Bitlocker encryption (and other undesirable settings for BYOD) could be addressed by amending the filters on Intune policies to exclude personal devices?

    • Blocking personal enrollment is the best option, but that won’t stop Bitlocker as that is at the AAD level, rather than Intune. The best solution is a CA policy to block anything which isn’t web apps

  3. I’ve been trying to figure this out myself. I see that this all depends on your compliance policy. What requirements are listed in there? I’ve added BitLocker as a requirement but it doesn’t seem to report back consistently.

    • Hi David, for BYOD, compliance will only work if the machines are Intune registered so would need to allow personal devices and then manage via compliance that way.
      The safest option I found was to block everything but the browser based apps via conditional access and then you can control those individually to stop data leakage

  4. Pingback: URL
  5. Hi, do you know an option to find the users that are using this method at the moment? So who is using the option no sign in to this app only?

    Can we find this users because the devices are not registerd in azure. So no information at all.

    • Your best bet is to look at the sign-in logs in Entra ID/Azure AD which will show all sign-ins from a browser.
      The other option would be to add a new conditional access policy to block browser sign-in on non-compliant devices and put it into audit mode (this bit is important), then look at the audit logs for the policy


Leave a Comment