Home » Blog » Conditional Access Policy – Building Real MFA Enforcement in Microsoft Entra ID

Conditional Access Policy – Building Real MFA Enforcement in Microsoft Entra ID

Security Defaults are a great first step for organizations that are just getting started with MFA enforcement in Microsoft Entra ID. They are easy to enable, they cover the most critical scenarios, and they require zero configuration. But as your organization grows and your security requirements become more complex, Security Defaults start to show their limits. When you need exclusions, app-specific controls, or location-based rules, you need Conditional Access.

This post the second part on a series on securing Microsoft Entra ID with MFA and Conditional Access policies. In this post and video, we cover why Security Defaults fall short, break down the anatomy of a Conditional Access policy, and walk through building and enforcing your first policy in the Entra ID portal.

Why Security Defaults Are Not Enough

Security Defaults are intentionally simple. That simplicity is what makes them easy to enable, and it is also what limits them. You cannot exclude specific users or groups, you cannot target individual cloud apps, and you cannot adjust requirements based on factors like location, device state, or sign-in risk. It is all or nothing.

For a small organization with straightforward requirements, that trade-offs are acceptable. But the moment you have a service account that cannot register for MFA, an executive who needs a different experience, or a compliance requirement that applies only to specific applications, Security Defaults cannot help you. That is when Conditional Access becomes the right tool.

Licensing Requirements

Before building your first Conditional Access policy, it is worth confirming your licensing. Conditional Access requires Microsoft Entra ID P1 or P2, which is included with Microsoft 365 Business Premium, E3, and E5 and other licensing plans. It is also available as a standalone license and as a time-limited trial in most tenants. If you are unsure what licenses are active in your tenant, check the Licenses blade in the Entra ID portal before getting started.

Security Defaults and Conditional Access Cannot Coexist

This is one of the most important things to understand before you start building policies. You cannot run Security Defaults and Conditional Access policies at the same time. When you move to Conditional Access, you need to disable Security Defaults first. That creates a brief window where MFA is not enforced, so it is important to move through the steps quickly and minimize the gap in coverage. The section below shows how to do that. See the video for a full walkthrough of the process.

The Anatomy of a Conditional Access Policy

Every Conditional Access policy follows the same structure. At its core, it is an if-then statement. If these conditions are met, then enforce these controls. Once you understand the three building blocks, everything else falls into place.

Assignments define who the policy applies to and what resources it covers. On the user side, you can target all users, specific users or groups, or directory roles like Global Administrator. You can also exclude specific users or groups, which is something Security Defaults cannot do and is critical for break-glass accounts and service accounts. On the resource side, you can target all cloud apps or get specific with individual applications like Exchange Online or SharePoint.

Conditions define when and how the policy applies. This is where Conditional Access becomes genuinely powerful. You can evaluate factors like sign-in risk, user location, device platform, client app type, and whether the device is compliant or joined to Entra ID. For the first policy in this series, we are leaving conditions unconfigured, so the policy applies universally. We will layer in conditions in an upcoming video.

Access Controls define what happens when the policy is triggered. You can grant access with requirements attached, such as requiring MFA, requiring a compliant device, or requiring a specific authentication strength. You can also block access entirely. For our first policy, the control is simple: grant access and require multi-factor authentication.

Report-Only Mode: Your Safety Net

Before enabling any Conditional Access policy, you need to know about Report-Only mode. This is one of the most valuable features in Conditional Access and the reason you should never build a new policy and immediately switch it on.

Report-Only mode allows a policy to evaluate every real sign-in and log what it would have done, without enforcing anything. Users are completely unaffected. You get full visibility into how the policy would apply across your tenant before it goes live. This is how you catch misconfiguration before it causes a lockout, and every new policy should start here.

Building Your First Policy – Step by Step

The following steps walk through the full process covered in the demo. If you are following along, it is strongly recommended to do this in a test or lab environment before making changes in production. See the accompanying video for a full walkthrough.

Disable Security Defaults

Sign in to the Azure portal and navigate to Microsoft Entra ID.
Select Properties under Manage.
Scroll to the bottom and select Manage Security Defaults.
Toggle Security Defaults to Disabled.
Select the reason, such as “My organization is planning to use Conditional Access” and select Save.

Create the Conditional Access Policy

In Entra ID, go to Security under Manage, then select Conditional Access under Protect.
Select Policies, then select New Policy.
Give the policy a descriptive name. For this example, use “Require MFA for All Users.” A consistent naming standard matters as your policy list grows.
Under Assignments, select Users and choose All Users.
Note the Exclude tab. This is where we can add accounts to be excluded, such as an emergency access account.
Under Target Resources, select All Resources.
Leave Network and Conditions at their defaults for this policy.
Under Access Controls, select Grant, then select Require Multifactor Authentication and click Select.
Set Enable Policy to Report-Only.
Select Create to save the policy.

Once the policy is in Report-Only mode and you have generated some sign-in activity, open Sign-In Logs from the Conditional Access blade under Monitoring. Open a log entry and navigate to the Conditional Access tab. The status will show as Not Applicable because the policy is not enforced yet. Next, go to the Report-Only tab and view details. Details will show you exactly what would have happened, including if the assignments matched, what conditions were evaluated, and what action would have been required.

Use the What If Tool

The What If tool lets you test how policies would apply to a specific user without waiting for them to sign in. From the Conditional Access Policies blade, select What If at the top of the screen. Choose a user, select a target app, set a device type and client app, then select What If to see which policies would apply and what controls would be enforced. This is especially useful for validating policy behavior for admin accounts or users with exclusions before going live.

Enable the Policy

Return to the Conditional Access policy list and open the policy.
Change Enable Policy from Report-Only to On.
Review the lockout warning. Leaving the current user excluded is a sensible precaution to avoid being locked out of the tenant.
Select Save to enforce the policy.

Once the policy is On, any user who signs in without an exclusion will be prompted for MFA. If they have not yet registered, they will be walked through the registration process at sign-in.

What Comes Next

With your first Conditional Access policy in place and MFA enforced across your tenant, you have taken a significant step toward a Zero Trust security posture. But requiring MFA for all users is just the foundation. In upcoming videos, we go deeper into real-world policy scenarios including blocking legacy authentication, restricting access by named location, protecting privileged accounts, and setting up break-glass accounts so you always have a way back in if something goes wrong.

Take Action Today

Conditional Access is one of the most impactful security tools available in Azure and Microsoft 365. Building your first policy is far more straightforward than it might seem. If your organization is still running on Security Defaults, now is the right time to evaluate whether Conditional Access is the better fit. The flexibility it provides is worth the additional configuration, and with Report-Only mode available to test safely, there is no reason to wait.