A Conditional Access Baseline for Microsoft 365: Eight Policies to Review for Each Customer

Conditional Access is where Microsoft Entra ID decides who may sign in, from where, and with what proof. For each customer it usually looks like one of two things: nothing at all, or a few policies someone created years ago with gaps nobody has checked since.

This guide is the baseline we recommend: eight policies that cover the identity attacks most tenants see most often. Each one maps to a CIS or CISA check, so you can confirm it is in place for the customer you are reviewing rather than assume it.

Before you start

Check your licence. Conditional Access needs Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium, E3 and E5. The two risk-based policies below also need Entra ID P2 (included in E5, or as an add-on). If you have neither, turn on security defaults instead — it is Microsoft's free, fixed set of protections and it is much better than nothing. Security defaults and Conditional Access cannot run together, so turn security defaults off only when your Conditional Access policies are ready to take over.

Set up your emergency access accounts first. Every policy below should exclude your break-glass accounts, and nothing else. If you do not have them yet, read our guide to Microsoft 365 break-glass accounts before you go further.

Start every policy in report-only mode. A report-only policy is evaluated at each sign-in but never blocks anyone. The sign-in logs show what it would have done. Leave each policy in report-only mode for at least a week, check the results, then turn it on.

The baseline

1. Require MFA for admin roles

Admin accounts are the first target in any tenant. Create a policy that targets the directory roles (at minimum Global Administrator, Privileged Role Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator and User Administrator), applies to all cloud apps, and grants access only with multifactor authentication.

Check: CIS-1.1.1, MFA enforced for privileged admin roles.

2. Require phishing-resistant MFA for the most privileged roles

A code or push approval can be phished: an attacker relays the prompt through a fake sign-in page. For Global Administrator and the other most privileged roles, require the phishing-resistant MFA authentication strength, which accepts only FIDO2 security keys, Windows Hello for Business or certificate-based authentication. Register the methods first, then turn the policy on.

Check: CISA-AAD-3.6, Phishing-resistant MFA required for highly privileged roles.

3. Require MFA for all users

Then extend MFA to everyone: all users, all cloud apps, grant access with MFA. Exclude only your break-glass accounts. Before you turn it on, make sure users have registered a method, or the first enforced sign-in will become a support call.

Check: CIS-1.1.6, MFA enforced for all users.

4. Block legacy authentication

Older protocols such as IMAP, POP, SMTP AUTH and old Office clients cannot complete MFA. An attacker with a stolen password can use them to sign in around every MFA policy you have. Create a policy for all users where the client apps condition is Exchange ActiveSync clients and Other clients, and the control is Block access. Check the sign-in logs for legacy sign-ins first: a scanner or line-of-business app that still uses them needs a fix, not an exclusion.

Check: CIS-1.1.3, Legacy authentication protocols blocked.

5. Block device code flow

Device code flow lets a user sign in on one device by typing a code shown on another. It is useful for TVs and conference room devices, and attackers use it in phishing: the victim enters the attacker's code and signs the attacker in. Unless you have devices that need it, create a policy with the Authentication flows condition set to device code flow and block it.

Check: CISA-AAD-3.9, Device code authentication flow blocked.

6. Respond to risky sign-ins (Entra ID P2)

Microsoft Entra ID Protection scores every sign-in for risk: unfamiliar locations, anonymous IP addresses, password spray patterns and more. Create a policy that requires MFA when sign-in risk is medium or high, and one that blocks access, or requires phishing-resistant MFA, when it is high.

Checks: CIS-1.1.9, Sign-in risk policy configured; CIS-1.1.7, Conditional Access policy blocks or challenges high-risk sign-ins.

7. Respond to risky users (Entra ID P2)

User risk is the likelihood that the account itself is compromised, for example because its credentials appeared in a leak. Create a policy that, when user risk is high, requires a secure password change (with MFA), or blocks access until an admin investigates.

Check: CIS-1.1.10, User risk policy configured.

8. Require a compliant or joined device

The last layer ties access to devices you manage. Require a device that is marked as compliant in Intune or Microsoft Entra hybrid joined before users reach company data. This one needs device management in place first. Roll it out to a pilot group, then widen it.

Check: CIS-1.1.5, Conditional Access policy requires compliant or joined devices.

Rolling it out safely

1. Create the break-glass accounts and exclude them from each policy.
2. Ask users to register MFA methods before any MFA policy is enforced.
3. Create each policy in report-only mode.
4. Use the What If tool in the Conditional Access blade to test specific users, and review the report-only results in the sign-in logs.
5. Turn policies on one at a time, admins first, so a problem has one obvious cause.
6. Review the policies after every change to admins, apps or licences.

Gaps we see often

• Policies left in report-only mode for months. Report-only protects nobody. It is a test step, not a state.
• Exclusion lists that only grow. One user excluded "for a day" becomes ten users excluded for a year. Every exclusion should have an owner and an end date.
• Policies scoped to a few apps instead of all cloud apps, which leaves the other apps open.
• Service accounts excluded from MFA instead of being replaced with managed identities or app registrations.
• Guests forgotten. Guest and external users should be covered by your MFA policy too.

How TenantVigil checks this

TenantVigil reads your Conditional Access policies (read-only) and checks each control above. Only enforced policies count: a policy in report-only mode or switched off does not pass a check.

For a Conditional Access change TenantVigil supports, the change is staged as an exact plan: the policy starts in report-only mode, the admin applying the fix and the break-glass accounts are excluded, and approval is scoped to that plan. TenantVigil only reads your Microsoft 365 tenant. It never changes a setting: you apply each fix yourself. Before the change can run, the Microsoft callback and permission setup for that sender must be complete.

Start free to see which of these one Microsoft 365 tenant already has. The Free plan requires a Microsoft work-account sign-in and administrator consent and covers one tenant. For the details of what TenantVigil reads and how, see the permission model.

Further reading: Microsoft's guide to common Conditional Access policies and to report-only mode.