A user completes MFA successfully and expects access to continue.

Instead, they see:

Access denied.

This is one of the more confusing Conditional Access scenarios because the sign-in event can clearly show that MFA succeeded.

The mistake is to treat MFA as the final access decision.

It is not.

Microsoft Entra can continue evaluating other requirements, including authentication strength, device compliance, approved client applications, authentication context, and other grant controls. Multiple Conditional Access policies can also contribute to the same decision.

So the useful troubleshooting question is not:

“Why did MFA fail?”

It is:

“What requirement remained unsatisfied after MFA succeeded?”

1. MFA Success Is Not the Same as Access Granted

Consider a simple evaluation:

flowchart TD

    A["User signs in"]
    B["Authentication"]
    C["MFA completed"]
    D["Conditional Access evaluation"]
    E["Other requirements"]
    F["Access decision"]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F

MFA is one part of the authentication and access process.

It does not override another requirement that the user has failed to satisfy.

For example:

flowchart TD

    A["MFA"] --> B["Satisfied"]
    C["Compliant device"] --> D["Not satisfied"]

    B --> E["Overall access"]
    D --> E

    E --> F["Denied"]

The user can therefore truthfully say:

“My MFA worked.”

while the administrator can also truthfully say:

“Conditional Access denied the request.”

There is no contradiction. The two statements describe different parts of the evaluation.

2. The Classic Case: MFA Succeeds, Another Policy Fails

Consider two applicable policies.

Policy A

Require MFA → Success

Policy B

Require compliant device → Failure

The user completes MFA.

The device is not compliant.

The resulting decision is:

flowchart TD

    A["MFA requirement"] --> B["Satisfied"]

    C["Device requirement"] --> D["Not satisfied"]

    B --> E["Access"]
    D --> E

    E --> F["Denied"]

The correct conclusion is:

MFA was not the root cause. The device requirement was.

Do not see:

Policy A → Success

and conclude:

“Conditional Access allowed the user.”

Instead ask:

What else applied?

3. MFA Is Not the Same as Authentication Strength

This is another major source of confusion.

An administrator may see:

MFA completed

and assume:

Required authentication method satisfied

Those are not necessarily equivalent.

Conditional Access can require a particular authentication strength, including strengths such as:

• Multifactor authentication
• Passwordless MFA
• Phishing-resistant MFA

For example, a policy may require:

Authentication strength → Phishing-resistant MFA

The user completes an Authenticator push:

MFA → Completed

But the method does not satisfy the required strength:

Required strength → Not satisfied

The resulting outcome can still be:

Access denied

The important distinction is:

MFA asks whether multifactor authentication occurred. Authentication strength asks whether the authentication method met the required strength.

When investigating this scenario, inspect Authentication details rather than stopping at “MFA completed.”

View larger

Image detail

−100%+Reset✕

4. Multiple Grant Controls Can Be Combined

Authentication strength is only one example.

A Conditional Access policy can introduce several requirements, such as:

• MFA
• authentication strength
• compliant device
• Microsoft Entra hybrid joined device
• approved client application
• app protection policy
• password change
• Terms of Use

Multiple controls can be combined.

For example:

MFA AND Compliant device AND Approved client

A user can satisfy the first requirement and still fail the complete policy requirement.

This changes the investigation from:

“Did MFA succeed?”

to:

“What complete set of requirements did this sign-in have to satisfy?”

View larger

Image detail

−100%+Reset✕

5. Authentication Context Can Add Another Requirement

There is another scenario that looks different from a normal sign-in failure.

The user can access the application normally, but one sensitive action fails.

For example:

“I can access the application, but I cannot perform this privileged action.”

Authentication Context allows Conditional Access requirements to be applied to sensitive resources or actions within an application.

The flow can therefore become:

flowchart TD

    A["Application access"]
    B["Normal authentication"]
    C["Sensitive action requested"]
    D["Authentication Context"]
    E["Additional requirement"]
    F["Step-up authentication"]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F

The investigation should determine:

1. Was an authentication context requested?
2. Was the expected context published?
3. Does a Conditional Access policy target it?
4. Was the resulting requirement satisfied?

This prevents a sensitive-action failure from being incorrectly treated as a general MFA problem.

6. Start With the Exact Sign-In Event

When a user reports:

“MFA succeeded but access was denied.”

do not immediately change the Conditional Access policy.

Start with the exact sign-in event.

Useful filters include:

• user;
• application;
• resource;
• status;
• date and time;
• Conditional Access result;
• correlation information.

Then work through the evidence:

flowchart TD

    A["Basic info"]
    B["Authentication details"]
    C["Conditional Access"]
    D["Device info"]
    E["Location"]
    F["Report-only"]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F

The error message tells you what the user experienced.

The sign-in event tells you what Microsoft Entra evaluated.

7. Read the Conditional Access Results as Evidence

The Conditional Access tab should answer three questions.

Which policies applied?

A policy that was Not applied did not contribute to the decision.

Which requirements succeeded?

A Success result means the applicable requirements for that policy were satisfied.

Which requirement failed?

A Failure result means the policy applied but one or more evaluated requirements were not satisfied.

For example:

Policy A

Require MFA → Success

Policy B

Require compliant device → Failure

The correct diagnosis is not:

“MFA failed.”

It is:

“MFA succeeded, but the compliant-device requirement failed.”

That is the level of specificity you want before making a change.

8. A Practical Evidence Matrix

When MFA succeeds but access is denied, use the sign-in event to answer the following:

The objective is to move from:

“MFA worked.”

to:

“MFA worked, but this specific requirement did not.”

9. Worked Example: MFA Succeeds, Device Fails

Consider a user accessing SharePoint.

The sign-in shows:

flowchart TD

    A["Authentication"]
    A1["MFA"]
    A2["Success"]

    B["Device"]
    B1["Compliant"]
    B2["No"]

    C["Conditional Access"]

    C1["Policy A — Require MFA"]
    C2["Success"]

    C3["Policy B — Require compliant device"]
    C4["Failure"]

    D["Overall evaluation"]
    E["Access denied"]

    A --> A1 --> A2
    B --> B1 --> B2

    C --> C1 --> C2
    C --> C3 --> C4

    A2 --> D
    B2 --> D
    C2 --> D
    C4 --> D

    D --> E

The evaluation can be reconstructed as:

flowchart TD

    A["User"]
    B["SharePoint"]
    C["Policy A applies"]
    D["MFA satisfied"]
    E["Policy B applies"]
    F["Compliant-device requirement"]
    G["Device = non-compliant"]
    H["Access denied"]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G
    G --> H

Root cause

Device compliance.

Not the root cause

MFA.

The appropriate remediation is therefore to investigate the device’s compliance state rather than weaken or remove the MFA requirement.

10. Worked Example: MFA Succeeds, Authentication Strength Fails

Now consider a privileged application.

The policy requires:

Authentication strength → Phishing-resistant MFA

The user authenticates using a method that successfully completes MFA but does not satisfy that strength.

The evidence may therefore look like:

flowchart TD

    A["MFA"]
    A1["Success"]

    B["Required authentication strength"]
    B1["Phishing-resistant"]

    C["Authentication method"]
    C1["Does not satisfy requirement"]

    D["Overall evaluation"]
    E["Access denied"]

    A --> A1
    B --> B1
    B1 --> C
    C --> C1

    A1 --> D
    C1 --> D

    D --> E

The user is not wrong when they say:

“I completed MFA.”

The issue is the difference between MFA completion and the required authentication method.

11. What If the User Can Get In but Something Is Restricted?

Not every Conditional Access issue produces an access-denied sign-in.

Sometimes authentication succeeds and access is granted, but the session is restricted.

For example:

“I can open the application, but I cannot download files.”

or:

“I’m being asked to authenticate again.”

The conceptual flow is:

Authentication → Access granted → Session control → Restricted experience

This is a different troubleshooting path from a failed grant control.

First establish whether the user is actually being denied access, or whether access has been granted with a restricted session.

12. Use Report-Only and What If Before Changing Production Policy

Once the failed requirement has been identified, validate the proposed change before modifying an active policy.

Report-only can help determine how a policy would evaluate without enforcing the result.

What If can help simulate Conditional Access evaluation for a particular user, application, conditions, and access scenario.

These tools are particularly useful when several policies overlap.

The objective is not simply to make the user’s error disappear.

It is to confirm:

Which policy should apply, what it should require, and whether the intended users can satisfy that requirement.

13. Don’t Fix MFA When MFA Isn’t the Problem

This is the operational lesson worth remembering.

If the evidence says:

MFA → Success | Device compliance → Failure

do not remove the MFA requirement.

If it says:

MFA → Success | Authentication strength → Failure

do not automatically weaken the authentication requirement.

If it says:

Authentication → Success | Session control → Restriction

do not remove the authentication policy simply because the user reports a problem.

Remediation should target the failed requirement.

That is the difference between troubleshooting Conditional Access and simply weakening it.

14. A Repeatable Troubleshooting Model

When someone reports:

“MFA worked, but access was denied.”

use this sequence:

flowchart TD

    A["MFA succeeded"]
    B["Find the exact sign-in"]
    C["Review Authentication details"]
    D["Review Conditional Access"]
    E["Identify applicable policies"]
    F["Find the failed requirement"]
    G["Determine why it failed"]
    H["Apply targeted remediation"]
    I["Verify the result"]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G
    G --> H
    H --> I

The most important step is the middle one:

Find the failed requirement.

Everything before it establishes evidence.

Everything after it should address the evidence.

15. The Administrator’s Quick Checklist

Before changing a Conditional Access policy, confirm:

Authentication

• Did primary authentication succeed?
• Did MFA complete?
• Which authentication method was used?

Authentication strength

• Did the policy require a specific authentication strength?
• Did the actual method satisfy it?

Conditional Access

• Which policies applied?
• Which succeeded?
• Which failed?
• Which were not applied?

Grant controls

• Was MFA only one requirement?
• Was a compliant or hybrid-joined device required?
• Was an approved client or app protection required?
• Were multiple grant controls combined?

Context

• Was Authentication Context involved?
• Was step-up authentication triggered?

Session

• Was access actually denied?
• Or was access granted with a restricted session?

Remediation

• Can the failed requirement be fixed directly?
• Can the change be validated with Report-only or What If?

Conclusion

MFA success is evidence, not a verdict.

A user can successfully complete MFA and still be denied because another Conditional Access requirement remains unsatisfied. That requirement may involve authentication strength, device compliance, another applicable policy, authentication context, or another grant control.

The troubleshooting model is therefore simple:

flowchart TD

    A["MFA succeeded"]
    B["What else applied?"]
    C["What did each policy require?"]
    D["Which requirement failed?"]
    E["Why did it fail?"]
    F["Fix that requirement"]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F

The goal is not to make Conditional Access less restrictive.

It is to make the access decision understandable, evidence-based, and precise.

When MFA succeeds but access is denied, don’t troubleshoot the MFA result in isolation. Troubleshoot the complete Conditional Access decision.