Require managed devices in Microsoft 365

Allowing users to access resources from any device is the equivalent of an airline company like United saying, “you know what, we are just going to let our pilots fly any plane they want. We don’t know if it is up to code. We don’t really know who is on the plane but they can still access our United resources.” Would you get on that plane? As the CEO of United would you be comfortable with that? I don’t know too many people that would say yes. By default in Microsoft 365, users can access their corporate data from:

• Any device
• Any network location
• Anywhere in the world

If this makes you uneasy, it should given this presents us with a significant amount of risk. In a previous article (opens in new tab), I discussed how you can secure access on BYOD/personal devices and the importance of educating your customers why managed devices should be the only method of accessing corporate resources. In today’s article, I am going to walk you through the exact policy you need to configure in your Microsoft environment to allow for only approved device access.

Managed Device Policy Matrix#

So like I mentioned last week, we want to channel our customers into using only approved managed devices. Today we are going to walk through the first recommended policy for secure device access which is requiring a managed and/or compliant device.

Default Settings#

By default users can really login on any device. That device could have active malware, it could be a device that owned from an attacker that recently compromised a user and get their credentials or performed some type of token theft.

In a previous article (opens in new tab) on persistence techniques, I also showed one of the common things attackers do in the attack kill chain after initial compromise is joining a device to your network to maintain persistence and effectively hide. These are all reasons, we want to enforce a strong policy for device access.

Baseline Policies#

When thinking about a layered approach to security, you will have varying states of maturity with the customers you manage. There are tiers or levels you can step into for policies you enforce based on where the customer is at today.

Layer 1 Protections: Block Access on Devices that are not Entra Joined or Entra Hybrid-Joined#

When you onboard a customer, within the first 90 days, you want to enforce a policy that requires managed devices to used signing in. We do this leveraging the device registration type in Microsoft 365. We want our devices to either be Entra Joined or Entra Hybrid Joined if they still have local active directory.

How to Configure

1. Go to the Entra Admin Center
2. Protections>Conditional Access>+New Policy
3. Name: Block Unmanaged Devices
4. Users > All Users
5. Exclude Break Glass User + (For CSP using GDAP>Exclude Guest >+Service Providers)
6. Target Resources > All Cloud Apps
7. Conditions>Filter for Devices>Exclusions>Device TrustType = Entra Joined or Entra Hybrid Joined
8. Grant>Block

Layer 2 Protections: Require a Compliant Device#

Layer 2 protections require more maturity and take this a step further. They require that:

• Microsoft Intune is leveraged and devices are enrolled
• Device compliance policies are configured enforced for Device access

They step up our protections because they also require that managed devices are in a “compliant” (i.e. “healthy”) state. You device what makes a device compliant within the policy you create in Intune but at a high level we are asking questions like:

• Does the device have AV turned on?
• Is the device at a low risk state with Defender?
• Is the device patched?

And more. It requires a higher level of maturity given you have to:

• Ensure that all managed devices are in Intune
• Have an SOP in place for managing “Non-Compliant” devices given the policy we are implementing would lock them out of their account if it is not.

How to Configure

(Prerequisite is creating and enforcing a device compliance policy (opens in new tab))

1. Go to the Entra Admin Center
2. Protections>Conditional Access>+New Policy
3. Name: Require Compliant Device
4. Users > All Users
5. Exclude Break Glass User + (For CSP using GDAP>Exclude Guest >+Service Providers)
6. Target Resources > All Cloud Apps
7. Grant>Require Device to be marked as Compliant

Couple of words of caution with this policy I consult with a lot of MSPs and Intune is pretty widely inconsistent right now of devices falling out of compliance without any indication as of why. In many cases, if you unenroll and re-enroll devices from Intune, they will show up as compliant again. For this reason, I always recommend turning on device compliance policy without restricting sign-ins at first and seeing if you do not get a ton of false positives on the compliance side. We want to keep our end-users happy and not overload our helpdesk. ×

Tooling to help with reporting on these policies#

I built a tool called CloudCapsule that allows you to connect your tenants to run a security assessment against the controls in place to CIS. You can perform a scan to look for these policies across the tenants that you manage.

Run Free Assessment (opens in new tab)

Conclusion#

Ok guys, I highly encourage you to go enforce at least the Layer 1 conditional access policy I showed here to start locking down your environment. Stay tuned next week as we cover the next recommended policy I have for secure device access. Subscribe to the newsletter to get automatic updates. If you didn’t see last weeks video (opens in new tab) on my top policy recommendations for BYOD/personal devices, be sure to check that out.