Blog / Identity and access
Conditional Access defaults: what to block first.
Microsoft 365 Conditional Access is deceptive: the platform ships with the tooling but not the policies. On day one, sign-ins are evaluated against nothing. Rolling out policies in the wrong order breaks user workflows before it reduces risk. This post covers the sequence that produces the largest risk reduction per hour of rollout work.
Phase 1: block legacy authentication
Legacy auth protocols (POP, IMAP, SMTP AUTH, EWS, ActiveSync basic auth) bypass MFA entirely. If any account uses them, the account is one credential leak away from compromise regardless of what else you do. Block first. Impact on user workflows in 2026 is nearly zero because Modern Auth clients handle all the legitimate use cases.
Policy: ”Block legacy authentication” for all users, all cloud apps. Roll out in report-only for one week to confirm no legitimate legacy client remains, then flip to enforcement.
Phase 2: block high-risk sign-ins
Entra ID Protection scores every sign-in for risk based on impossible travel, anonymous IP, leaked credentials, and other signals. Sign-ins scored ”high risk” are almost always compromises in progress. Block them at the sign-in event, not after they succeed.
Policy: ”Require reauthentication with MFA and password change for high-risk sign-ins” applied to all users. Users at the boundary see friction; genuinely compromised sessions are stopped.
Phase 3: require MFA for admins
Every administrative role (Global Admin, Security Admin, Exchange Admin, Intune Admin, Application Admin, Cloud Application Admin, Conditional Access Admin, User Access Admin, Helpdesk Admin, Directory Writer, Privileged Role Admin) requires phishing-resistant MFA. Break-glass accounts documented and excluded.
Policy: ”Require phishing-resistant MFA for privileged roles”. Assign to the built-in Entra security groups that map to each admin role. Ensure at least two named break-glass accounts are excluded, with alerting on any sign-in attempt from them.
Phase 4: require device compliance for privileged access
Even with MFA, admins signing in from an unmanaged, unpatched device open a path for token theft and session hijack. Require device compliance (managed by Intune) for any admin action.
Policy: ”Require Intune-compliant device for privileged users”. Applies to the same group as phase 3. Users get one grace week to enrol their admin workstation in Intune; after that, non-compliant device is blocked from admin actions.
Phase 5: require MFA for all users
Now the general population. MFA everywhere, with phishing-resistant methods (Windows Hello for Business, passkeys, FIDO2) rolled out through registration campaigns before enforcement.
Policy: ”Require MFA for all users”. Excluded groups: emergency access, service accounts (which should have workload-identity restrictions instead), and legacy printer/scanner accounts (which should be migrated to Modern Auth or replaced with connectors).
Phase 6: block non-compliant devices for sensitive apps
The general-user version of phase 4. Apps holding regulated data (finance, HR, source control, customer data) require a compliant device. Personal devices can access mail and Teams; not the regulated app set.
What order will not work
The most common rollout failure: turning on device compliance first for all users before rolling out Intune enrolment. Result: nobody can sign in until IT enrols every device. Support desk floods, policy is disabled within hours, the security team stops trusting Conditional Access as a control. Always build the enabling capability before the blocking policy.
Related