Conditional Access enforcement is covered in Phase 8. But several decisions that determine whether Conditional Access works correctly belong in Phase 2 – before devices enroll, before policies are deployed, and before anyone touches the Conditional Access blade.
This article exists because the gap between “we have Conditional Access configured” and “Conditional Access is actually enforcing what we think it’s enforcing” is almost always rooted in prerequisites that weren’t addressed early enough. Getting these right before the rest of the deployment builds on top of them is significantly cheaper than fixing them after the fact.
MFA registration is the most fundamental prerequisite. Conditional Access policies that require MFA only work if users have registered an authentication method. Deploying a “require MFA for all users” policy before users have registered is a lockout event – users fail the MFA challenge because they have no registered method, and they lose access. The correct sequence is to run a registration campaign first, validate that registration rates are acceptable across your user population, and then enable enforcement. Microsoft’s Authentication Methods policy and the registration campaign feature in Entra ID make this manageable, but it requires deliberate scheduling – not a last-minute step before go-live.
Enabling MFA enforcement before users have registered authentication methods is not a security improvement – it’s an outage. Registration must come before enforcement, always.
Legacy authentication assessment is the second prerequisite that consistently gets skipped. Legacy authentication protocols – SMTP, POP3, IMAP, older Office clients using basic auth – cannot complete MFA challenges. A Conditional Access policy that blocks legacy authentication will break any client or workflow still using those protocols. Before enabling legacy auth blocking, you need to understand what in your environment is still using it. The Entra ID sign-in logs filtered by client app will show you this clearly – look for clients identified as “Other clients,” “Exchange ActiveSync,” or legacy Office versions. That assessment should happen before the tenant is fully configured, not as a reactive exercise after something breaks.
Break-glass accounts are a prerequisite, not an afterthought. Every Conditional Access deployment needs at least two emergency access accounts that are excluded from all Conditional Access policies – cloud-only accounts, no MFA requirement, stored credentials accessible outside normal IT channels. These accounts exist for the scenario where Conditional Access misconfiguration or a major identity incident locks out all administrators. Without them, a misconfigured policy or a federated identity provider outage can lock everyone out of the tenant with no recovery path. Create and test these accounts before enabling any Conditional Access enforcement.
Break-glass accounts aren’t optional. They’re the emergency exit. Not having them isn’t a calculated risk – it’s an unrecoverable situation waiting to happen.
Named locations should be defined before you write policies that reference them. Trusted IP ranges – your office networks, known VPN exit points – need to be created and named deliberately so that Conditional Access policies can reference them by name rather than embedding IP addresses directly in policy conditions. Getting naming consistent across named locations makes the policy set readable later. Creating them reactively, as policies need them, produces an inconsistently named set of locations that’s hard to reason about at scale.
Licensing validation is often assumed and rarely verified. Conditional Access requires Entra ID P1 at minimum for all users in scope. Features like risk-based policies, Identity Protection, and the full sign-in risk signal capability require Entra ID P2. If users in scope for a Conditional Access policy don’t have appropriate licensing, the policy behavior is undefined – not reliably enforced. Verify licensing coverage before deploying policies that depend on features those licenses unlock.
The Conditional Access what-if tool is worth running during Phase 2 setup, before any enforcement is live. It lets you simulate how a specific user, device state, and application combination would be evaluated by your current policy set – including any Microsoft-managed baseline policies that may already be in place in your tenant. Running what-if scenarios during setup reveals gaps and overlaps before they affect real users. Running it only after something breaks is a more expensive way to get the same information.
None of these prerequisites are complex. All of them are cheap to address early and expensive to fix after enforcement is live. Phase 8 covers the full Conditional Access design. This article exists to make sure the foundation that design builds on is solid before you get there.
Intune Deployment Guide · Phase 2: Identity and Tenant Foundation
‹ Previous: [2.3.1] The Naming Convention Playbook
Next: [2.5] Windows Hello for Business: The Credential the Framework Already Assumed ›
