My favorite Conditional Access Policies for the SMB

It’s not even a question in my mind anymore–every org who moves their email and other data sets into Office 365 should be protected with Enterprise Mobility + Security (also available in Microsoft 365 Enterprise plans).

If you are in the Business subscription of Microsoft 365, this means adding Azure AD Premium Plan 1, at least, to get the full functionality required for Conditional access. And if you happen to upgrade all the way into Azure AD Premium Plan 2 (for example, via the Identity & Threat Protection SKU), then you will also gain “Risk-based” Conditional access–meaning that higher-risk sign-in events can be treated differently than “less risky” ones.

And I do like that. For instance, I can choose to block and require password resets when a user gets flagged for high risk–if they do have a compromised identity I want to fix it NOW. But then again… not every small business is going to leap for that extra security bundle–the stuff adds up!

No fear; you can do pretty well even with the AAD P1 version, which is available as an add-on to Business subscriptions, and is included in EM+S E3 and Microsoft 365 E3.

What is Conditional access?

Conditional access is just a means of protecting your front doors. All of your most valuable Office 365 data–the stuff worth protecting–lives in either Exchange Online or SharePoint Online. Also Teams chats & channels. However, note that policies which restrict parameters for sign-in to Exchange and SharePoint both end up impacting Teams anyway, since Teams stores and retrieves data from these locations, too.

By specifying the cloud apps within a Conditional access policy, you are defining which front doors you are protecting (and you can often combine multiple apps in a single policy or even choose All cloud apps).

When you turn on Conditional access you are basically saying to anyone who is trying to walk through your front door and gain access to the data within the defined applications: “Hey, you need to meet these conditions before you can come in and work with this data.“

Conditions that you can use include:

• Sign-in risk: High/Medium/Low/No (requires AAD P2 / E5)
• Device platform: iOS, Android, macOS, Windows, etc.
• Location: as in geography, IP address, etc.
• Client apps: Web browsers, Modern clients, EAS clients, etc.
• Device state: Compliant (managed by Intune/Device management), or Hybrid Azure AD Joined

Then, based on one or more of the above conditions, you can grant or block access. If you grant access, you can also apply access controls, for example:

• Require multi-factor authentication
• Require device to be marked as compliant (within Intune)
• Require Hybrid Azure AD joined device
• Require approved client app (e.g. the Outlook app for iOS and Android)

You can see how powerful this could be. Block entire geographical regions. Block devices that are not Hybrid Joined to Azure AD or are not enrolled in Device management / Intune. You really start to limit your attack surface quickly. Then you can have more confidence in the sign-ins happening against your tenancy. And, you could increase convenience for users also, by only requiring MFA under certain circumstances (unmanaged device, risky sign-in, etc.).

So pretty cool stuff.

My fave policies

So for the small and mid-sized business, I generally recommend a handful of policies. I will explain each of them here.

1. Require MAM for mobile devices

Since the majority of SMB organizations are using a BYOD model, I generally recommend to setup a policy–actually it is two policies–which enforce approved client apps (e.g. Outlook for iOS and Android).

Note: iOS and Android are the only two platforms that support the access control: Require approved client app.

The reason for this policy set is simple: it is much easier to setup and enforce app policies than deploy full MDM where you have to enroll all the devices, and on top of that have an annually expiring certificate for iOS that needs get renewed on time, and, aside from all that…most users just aren’t as comfortable with the idea of having the corporate entity (their employer) keeping controls over their personal devices.

Therefore, by requiring the app rather than compliance with an Intune policy, you can still manage all the data within the app, apply a PIN, prevent jail-broken devices from opening the app, remotely wipe the profile of the application data ONLY, and so forth. All without touching the device.

The first policy you create can protect All cloud apps, but you should only select Modern authentication clients–that is because we are going to treat other client apps differently, through other policies.

The second policy is just like the first, and you are specifying the same access control, but with regard to Exchange Online only, this time for Exchange ActiveSync clients (EAS clients only access Exchange Online data–so no other app applies here).

Optionally, you could restrict the policy set a bit more, by adding MFA as a requirement to the Modern clients. Note: MFA is not supported by EAS clients.

Now these first conditional access policies are only helpful if you actually have application protection policies in place for iOS and Android, which you can do from Client apps > App protection policies. The app policies allow you to impose stuff like application PIN, the requirement to check for jail breaking, restrict copy/paste/export to and from non-business apps, and so forth.

2. Require device management for other devices

If you are on another type of device (e.g. OSX or Windows), you may want to consider managing those with full Device management. This means that you would need compliance policies configured in Intune for each of the other platforms. That way you can enforce even more “conditions” since being in compliance is the condition (with compliance you can enforce the use of PIN/password, encryption, firewall, anti-malware, code integrity, etc.).

You will target the same device platforms in the Conditional access policy, and guard access by requiring the device to be marked as compliant. Until the user completes enrollment of the device, and the device is made to be compliant, they cannot gain access to resources.

Here again I would target specifically EAS and Modern clients with separate policies (you must create a policy targeting EAS separately–it’s a dumb rule that I’m sure has a perfectly reasonable developer explanation)–since those are the type of client apps that cache and hold local data on these platforms.

3. Deny legacy apps

Under the “Client apps” condition, you can also target “Other clients” and blanket deny them access straight up. You should be sure that no accounts out there are connecting via some legacy protocol like IMAP, SMTP, POP, etc. It is possible of course to make exceptions to any policy, and allow your LOB app or whatever is needed. But try to limit, or better yet, eliminate those if possible.

4. Require MFA for Web browsers (unmanaged devices)

Let’s just quickly review where we are at now:

• PC and Mac devices have to be managed
• iOS and Android devices have to use approved apps with enforced protections
• Legacy apps on any platform will be denied

There is one other scenario that I think we should enable–if someone connects from an unmanaged computer, they may want to be able to access their cloud apps via a web browser. In my opinion, this is less risky and should be allowed. Browsers don’t store local data in the same way that modern clients like Outlook do–you don’t need to reach over the air and “wipe” a browser like you do an app.

In the case of modern clients, we have the ability to remotely wipe corporate data (managed app) or the entire device if it is managed. So that gives me the warm fuzzies. With a browser, when it is closed out and the session flushed from memory, nothing meaningful resides on the device any longer. But, in case users are being dumb and storing credentials in their browsers, it is probably a good idea to at least require MFA.

This means you target all users and all cloud apps, and only one Client app (Web browsers). Then, you could optionally use the Device state (preview) condition to exclude managed devices (use the Exclude tab > Device marked as compliant).

The access control for this scenario, of course, is just Require multi-factor authentication.

Now we have every avenue into your 365 data covered in some way:

• PC’s and Mac’s with modern clients or EAS clients have to be managed, can be protected by compliance policies, and can be wiped
• iOS and Android must use modern (and approved) client apps, the data is protected with application policies, and app data can be wiped
• Any type of legacy app will be blocked outright
• Any unmanaged device must provide at least MFA to gain access to resources via a Web Browser

At this point, if you decided to do any location-based blocking on top of these policies, it would be icing on the cake. And I think as time moves forward this may be a weaker and weaker condition, anyway. It already kind of is–after all, how hard is it to get a VPN or TOR browser that brings you in via the US, for instance, even if you are sitting somewhere in Europe?

Personally, rather than trying to block specific geographies, I would leap instead for the risk-based sign-ons that take advantage of the machine AI built on Azure AD’s billions of daily sign-ins. But again, that brings us back to the money issue.

Anyway, at the very least, I think the policy sets I have described here are a pretty solid baseline for a lot of SMB’s–a good mix of security and usability. But what do you think? Have any other favorite Conditional access use cases you’d like to share? Let me know!