is the part of that decides, at every sign-in, whether to let the person in, ask for more proof, or refuse. It looks at who is signing in, from which device, from where, to what, and how risky the attempt looks, and then applies a rule you wrote in advance. Without it, access to your company's email and files is governed by a username and a password, plus whatever the user happened to set up.
This guide is the practical version: the five policies every business should have, what a device compliance check actually checks before it lets an app open, how to roll policies out without locking yourself out, and how the whole thing maps to the . Updated 30 September 2026.
The five policies every business should have
| Policy | What it does | Why it is first |
|---|---|---|
| Require MFA for all users, all cloud apps | Every sign-in from every user needs a second factor. | It closes the single most common way into a tenant: a password that leaked somewhere else. |
| Block legacy authentication | Refuses older sign-in protocols (IMAP, POP, SMTP basic auth, older Office clients) that cannot do MFA. | Without it, the MFA policy has a back door. Attackers try the old protocols first because they know this. |
| Require phishing-resistant MFA for administrators | Global and other privileged roles must sign in with a passkey or hardware security key, not a code or a push approval. | Codes and push prompts can be relayed through a fake sign-in page. Admin accounts are what attackers want most, and Essential Eight Level 2 requires phishing-resistant MFA for them. |
| Require a compliant device for company data | Email, SharePoint, OneDrive and Teams open only from a device enrolled in Intune that passes its compliance checks. | A stolen password on an attacker's laptop gets nowhere. This is the device security check people search for. |
| Block high-risk sign-ins | Uses Entra ID Protection risk signals to block or challenge sign-ins that look wrong: impossible travel, anonymous networks, leaked credentials. | It catches the attacker who has a valid password and a valid MFA session but is signing in from the wrong side of the world. |
The first four are available with the P1 licence included in Microsoft 365 Business Premium. The fifth needs Entra ID P2, which comes with Microsoft 365 E5 or as an add-on.
What a device compliance check actually checks
Requiring a compliant device means two things have to be true before an app opens. The device has to be known to your tenant, which means enrolled in (or joined to your domain and registered with Entra), and it has to pass the compliance policy you set in Intune. A device that is unknown, or known but failing, is treated the way the policy says: usually blocked, sometimes allowed into a browser-only session that cannot download.
A typical compliance policy for a business laptop checks that the operating system is at or above a minimum version, that the disk is encrypted, that Microsoft Defender Antivirus is running with current signatures, that a password or PIN of a set strength is enforced, that the screen locks after inactivity, and on phones, that the device is not jailbroken or rooted. Intune evaluates the device against the list on a schedule and marks it compliant or not. Conditional Access reads that mark at sign-in.
The consequence for an attacker is the one that matters. A phished password, or even a stolen session, is only useful from a device that passes those checks, and the attacker's machine does not. It is the control that turns a into a failed login rather than a breach.
What about personal phones and unmanaged PCs
Staff will read email on their own phones, and a policy that stops them will be worked around. Intune has a second mode for exactly this: app protection policies, which manage the Outlook or Teams app on a personal phone rather than the phone itself. Company data stays inside the managed apps, with a PIN, and the ability to wipe it, and the person's photos and messages are untouched. A Conditional Access rule can then require either a compliant device or an approved app with a protection policy, which covers both fleets.
Unmanaged PCs are harder, because there is no app-protection equivalent for a desktop browser. The usual answer is to allow browser access only, with downloads, printing and sync switched off through 's access controls, so the data can be viewed but not taken. Anything more than that needs the device enrolled.
How to roll it out without locking yourself out
Every policy has a report-only mode. Use it. A policy in report-only evaluates every sign-in and records what it would have done, and the sign-in logs show you exactly which users and which apps would have been blocked. Run each policy that way for at least a week before switching it on.
Create two break-glass accounts before you enable anything: cloud-only, with long random passwords stored offline, excluded from every Conditional Access policy, and monitored so that any sign-in raises an alert. They exist so that a misconfigured policy or an outage at your MFA provider cannot lock every administrator out of the tenant at once.
Then pilot with a small group, extend to everyone, and keep exclusions to the minimum. Every user, application or location excluded from a policy is a gap the policy no longer covers, and exclusions have a habit of outliving the reason they were added.
The mistakes we see most
Too many exclusions. Service accounts, an old integration, the managing director who found MFA annoying: each one is an account an attacker can use without meeting the policy. Fix the integration or replace the account rather than excluding it.
MFA required but legacy authentication left open. The policy exists, the tenant still accepts a basic-auth IMAP login, and the attacker uses that. The two policies only work as a pair.
Policies switched on without report-only. The finance system stops working on a Monday morning, the policy is disabled in a hurry to fix it, and nobody switches it back on.
No break-glass account, or one that has expired, or one that nobody can find the password for. This is only discovered at the worst moment.
Compliance policies with no consequence. A device can be marked non-compliant for months if no Conditional Access rule reads the mark. Compliance without a policy that enforces it is a report, not a control.
How it maps to the Essential Eight
| Essential Eight requirement | Conditional Access policy that satisfies it |
|---|---|
| Level 1: MFA for users of the organisation's online services and third-party services holding sensitive data | Require MFA for all users, all cloud apps. |
| Level 2: MFA used for online services and for users of systems is phishing-resistant | Require phishing-resistant authentication strength, first for administrators, then for everyone. |
| Level 2: privileged accounts prevented from accessing the internet, email and web services | A policy scoped to privileged roles that blocks Exchange Online and other web apps, paired with separate admin accounts. |
| Level 2: successful and unsuccessful MFA events centrally logged | Entra sign-in logs, exported to a log platform and retained. |
The full Level 2 list, in 's words, is in our Maturity Level 2 checklist. Which keys satisfy the -resistant requirement is covered in what qualifies as phishing-resistant MFA.
Frequently asked questions
What is Conditional Access in Microsoft 365?
The policy engine in Entra ID that evaluates every sign-in against rules you set and decides whether to allow it, require more proof, or block it. Rules can consider the user, the device, the location, the app and the risk of the sign-in.
Do we need Intune to use Conditional Access?
Not for MFA, legacy authentication or location rules. You need Intune, or another management tool that reports compliance to Entra, for any rule that requires a compliant device, because something has to check the device and report the result.
Can staff still read email on personal phones?
Yes, through app protection policies that manage the Outlook and Teams apps rather than the phone. Conditional Access can require either a compliant device or a protected app, so company phones and personal phones each meet the rule their own way.
What happens if a policy locks everyone out?
A break-glass account excluded from all policies signs in and disables or fixes the policy. That is the whole reason the account exists, and why it has to be created before the first policy is enabled.
Is Conditional Access included in Microsoft 365 Business Premium?
Yes. Business Premium includes Entra ID P1, which covers user, device, location and app-based policies, and Intune for device compliance. Risk-based policies need Entra ID P2.
Where to start
If you are on Business Premium and are not sure which of the five policies exist in your tenant, that is the first thing our Microsoft 365 security review checks, along with whether Defender is enrolled and whether legacy authentication is still open. The review ends with the policies written in report-only mode, ready to switch on.
