Enforce MFA in Microsoft 365

Implementing multi-factor authentication (MFA) across Microsoft 365 services is a critical security measure to protect user identities and organizational…

Implementing multi-factor authentication (MFA) across Microsoft 365 services is a critical security measure to protect user identities and organizational data from unauthorized access. While Microsoft offers various methods to enable MFA, Conditional Access policies in Microsoft Entra ID (formerly Azure Active Directory) provide the most granular control, allowing administrators to define specific conditions under which MFA is enforced.

This article details the process of configuring an Entra Conditional Access policy to enforce MFA for all users accessing Microsoft 365 applications, covering best practices, policy components, and deployment strategies.

Understanding Conditional Access Policies for MFA

Conditional Access policies evaluate identity signals (such as user, location, device, application, and real-time risk) to make decisions and enforce organizational access requirements. For MFA, this means defining "when" and "how" users must authenticate with a second factor.

Key components of a Conditional Access policy for MFA include:

Users or workload identities: Who the policy applies to (e.g., all users, specific groups).
Cloud apps or actions: Which applications or actions the policy targets (e.g., all cloud apps, specific Microsoft 365 services).
Conditions: Specific contextual elements that must be met (e.g., sign-in risk, device platform, location).
Grant: What happens when conditions are met (e.g., require MFA, block access).
Session: How access is controlled once granted (e.g., sign-in frequency).

Initial Setup and Best Practices

Before creating your MFA enforcement policy, ensure the following prerequisites are met and best practices are considered:

Microsoft Entra ID P1 or P2 license: Conditional Access is a premium feature.
Admin Roles: Global Administrator, Security Administrator, or Conditional Access Administrator.
Exclude Break-Glass Accounts: Create and exclude at least two "break-glass" or emergency access accounts. These highly privileged accounts are cloud-only, not synchronized from on-premises directories, and are exempt from all Conditional Access policies to prevent lockout in case of misconfiguration or directory issues. Secure them meticulously.
Communication Plan: Inform users about the upcoming MFA requirement, provide instructions for registration, and set clear expectations.
MFA Registration: Encourage or enforce MFA registration before policy enforcement. Users can register through mysignins.microsoft.com/security-info.

Configuring the Conditional Access Policy for MFA

Follow these steps to create a new Conditional Access policy:

1. Navigate to Conditional Access Policies

In the Microsoft Entra admin center:

Go to Protection > Conditional Access.
Click New policy.
Give the policy a descriptive name, e.g., "MFA for All Users - M365 Access".

2. Assign Users and Groups

Under Assignments:

Select Users or workload identities.
Under Include, select All users.
Under Exclude, select Users and groups and then select your designated break-glass accounts. This is crucial for avoiding administrative lockout.

3. Target Cloud Apps

Under Target resources:

Select Cloud apps or actions.
Under Include, select All cloud apps. This ensures MFA is enforced for all Microsoft 365 services (Exchange Online, SharePoint Online, Teams, etc.) and any other enterprise applications integrated with Entra ID.

4. Define Conditions (Optional but Recommended)

While not strictly necessary for basic "all users, all apps" MFA, conditions allow for more sophisticated controls. For a baseline MFA policy, you might omit these, but consider:

Device platforms: You might choose to exclude specific device types if your organization has a unique compliance posture (e.g., legacy mobile devices). For most cases, keep "Any device".
Locations: You could enforce MFA for connections from outside trusted network locations. For a universal MFA policy, keep "Any location" or define trusted locations and require MFA only for "Any location" excluding trusted ones.
Client apps: Typically "Browser" and "Mobile apps and desktop clients" should be included to cover all access methods.
Sign-in risk: For Entra ID P2 customers, integrate with Identity Protection to require MFA when sign-in risk is detected. This is a powerful enhancement.

5. Grant Access Control

Under Access controls:

Select Grant.
Choose Grant access.
Tick Require multi-factor authentication.
For the most robust security, also tick Require device to be marked as compliant and/or Require hybrid Entra ID joined device if you manage devices with Intune or have a hybrid AD environment. However, these require additional device management policies to be in place. For basic MFA, "Require multi-factor authentication" is sufficient.

6. Configure Session Controls (Optional)

Under Access controls > Session:

Consider Sign-in frequency. Setting this to "Every time" or "X hours" can enhance security, but may impact user experience. A common setting is "8 hours" or "1 day" to balance security and usability.
Persistent browser session: "Always persistent" or "Never persistent". "Never persistent" (requires re-authentication after browser close) is more secure.

# Example of a simplified Conditional Access policy structure
# (Not actual YAML config, but illustrative representation)
name: "MFA for All Users - M365 Access"
state: "Report-only" # Important for initial deployment

assignments:
  users:
    include:
      - "All users"
    exclude:
      - "Break-Glass Account 1"
      - "Break-Glass Account 2"
  cloud_apps:
    include:
      - "All cloud apps"

conditions:
  # Example - you might omit conditions for a basic "all users, all apps" MFA
  # locations:
  #   include: "Any location"
  #   exclude: "Trusted IPs" # Requires defining named locations

grant_controls:
  access_granted: true
  requirements:
    - "Require multi-factor authentication"
    # - "Require device to be marked as compliant" # If Intune is deployed
    # - "Require hybrid Entra ID joined device"   # If hybrid AD is deployed

session_controls:
  sign_in_frequency:
    value: "1 day" # Re-authenticate every 24 hours

Deployment Strategy: Report-Only First

Crucially, never enable a new Conditional Access policy directly to "On" without testing.

Report-only: Set the policy to Report-only mode first. This mode logs the outcome of the policy as if it were enforced, without actually blocking or granting access based on the policy.
Monitor and Analyze: After activating in Report-only mode, monitor the Conditional Access insights and reporting for a few days to weeks (depending on user activity). Go to Monitoring > Sign-in logs in the Entra admin center. Filter by "Conditional Access" and check the "Report-only (preview)" tab. Look for "MFA for All Users - M365 Access" and review the outcome for various users. Identify any unexpected "Failure" outcomes or legitimate users who would be blocked.
Adjust and Test: Based on the reports, refine your policy exclusions or conditions if necessary. You might find certain service accounts or applications that need specific exclusions.
Pilot Deployment (Optional): For very large or complex environments, consider deploying the policy to a small pilot group of users first (e.g., a security group of IT staff) rather than "All users" immediately.
Enable Policy: Once you are confident that the policy will not cause unintended disruptions, change the policy state from Report-only to On.

Common Pitfalls and Troubleshooting

Lockout of Administrators: The most common and severe issue. Always have break-glass accounts excluded and test thoroughly. If you get locked out, use a break-glass account to disable the problematic policy.
MFA Registration Prompt: Users will be prompted to register for MFA upon their first sign-in after the policy is enforced. Ensure your communication and support channels are ready for this.
- If a user cannot register, check their Entra ID health, ensure they have a phone or authenticator app available, and that their account isn't blocked.
- For users without smartphones, consider hardware tokens if supported by your Entra ID configuration.
Legacy Authentication Protocols: Conditional Access does not natively support legacy authentication (e.g., POP3, IMAP, SMTP, older Exchange ActiveSync clients) that do not use modern authentication methods. If these protocols are enabled and used, they will bypass Conditional Access policies, including MFA.
- Recommendation: Disable legacy authentication globally in your tenant to protect against these vulnerabilities. This can be done via Entra ID settings or specific application access policies. For example, in Exchange Online, you can use an authentication policy.
- Checking Legacy Auth: Review Entra ID sign-in logs for client apps showing "Other clients" or specific legacy protocol names.
Service Accounts: Non-interactive service accounts or applications that authenticate programmatically may fail if they are included in an MFA policy. Exclude these accounts or use managed identities/service principals where appropriate.
VPN/Network Issues: If your organization uses VPNs and "trusted locations" are defined, ensure the VPN IP ranges are correctly added as named locations in Entra ID.
Device State Conditions: If you select "Require device to be marked as compliant" or "Require hybrid Entra ID joined device" without corresponding Intune compliance policies or Hybrid Join setup, users will be blocked. Ensure these are configured first or start with only "Require multi-factor authentication."