What is Conditional Access in Microsoft Entra ID?
Conditional Access is the Entra ID policy engine that evaluates context — user, device, location, app, risk — at sign-in and applies controls accordingly. Learn how it works.
What is Conditional Access in Microsoft Entra ID?
Definition
Conditional Access (CA) is Microsoft Entra ID's policy engine that evaluates signals at sign-in — user, group, app, device, location, risk, client — and applies access controls like requiring MFA, requiring a compliant device, blocking access, or limiting session capabilities.
It is the foundation of Zero Trust in the Microsoft cloud and the primary mechanism for enforcing identity-based security policy.
In simple terms:
Conditional Access asks "given this context, what should happen?" — and enforces the answer.
Why Conditional Access Matters
- The single most important Entra ID security control.
- Required to enforce MFA effectively.
- Enables device-aware access (Intune compliance, hybrid join).
- Blocks legacy authentication that bypasses MFA.
- Responds to real-time risk (Identity Protection signals).
- Foundational for Zero Trust architectures (NIST SP 800-207).
How Conditional Access Works
A CA policy follows the structure: Assignments → Conditions → Access Controls → Session Controls.
Assignments
- Users / groups / roles — who the policy applies to.
- Cloud apps / actions / authentication contexts — what they're trying to access.
Conditions
- User risk (low/medium/high).
- Sign-in risk (real-time).
- Device platform (Windows, macOS, iOS, Android).
- Locations (named locations, country IPs).
- Client apps (browser, mobile, desktop, legacy).
- Device state (compliant, hybrid joined).
- Authentication flows (device code, etc.).
Grant Controls
- Block access.
- Require MFA.
- Require compliant device.
- Require hybrid joined device.
- Require approved client app.
- Require app protection policy.
- Require password change.
- Require terms of use.
- Require authentication strength (e.g., phishing-resistant).
Session Controls
- Sign-in frequency.
- Persistent browser session.
- App-enforced restrictions.
- Conditional Access App Control (via Defender for Cloud Apps).
- Continuous Access Evaluation (CAEP).
Common Conditional Access Policies
Baseline / Foundation
- Block legacy authentication for everyone.
- Require MFA for all users (or via security defaults).
- Require MFA for admins with stronger authentication strength.
- Block sign-ins from high-risk countries.
- Require compliant or hybrid joined device for sensitive apps.
Risk-Based
- Require password change on high user risk.
- Require MFA on medium sign-in risk.
- Block on high sign-in risk.
Workload Identities
- Block service principal sign-ins from outside expected IPs.
- Block managed identity sign-ins outside expected resources.
Device
- Require compliant device for accessing M365.
- Block sign-ins from non-compliant devices.
App Protection
- Require app protection policy for mobile access to corporate data.
Real-World Examples
1. Blocking Legacy Auth
After enabling a CA policy that blocks legacy authentication, password spray attacks against the tenant drop to near zero almost overnight.
2. MFA Fatigue Mitigation
Number matching + context display + Conditional Access policies enforcing strong authentication strength dramatically reduce successful MFA push prompts.
3. Compliant Device Requirement
Sensitive HR app requires a compliant device. An attacker with a stolen password and SMS code is blocked because their attacker device isn't compliant.
4. Risky Sign-In Block
Identity Protection flags a login from an unusual ASN with TOR. CA blocks and forces password reset before access continues.
5. Continuous Access Evaluation
A user is fired. HR triggers deprovisioning. CAEP-aware apps revoke their tokens within minutes — not the default 60-90 minutes.
Common Pitfalls
- MFA enforced via Conditional Access without including all critical apps.
- "All cloud apps" policies with broad exclusions that quietly defeat the policy.
- Break-glass accounts not excluded properly (locked out at the worst time).
- Service accounts and workload identities not handled.
- Legacy auth not blocked.
- No risk-based policies enabled.
- Sign-in frequency too long for sensitive sessions.
- No reporting / monitoring on policy outcomes.
Best Practices
- Block legacy authentication in a Day-1 policy.
- Require MFA for everyone, with phishing-resistant MFA for admins.
- Use named locations carefully — don't bypass MFA based solely on IP.
- Apply risk-based policies (Identity Protection signals).
- Require compliant device for high-value apps.
- Configure break-glass accounts as exclusions and monitor them.
- Use authentication strength to require FIDO2 / passkeys for admin actions.
- Enable CAEP wherever supported.
- Use report-only mode to test new policies safely.
- Document every policy with purpose, owner, and exclusions.
- Review policies quarterly — exclusions accumulate.
- Cover workload identities (service principal sign-in CA).
- Centralize sign-in logs to SIEM and detect on policy outcomes.
Conditional Access Checklist
- Legacy auth blocked for all users?
- MFA required for all users?
- Phishing-resistant MFA for admins?
- Sign-in / user risk policies enabled?
- Device compliance required for sensitive apps?
- Workload identity CA configured (where licensed)?
- Break-glass accounts properly excluded and monitored?
- Named locations used correctly (not as MFA bypass)?
- CAEP enabled where supported?
- Policies tested in report-only first?
- Quarterly policy review?
- CA effectiveness measured (blocked sign-ins, MFA challenges)?
How Forestall Helps
Forestall analyzes Entra ID Conditional Access posture:
- Identifies users / groups / apps not covered by any policy.
- Surfaces dangerous exclusions (e.g., admins excluded from MFA).
- Highlights gaps for workload identities.
- Maps how missing CA policies expand attack paths.
- Tracks CA coverage trends over time.
Frequently Asked Questions
Are Security Defaults enough?
Security Defaults are a great baseline for small organizations but provide limited customization. Most enterprises need Conditional Access for granular control.
Do I need Entra ID P1 or P2?
Conditional Access requires Entra ID P1 (or higher). Risk-based policies need P2. Security Defaults work without these but are less flexible.
How do I avoid locking myself out?
Always exclude break-glass accounts from CA policies and test new policies in report-only mode first.
Does CA apply to Azure resource access?
For control plane (Azure portal, ARM API), yes. For data plane on individual resources, it depends on the resource and whether it integrates with Entra ID.
What is CAEP?
Continuous Access Evaluation Profile — an open standard that lets supporting apps revoke tokens in near-real-time after risk events.
Conclusion
Conditional Access is the most important policy engine in Microsoft Entra ID. Done well, it enforces Zero Trust, blocks legacy authentication, requires phishing-resistant MFA, integrates risk signals, and protects every sensitive app. Done poorly, gaps and exclusions silently undermine the entire identity security program. Audit your policies continuously, cover every user and app, include workload identities, and use CAEP for fast revocation — and Conditional Access becomes the strong front door it's designed to be.
Find every gap in your Conditional Access posture.
Forestall surfaces users, apps, and scenarios not protected by your CA policies.