Tenant-Wide Multifactor Authentication Settings (SC-300)
Why Tenant-Wide MFA Settings Matter
Multifactor authentication (MFA) is one of the most effective security controls available in Microsoft Entra ID (formerly Azure Active Directory). Microsoft reports that MFA can block over 99.9% of account compromise attacks. Tenant-wide MFA settings allow administrators to configure MFA behavior at the broadest organizational level, ensuring a consistent baseline of authentication security across all users, applications, and scenarios. Without proper tenant-wide MFA configuration, organizations risk inconsistent enforcement, security gaps, and user confusion.
What Are Tenant-Wide MFA Settings?
Tenant-wide MFA settings refer to the centralized configuration options in Microsoft Entra ID that govern how multifactor authentication behaves across the entire tenant. These settings include:
1. MFA Service Settings (Legacy Portal): The legacy per-user MFA settings page where administrators can enable or disable MFA for individual users (Enabled, Enforced, Disabled states). While still functional, Microsoft recommends moving to Conditional Access-based MFA.
2. Authentication Methods Policy: A tenant-wide policy that defines which authentication methods are available to users (e.g., Microsoft Authenticator, FIDO2 security keys, SMS, phone call, email OTP, temporary access pass, third-party software OATH tokens, certificate-based authentication). Administrators can target specific methods to specific groups or all users.
3. Microsoft Entra MFA Settings (Additional Cloud-Based MFA Settings): These include:
- Account lockout settings: Number of MFA denials before lockout, lockout duration, and minutes before the counter resets.
- Block/unblock users: Manually block specific users from receiving MFA requests.
- Fraud alert settings: Allow users to report fraud when receiving unexpected MFA prompts. You can configure automatic blocking of users who report fraud.
- OATH tokens: Upload and manage hardware OATH tokens.
- Trusted IPs: Define IP ranges that bypass MFA (for federated tenants). Note that this is different from Named Locations in Conditional Access.
- MFA notifications: Configure whether users receive email notifications when MFA verification is performed on their account.
4. Security Defaults: A Microsoft-provided baseline protection that enforces MFA registration for all users and requires MFA for administrators and when necessary. Security defaults are designed for organizations that do not use Conditional Access policies. Security defaults and Conditional Access are mutually exclusive — you must disable security defaults to use Conditional Access.
5. System-Preferred MFA: A tenant-wide setting that prompts users to use the most secure authentication method they have registered, rather than the least secure. For example, if a user has both SMS and Microsoft Authenticator registered, the system will prompt for Microsoft Authenticator first.
6. Number Matching and Additional Context: Tenant-wide settings for Microsoft Authenticator that require users to enter a number displayed on the sign-in screen (number matching) and show application name and geographic location in the push notification (additional context). Number matching is now enforced by default for all Microsoft Authenticator push notifications.
How Tenant-Wide MFA Settings Work
The interaction between these settings follows a hierarchy and precedence model:
1. Security Defaults vs. Conditional Access:
- If Security Defaults are enabled, basic MFA is enforced for all users when Microsoft deems it necessary, and all admins must always use MFA.
- If Conditional Access is used, Security Defaults must be disabled. Conditional Access provides granular control over when and how MFA is required.
2. Per-User MFA vs. Conditional Access:
- Per-user MFA (legacy) sets a user's MFA state to Enabled or Enforced. When Enforced, the user must complete MFA for all cloud app sign-ins regardless of Conditional Access policies.
- Microsoft recommends disabling per-user MFA and using Conditional Access exclusively for consistent, policy-driven enforcement.
- If both per-user MFA and Conditional Access are configured, the most restrictive setting wins (MFA will be required if either method demands it).
3. Authentication Methods Policy:
- This policy determines which methods users can register and use. Even if MFA is required by Conditional Access, users can only satisfy the requirement with methods enabled in the Authentication Methods policy.
- Methods can be targeted to All Users or specific groups, and can be excluded for certain groups.
- Migration from the legacy MFA and SSPR policies to the unified Authentication Methods policy is managed through a migration toggle (Pre-migration, Migration in Progress, Migration Complete).
4. Fraud Alert and Account Lockout:
- When a user reports fraud, their account can be automatically blocked for 90 days (configurable).
- Account lockout protects against brute-force MFA attacks by locking the MFA mechanism after repeated failures.
5. Trusted IPs and Named Locations:
- Trusted IPs (in MFA service settings) apply specifically to federated users or MFA bypass scenarios.
- Named Locations (in Conditional Access) are the recommended approach for location-based access control and can exclude trusted networks from MFA requirements.
Configuration Locations
- Microsoft Entra Admin Center → Protection → Authentication methods: Authentication Methods policy, system-preferred MFA, number matching, additional context.
- Microsoft Entra Admin Center → Protection → Multifactor authentication: Account lockout, block/unblock users, fraud alert, notifications, OATH tokens, trusted IPs.
- Microsoft Entra Admin Center → Properties → Manage Security Defaults: Enable/disable Security Defaults.
- Microsoft Entra Admin Center → Protection → Conditional Access: Conditional Access policies requiring MFA.
- Legacy Per-User MFA Portal: Accessible via Users → All Users → Per-user MFA button.
Key Relationships to Understand
- Security Defaults provide a simple, baseline level of MFA protection. They are best for small organizations without Entra ID P1/P2 licenses.
- Conditional Access requires Microsoft Entra ID P1 or higher and provides the most granular MFA control.
- The Authentication Methods policy is the unified, modern way to manage which MFA and passwordless methods are available tenant-wide.
- Per-user MFA is considered legacy and should be migrated to Conditional Access.
Exam Tips: Answering Questions on Tenant-Wide Multifactor Authentication Settings
Tip 1: Know the Precedence. If a question asks what happens when both per-user MFA and Conditional Access are configured, remember that MFA will be required if either mechanism demands it. The most restrictive policy wins.
Tip 2: Security Defaults vs. Conditional Access. These are mutually exclusive. If a question mentions enabling Conditional Access, the answer likely involves disabling Security Defaults first. Security Defaults do NOT require any premium license; Conditional Access requires at least Entra ID P1.
Tip 3: Know Where Settings Are Configured. Exam questions often ask where to configure a specific setting. Remember: fraud alerts, account lockout, trusted IPs, and OATH tokens are in the MFA service settings. Authentication methods, number matching, and system-preferred MFA are in the Authentication Methods policy. Named Locations are in Conditional Access.
Tip 4: Fraud Alert Behavior. When a user presses the fraud alert code (0# on phone call), or reports fraud in the Authenticator app, the user's sign-in is denied and their account can be automatically blocked. Know that automatic blocking lasts 90 days by default.
Tip 5: Understand System-Preferred MFA. If a question describes a scenario where an organization wants users to be prompted with their most secure method first, the answer is to enable system-preferred authentication. This is a tenant-level setting.
Tip 6: Number Matching Is Default. As of May 2023, number matching is enforced by default for all Microsoft Authenticator push notifications. If a question references reducing MFA fatigue attacks, number matching and additional context are key answers.
Tip 7: Authentication Methods Migration. If a question asks about consolidating MFA and SSPR method management, the answer involves migrating to the unified Authentication Methods policy and setting the migration state to Migration Complete.
Tip 8: Per-User MFA States. Know the three states: Disabled (user is not enrolled in per-user MFA), Enabled (user is enrolled but must complete registration at next sign-in; MFA not required until registered), Enforced (user has registered and must complete MFA at every sign-in). Conditional Access does not use these states.
Tip 9: Trusted IPs vs. Named Locations. If a question asks about skipping MFA for corporate network users within a Conditional Access policy, the answer is Named Locations (not Trusted IPs from legacy MFA settings). Trusted IPs in MFA settings apply primarily to federated environments.
Tip 10: Licensing Awareness. Security Defaults = Free tier. Conditional Access = Entra ID P1. Risk-based Conditional Access (e.g., requiring MFA only for risky sign-ins) = Entra ID P2. Questions that mention risk-based policies typically require P2 licensing.
Tip 11: Read Carefully for Scope. If a question says 'all users in the tenant,' think Security Defaults or a Conditional Access policy targeting All Users. If it says 'specific groups,' think Conditional Access with group targeting or Authentication Methods policy with group targeting.
Tip 12: Elimination Strategy. Many SC-300 questions present four options where one involves a legacy approach and one involves the modern recommended approach. Microsoft almost always prefers the modern approach: Conditional Access over per-user MFA, Authentication Methods policy over legacy MFA/SSPR method settings, and Named Locations over Trusted IPs.
