Multifactor authentication (MFA) is a second proof at sign-in after the password: an authenticator prompt, a hardware key, or another approved method. Conditional Access is the Entra ID policy engine that decides when that second proof is required, when a compliant device is required, or when sign-in is blocked.
The Microsoft 365 plan article lists MFA as a migration checkbox. This guide is how the two controls differ once the tenant is running.
MFA is a method. Conditional Access is a rule.
MFA registration stores which methods a user may use. It does not, by itself, describe every situation. A user can have MFA registered and still sign in with only a password if no policy demands the second factor.
Conditional Access evaluates a sign-in against conditions, then applies a grant or a block:
- Conditions: user or group, guest vs member, application (Exchange, Teams, a custom app), location, device state, sign-in risk
- Grants: require MFA, require a compliant or Entra-joined device, require an approved client app, or block
- Session controls: limit persistent sign-in or restrict what a web session may download, depending on the licence
Security defaults are Microsoft’s baseline onboarding switch: they turn on a standard MFA posture for the tenant. Conditional Access replaces that baseline with named policies you can explain. Do not run both as if they were independent layers; pick one model and document it.
SMS and voice calls are weaker than an authenticator app or a phishing-resistant key. They still beat a password alone. Prefer app-based prompts for staff who handle finance or client files.
What happens at a Conditional Access sign-in
- The person enters their Entra ID credentials
- Policies that match the user, app, location, and device are collected
- The strictest matching grant is applied (MFA, compliant device, or block)
- The person completes MFA or is refused
- Tokens are issued only if every required grant is satisfied
Policies that organisations actually use
Common, explainable policies:
- Require MFA for all members, every app
- Require MFA for guests
- Require a compliant device for Exchange and SharePoint from unmanaged networks
- Block legacy authentication (old mail protocols that cannot do modern MFA)
- Exclude a break-glass emergency account from every policy, stored offline, audited
A policy that says “MFA when not in the office” needs a correct named location. A home fibre IP that was never added will prompt every night. A whole country named as “trusted” is not a location policy; it is a hole.
Admin roles should face stricter grants than a standard user. A Global Administrator on a personal phone with no MFA is the tenant’s weakest point.
What this is not
Conditional Access is not antivirus. It does not read email content. It does not replace backup. It does not replace a written joiner/leaver process. If a leaver’s account stays licensed and MFA-registered, the policies still let that account in.
Licence availability for Conditional Access and for device compliance depends on the organisation’s Microsoft 365 mix. This page does not rank SKUs; it explains the mechanism those SKUs unlock.
A practical example
A firm enables MFA “for some users” in a portal checkbox, leaves legacy IMAP open, and tells directors to skip the app “because they travel.” A password reuse on one mailbox is enough. The revision registers authenticator MFA for every member, turns on a Conditional Access policy that blocks legacy auth, requires MFA for all cloud apps, and stores two emergency accounts in a safe with a quarterly sign-in test.
Key takeaways
- MFA is the second proof. Conditional Access decides when it is demanded.
- Security defaults and Conditional Access are alternative baselines, not a stack to duplicate.
- Block legacy authentication or MFA will be skipped by old protocols.
- Keep an excluded emergency account, and make admins follow the strictest policy.
FAQ
Is MFA enough on its own?
It stops many password-only attacks. It does not see device health. Pair it with device compliance if laptops leave the office with client files.
Why was a user prompted ten times in a day?
Often a policy repeats on every app, tokens expire quickly, or the Microsoft Authenticator app is not set as the default method. Read the sign-in log in Entra ID before adding another policy.
Do guests need MFA?
Yes if they can see any internal file or Team. Guest MFA is a separate condition you can require without changing staff methods.