Most businesses we work with have MFA turned on. That's great — it's the single most effective control against account compromise. But MFA on its own only answers one question: "Is this the right person?" It doesn't answer equally important questions like: "Should this person be accessing this from a personal device in another country at 3am?"
That's where Conditional Access comes in. It's a feature built into Microsoft Entra ID (formerly Azure Active Directory) that lets you create policies controlling how, when, and from where people can access your business applications. And if you're paying for Microsoft 365 Business Premium, E3, or E5, you already have it — you're just probably not using it properly.
What Conditional Access actually does
Conditional Access policies evaluate a set of conditions every time someone tries to sign in, and then enforce a set of controls based on those conditions. Think of it as an intelligent gatekeeper that makes access decisions in real time.
The conditions you can evaluate include who the user is (or what group they belong to), which application they're accessing, what device they're using and whether it's managed by your organisation, where they're signing in from (by IP address or country), the risk level of the sign-in (detected by Microsoft's threat intelligence), and whether the device meets your compliance requirements.
Based on those conditions, you can enforce controls like requiring MFA, blocking access entirely, requiring a compliant or domain-joined device, limiting what the user can do within the application (like blocking downloads), or forcing a password change.
Why most businesses get it wrong
The most common mistake we see is businesses that have "MFA for all users" as their only Conditional Access policy. That's better than nothing, but it misses the point. A well-designed Conditional Access framework should have multiple layered policies that address different risk scenarios.
The second most common issue is overly permissive policies. We regularly find environments where admin accounts aren't subject to stricter controls than regular users, personal devices have the same access as managed corporate devices, and there are no geographic restrictions even though the business only operates in Australia.
The third issue is no break-glass accounts. If your Conditional Access policies lock out every account (including admins) and something goes wrong with your MFA provider, you're locked out of your own tenant. Every organisation needs at least two emergency access accounts excluded from Conditional Access, secured with strong passwords stored in a physical safe, and monitored for any usage.
A practical policy framework
Here's a framework we use as a starting point for Australian businesses. The exact policies need to be tailored to your environment, but these cover the fundamentals:
Policy 1: Require MFA for all users. This is your baseline. Every user, every cloud app, every sign-in. Exclude only your break-glass emergency access accounts.
Policy 2: Block legacy authentication. Older email protocols like POP3, IMAP, and SMTP AUTH don't support MFA. Attackers know this and specifically target them. Block these protocols for all users — modern mail clients don't need them.
Policy 3: Require compliant devices for sensitive apps. For applications that contain sensitive data (like your CRM, accounting software, or document management), require that the device accessing them is managed and compliant through Intune. This prevents someone from accessing client data from an unmanaged personal laptop.
Policy 4: Block access from outside Australia (with exceptions). If your business operates in Australia and your staff don't travel internationally, block sign-ins from all other countries. If staff do travel, create a named locations list of allowed countries and block everything else. This single policy eliminates a huge volume of credential-based attacks that originate overseas.
Policy 5: Require phishing-resistant MFA for admin accounts. Global admins, Exchange admins, SharePoint admins, and other privileged roles should be held to a higher standard. Require FIDO2 security keys or Windows Hello for Business instead of push notifications or SMS, which can be intercepted through SIM-swapping or MFA fatigue attacks.
Policy 6: Block high-risk sign-ins. If you have Entra ID P2 licensing (included in M365 E5), enable risk-based policies that automatically block or require password changes for sign-ins that Microsoft's threat intelligence flags as high-risk — such as sign-ins from known malicious IP addresses or impossible travel scenarios.
Common pitfalls to avoid
Testing in report-only mode first. Before enforcing any new Conditional Access policy, run it in report-only mode for at least two weeks. This lets you see what the policy would have blocked or required without actually affecting users. Check the sign-in logs to make sure legitimate access isn't being caught.
Don't forget service accounts. Service accounts that authenticate to Microsoft 365 or Azure (for integrations, automations, or third-party apps) need to be accounted for in your policies. If you block legacy auth globally but your line-of-business app uses SMTP AUTH, it'll stop working. Identify these before you enforce.
Document everything. Name your policies clearly (not "Policy 1" — use descriptive names like "Require MFA — All Users" or "Block — Legacy Auth Protocols"). Document why each policy exists, what it does, and who it applies to. When something breaks at 7am on a Monday, you need to be able to quickly identify which policy might be causing it.
How this relates to Essential Eight
Conditional Access directly supports several Essential Eight controls. Multi-factor authentication is obviously one, but restricting admin privileges is another — you can use Conditional Access to enforce just-in-time admin access through Privileged Identity Management (PIM), ensuring admin roles are only activated when needed and automatically expire.
User application hardening is also supported, as you can restrict what users can do within applications based on device compliance and session controls. And if you're pursuing Essential Eight ML2 or above, the ACSC's requirement for phishing-resistant MFA essentially mandates the kind of Conditional Access policy framework we've described.
Getting started
If you're on Microsoft 365 Business Premium or higher, you already have the licensing for Conditional Access. The barrier isn't technology — it's knowing what policies to create and how to roll them out without disrupting your business.
Start with the baseline policies (MFA for all users, block legacy auth, and geo-restrictions) and work up from there. And if you want someone to design and deploy it properly, that's exactly the kind of engagement we do.