Some policies I use in Conditional Access

This site is called Conditional Access, and yet surprisingly, it has very little advice on what you should do for CA policies. I’ve stayed away from this subject on purpose; it’s very hard to “baseline” CA policies as they are very bespoke to the individual needs of a business, and nobody can ever agree on what’s best.

The word “baseline” holds a lot of weight too. Many frameworks or baselines have become inarguable rulesets for administrators everywhere, even though few of them ever set out to be used in that way.

So, this isn’t a baseline, I’m not even going to call it guidance. These are some policies I use, feel free to take some inspiration.

I’ve copied ideas I’ve seen from Jay Kerai, Ru Campbell and others.

General Approach

Apply broadly, exclude narrowly.

If you assign to static groups, you’ve made yourself a static problem. Even if it’s a dynamic group, there might be times where for whatever reason a user isn’t quite fitting the rule, and it may as well have been an “all users” assignment from the start anyway.

Note: Where specific property types aren't configured, that means it will apply to everything.

In "MFA all users all resources", I'm not configuring any network or conditions. It simply means it applies to all users regardless of other possible login routes.

Policy list

A lot of guides will tell you to do a separate one for admins, which might assist with the gradual rollout of policies like this, but the end goal is everyone gets MFA.

Time to get rid of those old printers…. and don’t exclude your break glass from this one. In case of emergency, an SMTP email account is not what your Global Admin account is logging into 🙂

This one is very powerful. Entra doesn’t have listed options for every single user agent. By blocking all, but explicitly allowing the ones we want, we’re greatly reducing attack surface.

If your business doesn’t use macOS, don’t exclude it from the list.

This firstly requires an Intune MAM policy. My preferred route is MAM-WE, that’s Mobile Application Management-Without Enrolment. I don’t want people enrolling any personal devices in my tenant.

Probably the most effective way of preventing AiTM breaches, fairly hard to get businesses to understand that business data should only be accessed on business devices. Congrats if you’ve done this!

We’re blocking the “netflix” style logins for everyone. Normal end-users typically don’t need to use this, some admin functions require it for certain PowerShell modules etc.

This, in conjunction with the “require compliant device” is why I don’t do location blocking. It might make sense for you to do location blocking to make your logging quieter.

A slightly less impacting version of “Require Compliant Device” in a way. Most attackers will try and access one of the listed resources as their entry point. Combine them both because why not?

A long password in a safe for the Global Admin is not good enough. Use FIDO2 on that account.

A created account without MFA registration is quite risky. Lower the risk with this restricting policy. If your new starters always start in the office, make that the only location where they can register.

This prevents user authentication jumping to devices you might not want them to.

Use the impact analysis

Do not yeet any of these out into customer environments before fully understanding the impact.