A Conditional Access baseline that survives reality
Most tenants do not fail because a policy is missing. They fail because the policy exists in report-only mode, or because an exclusion group that was created for one migration in 2022 still contains eleven accounts.
By Piotr Zenon Żabrowski · Published · Updated
1Request
- User or workload
- Target application
- Requested scope
2Signals
- Identity strength
- Device compliance
- Risk score
- Location / network
3Decision
- Allow
- Allow with step-up
- Allow limited session
- Block
4Enforcement
- Session controls
- Just-in-time privilege
- Continuous evaluation
- Audit trail
Ship in this order
011. Block legacy authentication
Protocols that cannot carry MFA are the cheapest way in. Nothing else matters until this is enforced.
022. Require MFA for all users
All users, all cloud apps, phishing-resistant where the population allows it — passkeys or hardware FIDO2 keys for admins, Windows Hello for Business for managed devices. Emergency-access accounts are the only exclusion, and they are monitored.
033. Require compliant or hybrid-joined devices for privileged roles
Admin work happens from managed devices, or it does not happen.
044. Restrict device registration and token lifetimes
Require MFA to register a device; shorten sign-in frequency for administrative sessions.
055. Add risk-based policies
Sign-in and user risk drive step-up authentication or a forced password change, once the earlier layers are stable. Configure these as native Conditional Access risk conditions rather than the legacy Identity Protection risk policies, which are being retired.
Where these baselines break
| Failure mode | Why it happens | Fix |
|---|---|---|
| Permanent report-only policies | Nobody owns the decision to enforce | Set an enforcement date at creation; review report-only monthly |
| Exclusion groups with no expiry | Created for a migration, never cleaned | Time-boxed membership, owner attestation, alert on additions |
| Service accounts outside policy | MFA breaks the integration | Move to workload identities with certificate or federated credentials |
| Guest access ungoverned | Collaboration invites bypass review | Separate policy set for guests plus access reviews |
| No break-glass path | Fear of lockout blocks enforcement | Two excluded emergency accounts, hardware-key protected, alerted on use |
| Legacy and modern risk policies running in parallel | Nobody scheduled the cutover before the retirement date | Migrate to Conditional Access risk conditions and retire the legacy policy on a fixed date, not 'eventually' |
Baseline verification
- Legacy authentication blocked tenant-wide.
- MFA required for every interactive user, including administrators.
- Privileged roles require a compliant or hybrid-joined device.
- Every exclusion has a named owner and a review date.
- Two break-glass accounts exist, are hardware-key protected and alert on sign-in.
- Legacy per-user MFA/SSPR and legacy risk policies are fully retired, not just superseded on paper.
- Policy changes are logged and reviewed as configuration changes.
Frequently asked questions
Security defaults or Conditional Access?
Security defaults are a reasonable floor for small tenants. Once you need exclusions, device conditions or risk policies, move to Conditional Access — but keep the same intent.
How long does a baseline rollout take?
Technically days. Realistically a few weeks, because the work is inventorying legacy authentication and service accounts, not clicking policies.
Do the legacy per-user MFA and risk policies still matter?
It matters for the migration deadlines behind them. Legacy per-user MFA and per-user SSPR policies had to move to the unified Authentication Methods policy by 30 September 2025, and the legacy Entra ID Protection user-risk and sign-in-risk policies (read-only since mid-2025) retire on 1 October 2026 in favour of risk conditions inside Conditional Access itself. A tenant still running either legacy track alongside a modern baseline has two enforcement paths that can silently disagree.
Related
Identity & Zero Trust
Entra ID hardening, Conditional Access authentication strengths, privileged access management and identity attack-path analysis with BloodHound.
Microsoft Entra ID
Entra ID hardening: Conditional Access design, PIM, phishing-resistant authentication, app registration governance and agent identity.
Identity attack paths
Using BloodHound and Entra ID review to find privilege escalation paths across on-premises Active Directory and cloud identity.
Conditional Access checklist
Printable checklist for reviewing an Entra ID Conditional Access baseline, including authentication strengths, exclusions, break-glass accounts and legacy authentication.
Cloud security assessment
Configuration and architecture assessment for Azure, GCP and Alibaba Cloud: identity, network, data, logging and CSPM findings with a fix roadmap.
Cloud architecture review
Design-stage review of cloud and hybrid architecture: trust boundaries, identity model, segmentation, key management and detection design.