Module 6 of StartCloud's Microsoft 365 Security Essentials learning pathway, in six short units with a knowledge check: how Conditional Access turns sign-in signals into access decisions, the anatomy of a policy, the three baseline policies every business needs, and the report-only rollout discipline that keeps you from locking yourself out.
Conditional Access, Done Properly
If MFA is the lock, Conditional Access is the doorman
Back in Module 1 you switched on MFA, and that was the big win. But MFA on its own is a lock that treats every knock at the door exactly the same. Your accountant signing in from the office at 9am gets the same challenge as someone trying an old mail protocol from the other side of the world at 3am.
Conditional Access is Microsoft's policy engine for fixing that. At its simplest, every policy is an if-then statement: if a sign-in matches the conditions you describe, then apply the controls you chose. It gathers signals about each sign-in, weighs them against your policies, and makes a decision on the spot.
Who is signing in
User, group, or role
Where from
Network or country
What device
Platform and state
What they want
The app or resource
How risky it looks
Sign-in and user risk
Your Conditional Access policies
If the sign-in matches this... then do that.
Block
No entry, full stop
Grant, with conditions
MFA, compliant device, and so on
If MFA is the lock on the door, Conditional Access is the doorman standing next to it. The lock asks one question of everyone. The doorman sizes up who you are, where you came from, and what you are carrying, then decides whether you walk straight in, show extra ID, or head back to the taxi rank.
Two housekeeping notes before we go deeper. Conditional Access needs Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium and E3 (risk signals from Entra ID Protection need P2, which comes with E5). And policies are enforced after the first factor is completed, so it is a second gate behind the password, not a replacement for it.
Every Conditional Access policy, from the simplest to the most elaborate, has the same two halves. The assignments describe which sign-ins the policy catches (the "if"). The access controls describe what happens to the ones it catches (the "then"). Learn this shape once and every policy you ever read makes sense.
One policy, two halves
Users
Who the policy applies to: everyone, specific groups, or directory roles. This is also where exclusions live.
Target resources
What they are trying to reach: all resources, or specific apps like Exchange Online or SharePoint.
Conditions
The circumstances: network location, device platform, client app type, or sign-in and user risk levels.
Grant
The decision itself. Block access outright, or grant it with requirements: MFA, an authentication strength, a compliant device, and more.
Session
What the session looks like once they are in: sign-in frequency, persistent browser sessions, app-enforced restrictions.
Two rules of the road worth memorising. Within one policy, all the assignments combine with AND: every configured assignment must match before the policy fires. And when several policies apply to the same sign-in, the user must satisfy all of them. One policy asking for MFA and another asking for a compliant device means the user needs both. Policies stack, they do not vote.
The minimum a policy needs to do anything at all: a name, at least one user assignment, at least one target resource, and a grant or block control. Conditions are optional seasoning. Plenty of excellent policies use none at all.
You do not need twenty policies. You need three good ones, and Microsoft agrees: these sit at the top of its own Secure foundation templates, and they recreate what security defaults gave you, with room to grow. Build these first, get them stable, and only then get fancy.
Each one is available as a template in the Entra admin center, so you are assembling flat-pack furniture with the instructions included, not woodworking from scratch.
Require MFA for all users
The policy that recreates the heart of security defaults, but under your control. Every user, every resource, MFA required. Microsoft ships this as a ready-made template in its Secure foundation set.
- Include: all users, all resources
- Grant: require multifactor authentication
- Exclude: break-glass accounts only
- Available as a built-in template
Require MFA for admins, phishing-resistant where possible
Admin roles like Global Administrator are the accounts attackers want most, so they get a stronger gate. Where your admins can use passkeys or hardware security keys, step this up to the phishing-resistant authentication strength. A fake login page cannot trick a security key.
- Include: privileged directory roles
- Grant: require authentication strength
- Phishing-resistant MFA for admins is a Microsoft template
- Covers Global Admin, Exchange Admin, and friends
Block legacy authentication
Old protocols like IMAP, SMTP, and POP3 cannot do MFA at all, which makes them the side door attackers adore. Microsoft's analysis puts more than 97 percent of credential stuffing attacks and over 99 percent of password spray attacks on legacy authentication. Close the door.
- Include: all users, all resources
- Condition: legacy authentication clients
- Grant: block access
- Kills off password spray almost entirely
Here is the part that separates a tidy rollout from a Tuesday you will not forget. Conditional Access enforces exactly what you tell it to, immediately, for everyone it matches. A typo in a block policy does not send you a warning email first. So the professionals follow three habits, every single time.
1. Report-only mode first, always
Every new policy starts its life in report-only mode. The policy is evaluated against your real sign-ins and the result is written to the sign-in logs, but nothing is enforced and nobody is prompted or blocked. After a week or two you can see precisely who the policy would have caught, compare the results in the sign-in log's report-only tab, and fix surprises before they become incidents. Policies created from Microsoft's templates default to report-only for exactly this reason.
2. Ask What If before you wonder what happened
The What If tool simulates a sign-in without anyone actually signing in. Pick a user, an app, and the conditions (location, device platform, risk level) and it reports which policies would apply and what they would do. It is the flight simulator for your policies: crash there, not in production. Use it to answer questions like "what happens when Sarah signs in from her personal laptop in Bali" before Sarah is actually in Bali.
3. Exclude almost nobody
Microsoft recommends excluding exactly two kinds of account from your policies: your break-glass accounts (the two emergency access accounts you set up in Module 1, so a misconfigured policy can never lock every admin out at once) and genuine service accounts that cannot complete interactive MFA. That is the whole list. Every "just exclude the directors, they find the prompts annoying" request is a hole in the fence, in precisely the spot attackers check first.
The classic self-inflicted wound is a block policy scoped to all users with no exclusions, saved with the best of intentions at 4:55pm. Before any policy leaves report-only: confirm both break-glass accounts are excluded, run What If against your own admin account, and switch it on while you still have a working session open in another browser tab. Belt, braces, and a spare belt.
Changing an existing policy? Same discipline. Clone it, make the change on the report-only copy, compare the two in the logs, then update the real one and delete the copy. Report-only mode is not just for new policies, it is for every change you are not completely sure about. Which should be all of them.
Time to build baseline policy number one, require MFA for all users, the careful way. Everything happens in the Microsoft Entra admin center at entra.microsoft.com, and you will need the Conditional Access Administrator role or better. If you are still on security defaults from Module 1, remember they must be switched off before Conditional Access policies can be turned on; you cannot run both at once.
- 1Sign in to the Microsoft Entra admin center and go to Entra ID, then Conditional Access, then Policies.
- 2Select New policy and give it a clear name, for example CA001 - Require MFA for all users. A naming standard pays for itself the day you have ten of these.
- 3Under Users, choose Include: All users. Under Exclude, add your two break-glass accounts and nothing else.
- 4Under Target resources, choose Include: All resources.
- 5Skip Conditions entirely. This policy applies everywhere, which is the point.
- 6Under Access controls, choose Grant, tick Require multifactor authentication, and select Select.
- 7Set Enable policy to Report-only and select Create.
- 8Let it run for one to two weeks. Check the Report-only tab in the sign-in logs and confirm it catches who you expect and nobody it should not.
- 9Run the What If tool against your own account and a couple of typical staff accounts as a final sanity check.
- 10Switch the policy from Report-only to On. Then repeat this same routine for the admin MFA and block legacy authentication policies from the previous unit.
Faster route: the New policy from template option pre-builds this whole policy from Microsoft's Secure foundation set, with your signed-in account excluded automatically. You still adjust the exclusions to your break-glass accounts, and you still start in report-only. The discipline is the feature.
- Microsoft Learn: What is Conditional Access?
- Microsoft Learn: Build a Conditional Access policy
- Microsoft Learn: Conditional Access policy templates
- Microsoft Learn: Analyze Conditional Access policy impact (report-only mode)
- Microsoft Learn: Block legacy authentication with Conditional Access
Steps were current at the time of writing (July 2026). Microsoft occasionally moves things around the admin centre, so screens may vary slightly.
Knowledge check
5 quick questions. Get 4 right and the module is yours.
1. At its simplest, a Conditional Access policy is...
2. Which two halves make up every Conditional Access policy?
3. Why does blocking legacy authentication matter so much?
4. Who should be excluded from your baseline Conditional Access policies?
5. You have just created a new Conditional Access policy. What happens before it goes live?