365msp.com.au
Guide

A Conditional Access baseline, in plain English

The sign-in rules most businesses of 10 to 150 people should have, the order to build them in, and how to test each one before it can lock anyone out.

Published . Checked against Microsoft documentation in October 2026. Written by the Jinba IT team behind 365msp.

Conditional Access is the part of Microsoft Entra ID that decides, at each sign-in, whether to allow it, ask for more proof, or block it. It runs after the password (the first factor) has been checked. This guide sets out a baseline that suits most businesses of 10 to 150 people, in the order we would build it.

What you need first

Conditional Access needs Entra ID P1. Business Premium includes it. If you don't have P1, Microsoft's free security defaults are the fallback: they require everyone to register for MFA, require MFA for admins, and block legacy authentication. Microsoft says that if you have P1 or P2 licences, security defaults are probably not right for you, and that they suit tenants without Conditional Access policies. Moving from one to the other is a planned change: switch security defaults off and your own policies on in the same window, so there is no gap.

If Conditional Access licences later lapse, Microsoft doesn't delete the policies, but you can no longer edit them.

The baseline, policy by policy

1. Emergency access accounts, before anything else

A badly written policy can lock every administrator out. Microsoft's guidance for emergency access ("break-glass") accounts is specific:

  • Keep at least two, as cloud-only accounts on your .onmicrosoft.com domain, not synced or federated.
  • Give them the Global Administrator role permanently.
  • Protect them with a phishing-resistant method such as a FIDO2 security key or passkey, and use a different method from your everyday admin accounts.
  • Exclude them from Conditional Access policies that block or restrict sign-in. Report-only policies don't need the exclusion.
  • Don't tie them to one person's phone. Store the credentials securely, in separate places, where more than one authorised person can reach them.
  • Alert on every sign-in, and test that they still work at least every 90 days.

2. Require MFA for every user

One policy covering all users and all resources, with the emergency accounts excluded. Since late 2024 Microsoft has been rolling out mandatory MFA for the Azure portal and the Entra, Intune and Microsoft 365 admin centres, but that covers the admin portals only. Your staff's mailboxes need their own rule.

3. Block legacy authentication

Older protocols such as POP, IMAP and basic SMTP authentication can't do MFA, so a stolen password works on them regardless of your MFA policy. Microsoft says that more than 97 per cent of credential stuffing attacks and more than 99 per cent of password spray attacks use legacy authentication. The policy blocks the "Exchange ActiveSync clients" and "Other clients" conditions. Before you switch it on, filter the sign-in logs by client app, on both the interactive and non-interactive tabs, to find what still uses these protocols. Scanners and line-of-business systems that send email are the usual casualties, and they need another way to send.

4. Treat admin accounts differently

Give administrators separate admin accounts that they don't use for everyday email and browsing, and keep the number of Global Administrators small. Microsoft recommends using the role with the fewest permissions that does the job, such as Helpdesk Administrator for password resets. A stricter policy for admin roles (a phishing-resistant method, or a compliant device) is a sensible next step.

5. Require a managed, healthy device

This is the policy that makes a stolen password plus a stolen MFA prompt much less useful, because the attacker's own laptop doesn't pass. It depends on Intune: the rule grants access only to devices marked as compliant with your Intune compliance policies, and Microsoft warns it won't work as intended until a compliance policy exists and at least one device is compliant. Requiring a compliant device doesn't block Intune enrolment itself, so new laptops can still enrol.

Not every business is ready for this on day one. Microsoft suggests intermediate options, such as requiring a compliant device for administrators only, or requiring a compliant device or MFA for everyone. If you use Entra Connect to sync from an on-premises directory, exclude the Directory Synchronization Accounts role from this policy.

6. Risky sign-ins

Entra ID Protection detects things like leaked credentials, password spray and sign-ins from anonymising addresses, and risk-based policies can demand a password reset or MFA when it does. Those policies are an Entra ID P2 feature. On Business Premium (P1) you get a limited risky sign-ins report that doesn't show risk detail or level, so someone needs to look at it and act. P2 can be added; Microsoft lists it in the Defender Suite and the Defender and Purview Suites sold for Business Premium.

Test in report-only mode

Report-only mode evaluates a policy at every sign-in and logs what it would have done, without enforcing it. Users aren't prompted or blocked. Each sign-in shows one of these results:

Report-only results and what they mean
ResultWhat it means
SuccessThe sign-in already met the policy, for example MFA was already done.
FailureThe policy would have blocked this sign-in. Check every one of these before you enforce.
User action requiredThe person would have been asked for MFA or another step.
Not appliedThe policy didn't apply, for example because the user is excluded.

The policy impact view shows the potential effect over the last day, week or month. One caution from Microsoft: report-only policies that check device compliance can prompt Mac, iPhone and Android users to pick a certificate, again and again. Exclude those platforms from report-only compliance policies. A full working week in report-only is a sensible minimum, so that travellers, part-time staff and once-a-month processes show up before the policy goes live.

Mistakes to avoid

  • No emergency account, or one that is also blocked. The first policy you write should be tested against it.
  • Exclusions that grow quietly. Every exclusion needs a reason, an owner and a review date. A policy with ten exclusions protects less than it appears to.
  • Policies left in report-only. Report-only is a test. Six months later it is a false sense of security.
  • Service accounts used for sign-in. Calls made by service principals aren't blocked by user policies. Shared user accounts used by scripts or devices should be replaced, since they are hard to protect with MFA.
  • Enforcing device compliance before devices report. Roll Intune out first, as in our Intune and Autopilot rollout guide.

How 365msp applies it

Every tenant we manage gets Conditional Access with enforced MFA and legacy authentication blocked, as part of our security baseline, and our 24/7 cybersecurity remediation SOC watches identity alerts as well as endpoints. Details of that work are on the Entra ID and Conditional Access service page.

Sources

Checked October 2026. We read each of these Microsoft Learn pages on 14 October 2026 and wrote this guide against them. Microsoft renames plans and moves features between them, so confirm the current page before you buy or change anything.

Want this checked on your tenant?

The tenant review is free and read-only. We look at licensing, sign-in rules, devices and backup, and you keep the findings either way.

Book a tenant review