Microsoft 365 / MFA setup: security defaults or Conditional Access?

When applying multi-factor authentication (MFA) in Microsoft 365, if you need simple organization-wide basic protection, review Security Defaults. If you need conditional policies based on users, apps, locations, or devices, review Conditional Access. The two methods are not intended to be enabled simultaneously. Conditional access requires appropriate Microsoft Entra licenses and policy design.

Differences between Security Defaults and Conditional Access

According to Microsoft's Security Defaults Guidance and Conditional Access Deployment Plan, security defaults and conditional access are not used simultaneously. For product-specific licenses, check the latest conditions at Microsoft Entra License Information.

MFA registration, requirements, and completion are different

Multifactor authentication (MFA) verifies identity using two or more distinct authentication factors. A password is one possible factor; supported passwordless methods can also satisfy MFA requirements. You need to separately check the fact that an authentication app was registered, that MFA was required for a specific login, and that this requirement was actually fulfilled. If you only register it without applying the policy, the intended protection may not be achieved.

Conversely, the absence of authentication prompts every time does not mean MFA is turned off. The authentication status of the existing session or token may have been recognized, so it is determined from the login record. Even if the legacy per-user MFA screen shows “Disabled”, MFA may be applied through security defaults or conditional access. Do not enable legacy per-user MFA based solely on this indication.

Questions to check before making a decision

• Which authentication policies are already enabled in the current tenant? A new tenant may have security defaults turned on.
• Which authentication methods have administrators and regular users registered? A pre-deployment preparation guide may be necessary.
• Are there old apps or devices using legacy authentication? You need to check the possibility of work interruption if blocked.
• Do you have an emergency admin account and recovery procedures prepared? All administrators could be locked out due to incorrect conditional access policies.
• Does the user have a license to use the required features?

Procedure for reviewing security defaults

1. Sign in to the Microsoft Entra admin center with the required permissions.
2. [Entra ID] → [Overview] → [Properties] to find the location for managing security defaults. If the menu structure has changed, search for “Security Defaults” in the admin center search.

3. Record the current status and investigate affected administrators, users, and apps. Notify the organization and prepare for authentication registration, then decide whether to apply.
4. If you select security defaults, apply them via Manage security defaults → Enabled → Save. Configuring security defaults requires at least the Conditional Access Administrator role. Guide users through the registration process for supported authentication methods.
5. Check the new login flow for administrators and general users, and inspect authentication registration and login logs. Include whether existing login sessions will be maintained in the deployment plan. Revoking existing sign-in sessions affects user work, so it should be performed within an approved scope after notification and preparation for support.

The security defaults do not provide a way to add exceptions for individual users. Before turning off the overall default protection just because only certain legacy devices need to bypass it, review whether you need to change the authentication method for those devices or transition to a conditional access design. Do not schedule user guidance based on a previous document’s MFA registration grace period.

When introducing conditional access

In the Microsoft Entra admin center, open Conditional Access → Policies. Depending on the screen layout, it may be under the security menu of Entra ID or can be found through the admin center search. Check that you have the role required to create or modify policies and that affected users have the necessary licenses. Common conditional access requires Entra ID P1, and conditions based on user or sign-in risk require P2, etc.

When switching from security defaults, you need to design and verify an alternative policy and set a transition time. Simply turning off security defaults and creating a Report-only policy does not provide equivalent protection. Microsoft recommends immediately activating the protection policy after disabling defaults. Therefore, the Report-only exercises below should be carried out in a test environment where existing protection is maintained or according to a transition plan, and not used as a preparatory step to first disable protection in an operational organization.

1. Enter a name in the new policy that clearly indicates its purpose and target. For example, write it like "Require MFA for pilot users."
2. Include the test group in users and compare with the target accounts. Emergency accounts should be excluded from login-blocking or restricted policies according to the Emergency Access Account Design, and separate strong authentication and monitoring should be prepared.
3. Determine the apps/resources to protect in the target resources. Do not interpret the results of testing a single app as automatically applied to all services.
4. Under Grant controls, select the requirement for MFA and save the policy state as Report-only. Do not mix blocking, compliant devices, and risk conditions from the beginning; check what effect each requirement produces.
5. Log in to the resource with a test account and check the targets, requirements, and expected failure causes of the policy in the Report-only results of the sign-in events. Report-only does not actually enforce access control of this policy.

Verification before and after activation and rollback

Record the expected results in a table first. For example, test users should meet MFA requirements in the specified app, and users outside the target should not be affected by the new policy. However, other policies or Microsoft-mandated authentication requirements may be applied separately, so excluding one policy does not mean a complete MFA exemption.

After reviewing the report-only results and actual tests, set the policy to On starting with the approved pilot. Then, check the authentication requirements and access results in new logins and expand the target. Microsoft's deployment plan recommends reviewing impacts in report-only mode for at least a week before enforcing the policy. Use that observation period to collect representative sign-in results for key roles and apps; elapsed time alone is not sufficient validation.

If an issue occurs, check the policies applied in the Conditional Access tab of the failure event. If a new policy is the cause, use the prepared administrative access path to set that policy to Report-only or Off, and verify that existing protections are maintained. Do not turn off all policies at once or leave them as long-term exceptions. After recovery, correct the target, conditions, and authentication methods, and reapply the policy only after passing the same test again.