Microsoft Entra ID: require MFA with Conditional Access

Implementing multi-factor authentication (MFA) is a critical security control for modern identity platforms. Microsoft Entra ID (formerly Azure Active…

Implementing multi-factor authentication (MFA) is a critical security control for modern identity platforms. Microsoft Entra ID (formerly Azure Active Directory) offers robust MFA capabilities, most effectively enforced through Conditional Access policies. This article details the creation and deployment of a Conditional Access policy to mandate MFA for all user sign-ins, discussing best practices, common configurations, and essential considerations.

The core principle is to define conditions under which access to cloud applications is granted, and what controls must be satisfied. This allows for granular control, ensuring that sensitive resources always require stronger authentication, while potentially allowing more lenient access under trusted conditions.

Understanding Conditional Access Components

A Conditional Access policy is built upon several key components that dictate its behavior. Familiarity with these components is essential for effective policy design.

Users or workload identities: Specifies which users, groups, or service principals the policy applies to. It's crucial to exclude emergency access (break-glass) accounts from any "All users" policy.
Cloud apps or actions: Defines the target resources or actions the policy protects. This could be specific applications, or all cloud apps.
Conditions: These are the "if" statements that trigger the policy. Common conditions include device platforms, locations, client apps, device state, and sign-in risk.
Grant: These are the "then" statements that specify the access controls. This is where MFA is enforced, but also includes requiring compliant devices, hybrid Entra ID joined devices, or terms of use acceptance.
Session: Controls applied after access is granted, such as sign-in frequency or persistent browser sessions.

Crafting the "Require MFA for All Users" Policy

This foundational policy ensures that every user, attempting to access any cloud application within your Entra ID tenant, is prompted for MFA. This is a baseline security improvement for virtually all organizations.

Policy Creation Steps in Microsoft Entra Admin Center

Navigate to the Microsoft Entra admin center (entra.microsoft.com).
In the left-hand navigation, expand Protection, then select Conditional Access.
Click on New policy in the toolbar.
Provide a descriptive name, e.g., CA001: Require MFA for All Users to All Cloud Apps.
Under Assignments:
- Users or workload identities:
  - Select All users.
  - Under Exclude, select Users and groups, and add your designated emergency access account(s). This is paramount to prevent lockout.
- Cloud apps or actions:
  - Select All cloud apps. This ensures broad coverage. For more granular control, you could select specific applications.
Under Access controls:
- Grant:
  - Select Require multifactor authentication.
  - Ensure Require one of the selected controls is chosen.
Under Enable policy:
- Initially, set this to Report-only. This allows you to monitor its impact without enforcing it.
Click Create.

A typical policy configuration in JSON format (as seen via Graph API or Policy Details view) might look like this:


{
  "displayName": "CA001: Require MFA for All Users to All Cloud Apps",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "users": {
      "includeUsers": [
        "All"
      ],
      "excludeUsers": [
        "<object_id_of_emergency_account_1>",
        "<object_id_of_emergency_account_2>"
      ]
    },
    "applications": {
      "includeApplications": [
        "All"
      ]
    },
    "clientAppTypes": [
      "all"
    ],
    "locations": null,
    "devicePlatforms": null,
    "signInRiskLevels": null,
    "userRiskLevels": null
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": [
      "mfa"
    ]
  },
  "sessionControls": null
}

Note: The state field corresponds to "Report-only", "On", or "Off".

Emergency Access Accounts (Break-Glass Accounts)

An absolute requirement for any organization implementing Conditional Access is the establishment and careful management of emergency access accounts. These accounts serve as a failsafe to prevent complete lockout from your Entra ID tenant if Conditional Access policies are misconfigured or if authentication services experience an outage. The Microsoft documentation typically recommends at least two such accounts.

Exclusion: These accounts MUST be excluded from all Conditional Access policies that could potentially prevent their sign-in, especially those requiring MFA, compliant devices, or specific network locations.
Strong Passwords: Use extremely long, complex, randomly generated passwords. Store them securely, perhaps in an encrypted vault, and split the password among multiple key personnel.
Monitoring: Implement strong auditing and alerting for these accounts. Any sign-in attempt from an emergency access account should trigger high-priority alerts to security teams. Regularly review their sign-in logs.
No Licenses: Do not assign licenses to these accounts unless absolutely necessary for specific administrative tasks that require a license.
Restricted Permissions: Grant only the necessary permissions (e.g., Global Administrator) for emergency situations. Avoid daily use.

Phased Rollout and Monitoring (Report-only Mode)

Deploying Conditional Access policies directly to "On" can have unintended consequences, potentially locking out users. The "Report-only" mode is invaluable for validating policy behavior without actual enforcement.

Initial Deployment: Create the policy in "Report-only" mode.
Monitoring Period: Allow the policy to run in "Report-only" for a minimum of 1 week (or longer, depending on your organization's sign-in patterns).
Utilize Sign-in Logs:
- In the Entra admin center, navigate to Identity > Monitoring & health > Sign-in logs.
- Add a filter for Conditional Access and select Report-only (applied) or Report-only (not applied).
- Analyze these logs to identify any users who would have been blocked or prompted for MFA unexpectedly. Pay close attention to service accounts or applications that might not support interactive MFA prompts.
Workbook Insights: Leverage the Conditional Access workbooks (under Conditional Access > Insights and reporting) for aggregated views of policy impact.
Iterate: Based on the report-only findings, adjust your policy inclusions/exclusions as needed. For example, if you find a legacy application failing, you might temporarily exclude it and plan for modern authentication upgrades.

Transitioning to Enforcement

Once you are confident the policy will not cause widespread disruption after careful monitoring in "Report-only" mode:

Return to the Conditional Access policy in the Entra admin center.
Change Enable policy from Report-only to On.
Click Save.

Even after enabling, continue to monitor sign-in logs for any new issues. It's often beneficial to roll out to a pilot group first if "All users" is too broad for an initial "On" state. This can be achieved by including a specific group in the policy instead of "All users," then gradually adding more groups.

Advanced Considerations and Best Practices

While a "Require MFA for All Users" policy is a strong baseline, Conditional Access offers much more granularity. Consider these extensions:

Device State: Require devices to be either "Compliant" (managed by Intune) or "Hybrid Entra ID Joined" for accessing sensitive apps. This provides device context to access decisions.
Location-Based Policies: Block access from specific countries or regions (e.g., known high-risk locations). Alternatively, enforce MFA more strictly for sign-ins from outside trusted corporate network ranges.
Client Apps: Differentiate access based on the client application used (e.g., requiring MFA only for browser access, but not for modern desktop apps that already handle session tokens securely). Be cautious with legacy authentication clients, as they often don't support MFA.
Sign-in Risk and User Risk: Integrate with Entra ID Protection to dynamically require MFA, change password, or block access based on real-time risk detections (e.g., impossible travel, unfamiliar sign-in properties, leaked credentials).
Named Locations: Define trusted IP ranges (e.g., corporate offices, VPN endpoints) as "Named locations" to create more nuanced location-based policies. This can help reduce MFA prompts for users on trusted networks.

Common Pitfalls and Troubleshooting

Excluding Emergency Accounts: The most critical pitfall. Failing to exclude emergency accounts is the primary cause of tenant-wide lockout. Always double-check this.
Ignoring Report-only Logs: Rushing to "On" without thoroughly reviewing report-only insights can lead to widespread access issues for users or applications.
Blocking Legacy Authentication: If you select "All client apps" and have users or applications relying on legacy authentication protocols (e.g., POP3, IMAP4, older Outlook versions without modern auth), they will be blocked. Consider a separate policy to block legacy authentication explicitly, allowing you to manage exceptions, or enforce modern authentication.
Overlapping Policies: While Entra ID typically processes policies sequentially, unintended interactions can occur. Keep policies as focused as possible. If multiple policies apply, the most restrictive grant control wins. If one policy grants access and another blocks, the block takes precedence.
User MFA Registration State: Users must have registered at least one MFA method before a policy requiring MFA can be satisfied. If a user hasn't registered, they will be prompted to do so during their first sign-in under an MFA-requiring policy. Ensure proper communication and user guides are available.
Licensing: Conditional Access features require an Entra ID P1 license (or equivalent, such as Microsoft 365 E3/E5). Users affected by the policy must have the appropriate license.