JUMP TO SECTIONChoose a lesson section
Authentication proves identity. Conditional Access evaluates context.
Authentication checks who is signing in. Authorization decides what that identity may access. Conditional Access is a policy engine that can place requirements on sign-ins to protected resources based on identity, application and other signals.
Think of a policy as an if–then rule: If a Finance employee accesses SharePoint Online, then require a compliant device. Microsoft Entra uses the policy's targeting, conditions and controls to determine what must happen before access can proceed.
MFA is an authentication requirement. Conditional Access can require MFA, but it can also require other things—like a compliant device. Completing MFA doesn't guarantee a policy-compliant sign-in, and a successful sign-in doesn't automatically grant every application permission.
Want the foundational explanation first? Watch or read Understanding MFA .
Who + what + conditions + controls.
A policy needs a defined audience and target. Conditions can refine when it applies. Grant controls can block access or demand particular requirements before access continues.
Users, groups, roles and target resources such as SharePoint Online. Include or exclude identities deliberately.
Signals such as client app, device platform, network location or risk can refine when a policy applies.
Block, require MFA, require an allowed authentication strength, require device compliance or apply session controls.
Here, a Finance employee on an unmanaged device can meet MFA and still fail the device requirement.
Applicable policies combine. If one enabled policy requires MFA and another requires a compliant device, both requirements matter. A block policy isn't negated because another policy succeeded. Within a grant policy, the administrator can configure selected controls with AND or OR logic where supported.
Not all MFA offers the same protection.
A password followed by an SMS code can satisfy a general MFA requirement. But SMS codes can be phished, so they don't satisfy the built-in phishing-resistant authentication strength.
Better than password-only, but not phishing-resistant.
Properly configured FIDO2 or Windows Hello for Business can satisfy the built-in phishing-resistant strength.
An authentication strength specifies which authentication method combinations can satisfy a policy. Separately, device compliance is about whether the device meets the organization's management and compliance requirements. Neither should be confused with application permissions.
Security Defaults, per-user MFA, Conditional Access MFA grants and Conditional Access authentication strengths are different enforcement approaches. A legacy per-user MFA status of “Disabled” does not, by itself, prove MFA isn't enforced through Security Defaults or Conditional Access.
Alex passed MFA. Why was access interrupted?
Let's follow the fictional event used in Practice Module 003. Alex signs in to SharePoint Online from an unmanaged device using a password and SMS. Three policies are relevant to the investigation, but they don't have the same effect.
The root cause: the enforced compliant-device policy is unmet. General MFA succeeded. The phishing-resistant pilot is in report-only mode, so it does not enforce its proposed grant. Turning off MFA or excluding the entire Finance group would be the wrong response.
The Module 003 policy investigation lets you inspect the fictional sign-in, compare applied policies, and test a compliant device and FIDO2 authentication in a safe simulation.
Use sign-in evidence before touching a policy.
Start with the affected user, application and approximate timestamp. In the Entra admin center, open Entra ID → Monitoring & health → Sign-in logs, select the event, and inspect its Conditional Access and Authentication Details information. Appropriate read permissions are required.
Is this the user, resource, client and time of the problem?
Which enabled policy failed? Which policies succeeded, weren't applied or were report-only?
Authentication strength, device compliance, location and scope each imply different remediations.
Use an appropriately scoped test before broad policy changes. Confirm the actual sign-in outcome afterward.
The What If tool (Entra ID → Conditional Access → Policies → What If) can estimate which policies apply to a specified sign-in scenario. It helps with planning, but does not replace actual sign-in evidence or account for every dependency.
These describe potential outcomes for a proposed policy. They are not an indication that the report-only policy itself enforced a block.
Roll out protection without creating a lockout.
Conditional Access isn't just a configuration exercise. It is change management. A poorly targeted policy can disrupt normal users or even prevent administrators from accessing the tools needed to recover.
Document licensing, existing Security Defaults or Conditional Access protections, important applications, service dependencies and the identities in scope.
Maintain separately secured and monitored emergency-access accounts. Validate that recovery works and that restrictive policies cannot lock them out.
Choose representative users and apps; confirm the necessary methods are registered and any compliance signals are genuinely available.
Review affected sign-in events, unexpected policy matches and user-action-required outcomes. Report-only evaluates but does not enforce the new controls.
Enable the policy for a controlled population with a recovery plan. Expand only after checking real sign-in outcomes and user impact.
Review failed sign-ins and exceptions. Maintain a change log, reassess coverage and keep recovery identities tested.
Security Defaults provides baseline protections without additional premium licensing; custom Conditional Access requires at least Microsoft Entra ID P1 for users in scope. Security Defaults and custom Conditional Access enforcement are not used together. Prepare and validate replacement protections, coordinate the switch carefully, and do not leave the tenant without equivalent security controls.
Tenant-wide presets with limited customization.
No extra Entra premium license required.Define targeting, signals and controls deliberately.
Requires eligible P1 licensing; some advanced risk-based features need P2.Five questions before you practice.
01 / Alex completed MFA. How could Conditional Access still interrupt access?
An applicable enforced policy may require another grant, such as a compliant device. One policy succeeding does not cancel another policy's requirement.
02 / Does an SMS code satisfy a phishing-resistant MFA authentication strength?
No. A password plus SMS can satisfy a general MFA grant but not the built-in phishing-resistant strength. An appropriately configured FIDO2 security key or Windows Hello for Business is a stronger example.
03 / Why shouldn't an admin immediately enable a new policy for every user?
Assignments, exclusions, methods, device readiness and dependent applications might not behave as expected. Use report-only evaluation, pilot users, emergency access and real sign-in testing first.
04 / A report-only policy says 'User action required.' Did that policy block the sign-in?
No. It means the proposed control would need additional user action if enforced. Another enabled policy may still block or interrupt the actual sign-in.
05 / Can you keep Security Defaults on while replacing them with custom Conditional Access?
Security Defaults must be disabled to use the custom Conditional Access replacement. Prepare appropriately licensed protections and a coordinated transition so you don't leave the tenant exposed.
Check the source.
Microsoft features, licensing and administrative paths change. These official references are the best place to validate current behavior before working in a production tenant.