A diagram depicting Conditional Access in Azure AD

I seem to write an awful lot on here about Conditional Access… not that that’s a bad thing 🙂 As I’ve referenced before, it’s possibly one of my favourite Azure AD features and is a key part of the puzzle when it comes to securing, enforcing, and controlling authentication.

To date Conditional Access has been a notable gap in the small(er) business variant of Microsoft 365: M365 Business. Yesterday (at long last!), that changed so you can now take advantage across the M365 stack!

Conditional Access in M365 Business

In a blog post on the Microsoft Tech Community forums yesterday, Ashanka Iddya announced that effective immediately Conditional Access will be provided as part of Microsoft 365 Business. From a feature perspective, it will be equivalent to that in Azure AD P1. This is a HUGELY advantageous for those organisations that are serious about securing access, but don’t want (or can’t justify) the uplift to M365 E3. If it applies to you, take a look today… you’ve just been gifted a fantastic set of functionality that was sorely missing before!


I provided the below overview in a previous post on Conditional Access (CA: New Baseline Policies) which I’ve repeated here for those that are unfamiliar. Happy reading, and happy playing!

A bit about Conditional Access…

In my opinion, Conditional Access is one of those fantastic Azure AD features that almost single-handedly justifies the purchase of Premium licensing. For the uninitiated, it allows us to control authentication behaviour based on a selection of things…

At a base level, we can use Conditional Access to approve, block, or limit sessions based on different criteria. For Azure AD P1 these attributes are based on static conditions such as who / what / where. Azure AD P2 extends this to include risk-based policies – a component of Identity Protection. These advanced policies use automated intelligence to classify the risk of an authentication request; enforcing dynamic controls based on the result. As an example, a request from an anonymous IP address on an unknown device can trigger a high-risk condition; blocking access or mandating MFA before the request is allowed. Clever stuff.


Have a read of Ashanka’s post, and pay particular attention to the FAQ section at the base of the article. In there you’ll find extra detail, the limitations, and applicability.

Where it applies to you, I guarantee you won’t be disappointed!

Feel free to make contact in the comments below, or to contact me on Twitter if you have any questions 🙂