Conditional Access and MFA Enforcement
Plan, implement, and manage Conditional Access policies — the zero-trust policy engine that controls who can access what, from where, under what conditions.
The zero-trust policy engine
Conditional Access is the bouncer at every door in your Microsoft 365 building.
It doesn’t just check if you have a valid badge (authentication). It checks: Where are you coming from? What device are you using? Is the device managed? What are you trying to access? What time is it? Is your sign-in looking suspicious? Based on ALL of these signals, it decides: let you in, make you verify your identity again, or block you entirely.
At the Expert level, the question isn’t “what is Conditional Access?” — it’s “how do you design 15-20 policies that work together without locking people out?”
Anatomy of a Conditional Access policy
| Component | Options | Example |
|---|---|---|
| Users | All users, specific groups, exclude groups | All users except break-glass accounts |
| Target resources | All cloud apps, specific apps, user actions | Office 365, Azure portal |
| Conditions | Device platform, location, client app, sign-in risk, user risk, device filter | iOS and Android, outside corporate network |
| Grant | Block, require MFA, require compliant device, require Entra hybrid joined, require approved app | Require MFA AND compliant device |
| Session | App-enforced restrictions, sign-in frequency, persistent browser, CASB controls | Re-authenticate every 8 hours |
Priya’s CA policy architecture for GlobalReach
| Policy Name | Users | Apps | Conditions | Grant |
|---|---|---|---|---|
| Require MFA for all users | All users (excl. break-glass) | All cloud apps | — | Require MFA |
| Block legacy authentication | All users | All cloud apps | Client apps: Other clients | Block |
| Require compliant device for sensitive apps | All users | SharePoint, Exchange | — | Require compliant device |
| Block access from risky locations | All users | All cloud apps | Named location: Blocked countries | Block |
| Require phishing-resistant MFA for admins | Admin roles group | All cloud apps | — | Require authentication strength: Phishing-resistant MFA |
| Risk-based MFA | All users | All cloud apps | Sign-in risk: Medium+ | Require MFA |
| Force password change for high-risk users | All users | All cloud apps | User risk: High | Require password change + MFA |
Exam tip: Policy evaluation order
Conditional Access policies don’t have a specific order — they’re ALL evaluated for every sign-in. Key rules:
- Block wins — if any policy results in Block, access is denied regardless of other policies
- All grant controls must be met — if Policy A requires MFA and Policy B requires compliant device, the user needs BOTH
- Exclusions are powerful — break-glass accounts MUST be excluded from blocking policies
- Report-only mode — test policies before enforcement by enabling Report-only
The exam often presents scenarios where multiple policies apply and asks what the combined effect is.
Exam tip: Security Defaults vs Conditional Access
Security Defaults provide baseline identity protection for tenants without Conditional Access:
| Feature | Security Defaults | Conditional Access |
|---|---|---|
| Licensing | Free (Entra ID Free) | Requires Entra ID P1+ |
| MFA enforcement | All users, all sign-ins | Configurable by user, app, condition |
| Block legacy auth | Yes (blanket block) | Configurable per policy |
| Customisation | None — take it or leave it | Full policy control |
| Best for | Small tenants, no dedicated admin | Enterprises needing granular control |
Critical: Security Defaults and Conditional Access are mutually exclusive. Enabling CA policies requires disabling Security Defaults. The exam may ask: “Which approach should a 50-person company with no IT staff use?” → Security Defaults.
MFA enforcement through Conditional Access
The migration from per-user MFA
Microsoft recommends moving from per-user MFA (legacy) to Conditional Access-based MFA:
| Feature | Per-User MFA (Legacy) | Conditional Access MFA (Recommended) |
|---|---|---|
| Configuration | Per-user toggle in Entra | Policy-based in Conditional Access |
| Granularity | MFA always required for enabled users | Conditional — based on location, risk, app, device |
| Exceptions | Difficult to manage | Group-based exclusions and conditions |
| Trusted locations | Trusted IPs only | Named locations (IP ranges, countries, GPS) |
| Risk-based | Yes — require MFA only for risky sign-ins | |
| Report-only mode | Yes — test before enforcing | |
| Authentication strength | Yes — require specific methods (e.g., phishing-resistant) |
Authentication strength policies
Authentication strength lets you specify WHICH MFA methods satisfy a CA policy — not just “any MFA”:
| Strength | Allowed Methods | Use Case |
|---|---|---|
| MFA (built-in) | Any MFA method (Authenticator, SMS, phone call, FIDO2, WHfB) | General users |
| Passwordless MFA (built-in) | Authenticator passwordless, FIDO2, WHfB, certificate-based | Users moving to passwordless |
| Phishing-resistant MFA (built-in) | FIDO2, WHfB, certificate-based ONLY | Admins, high-security roles |
| Custom strength | Any combination you define | Specific requirements |
Elena requires phishing-resistant MFA for all MedGuard Health administrators:
Policy: Require phishing-resistant MFA for admins
Users: Admin roles group
Apps: All cloud apps
Grant: Require authentication strength → Phishing-resistant MFAThis means admins MUST use FIDO2, Windows Hello, or certificate-based auth — regular Authenticator push won’t satisfy the policy.
Named locations
Named locations define trusted and blocked network locations:
| Location Type | How It Works | Example |
|---|---|---|
| IP ranges | Trusted corporate IP addresses | GlobalReach’s office egress IPs |
| Countries/regions | Geographic location from IP | Block all sign-ins from high-risk countries |
| Compliant network | Microsoft’s Global Secure Access | Devices connecting through secure access edge |
Priya creates named locations:
- Corporate offices (trusted) — IP ranges for all 6 offices
- Blocked countries — countries where GlobalReach has no business presence
Deep dive: Report-only mode
Before enforcing a new CA policy, always test it in Report-only mode:
- Create the policy with all conditions and grant controls
- Set the policy state to Report-only (not On)
- Monitor sign-in logs — each sign-in shows what would have happened if the policy were enforced
- Review for unexpected blocks or excessive MFA prompts
- Adjust conditions/exclusions as needed
- Switch to On when confident
The exam expects you to recommend Report-only mode for any new or modified policy. Going straight to enforcement risks locking out users.
Key concepts to remember
Knowledge check
Priya has two CA policies: Policy A requires MFA for all users accessing Exchange Online. Policy B requires a compliant device for all users accessing Exchange Online. A user signs in from an unmanaged personal device. What happens?
Elena wants to ensure MedGuard Health administrators can only sign in using FIDO2 keys or Windows Hello — not standard Authenticator push. How should she configure this?
Domain 2 complete! Next up: Domain 3 — Defender XDR: Security Posture and Threat Intelligence — the unified security portal that ties all your defences together.