Why MFA Success Can Still Result in Access Denied
Understand why Microsoft Entra can deny access after MFA succeeds, and learn how to identify the Conditional Access requirement that actually failed.
Read article →
Support Engineering Weekly
Episode 003
When MFA Succeeds but Access Is Still Denied
Why can a user successfully complete MFA and still receive an access-denied result? Alex and Maya examine what happens after MFA succeeds and how Conditional Access, authentication strength, grant controls, device requirements, Authentication Context, and session controls can influence the final access decision.
00:0023:49
ChapterWhy MFA Can Succeed Yet Access Is Denied
Transcript
Read the conversation
Follow the episode as a written conversation. Transcript entries are synchronized with the audio player.
You are listening to Support Engineering Weekly.
So start with a scenario that, you know, pretty much every IT
administrator listening to this has probably faced at least once this week.
Oh yeah, the dreaded all caps ticket.
Exactly.
You open your ticketing queue, and there's this high priority
ticket just staring at you.
The user is practically shouting, insisting like, "My MFA worked. I hit
approve on my phone. I saw the green check mark." But then you pull up the
Microsoft Entra sign-in logs, right?
Right.
And the system is just staring right back at you with this giant
uncompromising red access denied.
Which is just the worst because you assume the user is either
lying or, well, deeply confused.
And the user assumes IT is just completely broken.
Yeah.
But the wild part of this entire standoff is that, uh, both of you are
actually telling the absolute truth.
It's the ultimate IT stalemate.
The user genuinely did complete the multi-factor authentication
challenge, and the system genuinely did slam the door in their face.
There's zero contradiction there, even though it like structurally
feels like reality is bending.
Yeah.
And we see this mismatch drive help desks absolutely crazy, mostly
because they're operating under a fundamental misunderstanding of what
that MFA prompt actually represents.
By the way, I'm Alex.
And I'm Maya.
And we wanna explicitly thank you for joining us on this deep dive.
Today, we are tearing into the Microsoft Entra conditional access architecture.
We really need to unpack exactly why MFA success is emphatically
not the final access decision.
Right.
So our mission today is to equip you with an evidence-first troubleshooting model.
We want you to stop guessing, identify the exact failing requirement
in your logs, and, you know, avoid accidentally weakening your
organization's security posture.
Just to get a loud VIP off your back.
Which is a temptation we've all felt, right?
The pressure mounts, the user is locked out, and the admin just temporarily
disables the security policy.
Because they misdiagnose the problem as a broken MFA issue, when in reality the
root cause is usually something entirely disconnected from the authentication app.
So to untangle this, we have to completely dismantle the core misconception that
causes the confusion in the first place.
Right.
This deeply ingrained idea that MFA is the finish line of a login.
Yes.
Well, I like to visualize this whole architecture, uh,
kind of like airport security.
Oh, that's a great analogy.
Yeah.
So successfully showing your driver's license and your boarding pass to
that first agent at the podium, that is your multi-factor authentication.
You've proven who you are, and you've proven you hold the ticket.
But walking past that podium does not mean you get to bypass the luggage scanner.
Or the metal detector or the random explosive swab test.
Those secondary security checkpoints, those are your
conditional access requirements.
Exactly.
The fact that the ID check succeeded does not guarantee
you a seat on the actual plane.
It just gets you to the next line.
That airport visualization maps perfectly to the technical flow of Entra's
architecture, actually, because MFA is simply one isolated component of a much
larger authentication and access pipeline.
Completing it just provides evidence that one specific requirement was met.
Right.
Microsoft Entra doesn't just stop processing the moment you
approve that push notification.
It takes that MFA successful token and carries it forward into
this complex evaluation engine.
So it's running down a whole sequence of other potential requirements.
Exactly.
Checking the network location, looking at device compliance, assessing
user risk, all before it ever calculates a final access decision.
So the architecture physically separates the act of authenticating
from the act of granting access.
You have the user signing in and completing MFA in step two, and then
conditional access steps in to look at the broader contextual picture
in step three, four, and five.
Precisely.
The telemetry flow is strictly sequential.
So you have primary authentication, then MFA completion, followed by
conditional access evaluation.
Checking all those supplemental requirements.
Yeah.
And only at the very end of that gauntlet do you get an access decision.
So when a user submits a ticket saying, "My MFA worked," they are accurately
describing the success of step two.
But when the administrator looks at the dashboard and says, "Conditional access
denied the request," they're looking at the final verdict in step five.
Which means the single biggest mistake you can make in your
troubleshooting process is treating step two as if it were step five.
Which fundamentally changes the operational question we should be asking.
Because I'm methodical by nature.
Yeah.
I'm always asking, you know, what changed?
Right.
So if we abandon the premise of why did MFA fail- Yeah Since we know it
actually succeeded, we have- Exactly.
Let's say we agree MFA isn't the final decision, but what if the MFA
the user performed was successful but just, you know, wasn't muscular
enough for the specific application they are trying to access?
We have to draw a hard line between simply performing multi-factor
authentication and meeting an authentication strength requirement.
This specific nuance is a massive pitfall for support engineers because you open
the sign-in logs, you look at the basic summary tab, and you see this reassuring
message that says, "MFA completed."
And human nature dictates that you check that box in your head and assume the
authentication method was fully satisfied.
But conditional access has evolved.
It can now demand a particular authentication strength
based on the target resource.
Right.
So that could be your standard authenticator app push- Yeah
or passwordless MFA.
Or it might require the highest tier, like phishing-resistant MFA,
which would be a FIDO2 security key or Windows Hello for Business.
Let's run this through the worked example from our source material because
the mechanics here are fascinating.
Yeah, let's do it.
Imagine you are securing a highly privileged application.
Let's say it's the financial system that handles global payroll.
Okay.
High stakes.
Very.
And the conditional access policy for this specific app mandates
phishing-resistant MFA Now, a user tries to log in, and they authenticate
using a standard authenticator app push notification on their smartphone.
They hit Approve.
Right, they hit Approve.
Oh.
The Entra sign-in logs will literally record that MFA completed
successfully, but the final resulting decision is a hard access denied.
Yeah.
I have to admit, if I'm an admin looking at that dashboard, this feels like
the system is actively gaslighting me.
I know.
It really does.
So I have to ask, why are these treated as separate concepts in the logs?
Like, why doesn't the system just throw an MFA failed error if
the strength wasn't high enough?
I completely understand the frustration there, but the system
is actually doing you a massive favor by being technically precise.
As engineers, we require that precision to isolate the variable.
Okay, how so?
Well, think about the mechanical truth of what just happened.
The multi-factor authentication did occur.
The user's credentials were valid, and their secondary
device responded correctly.
So the mechanism itself is flawless.
Exactly.
If the system lazily logged MFA failed, your immediate troubleshooting
step would be completely wrong.
You'd assume the user's phone is broken or their authenticator
app lost its sync token.
Or they're typing in a wrong one-time passcode.
Right.
You would spend three hours on a screen share trying to re-register their device.
Oh, wow.
Okay, that makes total sense.
By logging MFA completed alongside a failure in the authentication
strengths requirement, the system is handing you the exact diagnosis.
Yep.
It's telling you the mechanism works perfectly, but the user
brought a knife to a gunfight.
They just chose the wrong tool for the job.
Exactly that.
The authentication was valid, but it wasn't strong enough.
But to spot this, you cannot rely on the high-level summary view.
You have to actively click into the Authentication Details tab, right?
Yes.
In the Microsoft Entra sign-in logs, if you stop at MFA completed, you will
completely miss the strength mismatch.
You have to compare the recorded authentication method that was
actually used against the policy's required authentication strength.
All right, so we've solved the authentication strength hurdle.
Let's say the user's educated, they use their physical
phishing-resistant hardware key, and the authentication side is flawless.
But they still get blocked.
Right.
This pulls us into what I like to call the multi-requirement minefield.
We need to talk about how conditional access stacks multiple requirements
together using combined grant controls.
Because real-world conditional access architecture is rarely
built on single isolated rules.
It relies on a compounding strategy of grant controls tied
together with absolute AND logic.
So a standard corporate policy doesn't just ask for one thing.
No, it usually dictates that you need MFA, AND you must be on a
compliant device, AND you must be using an approved client application.
The source material provides a great look at this with a SharePoint access scenario.
Let's say an employee is trying to access SharePoint over the weekend.
Okay.
Policy A in your environment says require MFA for all cloud apps.
Policy B says require a compliant device for SharePoint.
So they log in from their couch using their personal unmanaged iPad.
Exactly.
They execute their MFA perfectly.
Policy A evaluates the session, sees the MFA claim, and marks it as a success.
But policy B evaluates the device state, realizes this iPad is completely
unknown to your mobile device management system, and fails the requirement.
And this brings us to the cardinal rule of conditional access evaluation,
which is that one successful control does not mathematically
compensate for another unmet control.
The success in policy A does not bank any goodwill that cancels out
the failure in policy B. Because they operate on strict AD logic.
Right.
So the overall evaluation for that session is gonna collapse
into an access denied state.
As someone whose brain automatically jumps to what
changed in the environment- Mm-hmm.
This scenario is just the ultimate wildcard.
Oh, totally.
An employee will submit a ticket saying, "I used to get into SharePoint on my
iPad every day, and today I can't, so your MFA system is clearly broken." Yeah,
because they're experiencing a single access denied error on their screen.
But behind the scenes, multiple overlapping policies are battling it out.
How do we untangle that knot when everything just
looks like a generic block?
That untangling is the crucial pivot point in any investigation.
When you navigate to the conditional access tab within those sign-in logs,
you must interrogate the data with three highly specific questions.
Okay, what's the first one?
First, you ask which policies actually applied to the sign-in.
If a policy wasn't applied, maybe it only targets the finance
department, and this user is in marketing, you completely ignore it.
It didn't contribute to the decision.
Exactly.
Second, you look at the applied policies and ask which requirements succeeded.
And third… The goldmine.
Which specific requirement failed?
In your iPad scenario, the diagnosis you put in the ticket notes isn't MFA failed.
The highly accurate diagnosis is MFA succeeded, but the compliant
device requirement failed.
Nailed it.
So far, we've been operating under the assumption that the user is being
blocked the front door, like they try to launch the app, and they get
tackled by the bouncer immediately.
Right.
But what happens when the user does get in, everything seems fine, and then
they suddenly get blocked or restricted twenty minutes into their workflow?
This introduces us to the hidden tripwires of the architecture,
which are authentication context and session restrictions.
These scenarios are fascinating from an engineering perspective,
but they look entirely foreign compared to a normal sign-in failure.
And they absolutely drive end users crazy because they feel so random.
Let's break down authentication context first.
Okay.
This feature allows administrators to apply conditional access requirements,
not just to an application as a monolithic block, but to a specific, highly
sensitive action inside the application.
I love comparing this to a casino.
Oh, let's hear it.
The bouncer at the front doors of the casino checks your ID and
lets you onto the gaming floor.
That is your normal login and standard MFA.
Okay.
Makes sense.
But if you try to walk into the exclusive high roller room to drop
fifty thousand dollars on a single hand of blackjack, the pit boss at
that specific door is going to demand a secondary, much stricter verification.
That is a brilliant analogy.
The user authenticates normally, they open their corporate app, and
they start doing their daily tasks.
Everything is green.
But then they attempt to perform a highly privileged action.
Right.
Maybe they try to initiate a massive wire transfer, or they click
the button to export the entire customer database to a CSV file.
And the application is programmed to recognize that specific action as
an authentication context trigger.
The moment they click that button, the application pauses the action and forces
a step-up authentication requirement, demanding a stronger verification method.
But think about the user experience there.
To a user, a blocked sensitive action doesn't feel like a
sophisticated security checkpoint.
No, it just feels like the website crashed or their login broke.
They were gonna submit a ticket saying like, "The app kicked me
out," or, "My session died." So how does a support engineer tell the
difference between a real front door access denial and an authentication
context failure deep inside the app?
The secret is once again buried in the telemetry.
You have to look at the logs to see if an authentication context
was explicitly requested by the application during that session.
So you check if a conditional access policy targeted that specific context.
And finally, you check if the user actually satisfied that
resulting step-up requirement.
You absolutely cannot treat a sensitive action failure as a general broad
strokes authentication problem.
Because the front door is fine, it's the vault door that denied them.
Beautifully put.
And that leads us to the other side of this hidden tripwire
concept, session restrictions.
This is arguably the most confusing scenario of all
because the access is actually…
Granted, it's not denied, but the session itself is fundamentally limited.
Right.
Let's trace the flow.
The user logs in, they pass the MFA challenge.
Conditional access evaluates all the policies, everything comes
back as a success, and the final decision is access granted.
But an additional session control is applied to that grant.
This means the architecture intercepts the traffic and enforces limitations.
So the user might be able to open a highly confidential document in their
web browser and read it perfectly fine.
But they'll notice the download button is completely grayed out.
Or they are blocked from copy-pasting the text.
I've actually always wondered about the mechanics of that.
How does Entra actually reach into a third-party application
and gray out a download button without breaking the whole web page?
It's essentially acting as a highly intelligent middleman.
Instead of the user's browser talking directly to the application server,
conditional access routes the session through a reverse proxy service.
Oh, I see.
Yeah.
The application sends the web page, the proxy intercepts it, strips
out the code that enables the download function, and then delivers
the restricted page to the user.
Or in another session restriction scenario, the user might be forced
to authenticate again on a much shorter timeline than they expect.
Exactly.
Overriding the normal token lifetime.
The conceptual flow to remember here is authentication occurs,
then access is granted, then a session control is layered on top,
resulting in a restricted experience.
And the danger for the IT admin is that the user will submit a
furious ticket claiming they are being denied access to their files.
But they aren't denied.
They are experiencing a mathematically perfect policy-driven, restricted session.
If you don't check the sign-in outcome first to verify that access was actually
granted, you might go chasing ghosts in your authentication policies when the
system is actually functioning flawlessly.
Exactly.
Okay.
We've comprehensively mapped out all these distinct ways a login can silently
fail or heavily restrict a user even after their MFA succeeds perfectly.
We covered a lot of ground.
Now we need to bridge the gap between theory and practice.
How do we systematically hunt down the root cause in a
chaotic real-world environment?
The source material lays out an incredibly robust evidence-first
troubleshooting model culminating in this eighteen-check administrator checklist.
And the entire foundation of this model rests on one immovable rule.
You must never, ever start your troubleshooting by changing the
conditional access policy itself.
Never guess.
Always start with the exact specific sign-in event in the
Microsoft Entra sign-in logs.
I wanna dig into the psychology of why this rule is broken so often.
Why is it so incredibly tempting for admins to just weaken the MFA
policy when they see these errors?
Because it's the path of least resistance.
Right.
I see it happen constantly.
An executive complains they can't get into their email.
The ticket subject line says, "MFA failed." And the admin, wanting to
provide good customer service, just adds that executive to an exclusion group.
Completely bypassing the policy.
Yes.
It happens because administrators are constantly under intense
time pressure, and without taking the time to parse the logs, they
blindly trust the user's report.
The user says, "My MFA is broken," and the admin wants to be immediately helpful.
So they dial back the security perimeter.
It's a dangerous knee-jerk security downgrade, and the most tragic
part is that it often doesn't even resolve the user's issue.
Because if the root cause was actually a non-compliant device, exempting
them from MFA does absolutely nothing.
They are still blocked, and now your environment is less secure.
That is the ultimate cell phone.
You rip out the security cameras, and the door is still locked anyway
because their iPad isn't managed.
Exactly.
So let's explore the philosophy of this 18-check progression.
It's deliberately designed to prevent that exact scenario.
We aren't gonna list all 18 steps, but let's talk about why
it's structured as a funnel.
The funnel metaphor is perfect.
The checklist forces you to evaluate the transaction chronologically
exactly as the system processes it.
You are pouring all the evidence into the top of this funnel to
isolate the single failing variable.
So you start at the very top with authentication validity.
Mm. Did the primary authentication even succeed?
Was the password right?
Did the MFA mechanism actually complete its handshake?
What specific method push, SMS hardware key was recorded?
You have to establish that baseline first, because if you skip straight to looking
at conditional access policies, you might miss the fact that the user was trying to
use a legacy authentication protocol that the system doesn't even support anymore.
And once you verify the authentication was valid, you move down the
funnel to authentication strength.
Right.
You ask the data, did the policy demand a stronger method than
what the user actually provided?
If they used SMS but the policy demanded a FIDO2 key, you stop right there.
You found your failure.
But if the strength was sufficient, you drop further down the funnel into the
conditional access evaluation phase.
Which policies actively applied to this user session?
Which ones evaluated as a success?
And crucially, which specific policy failed?
From there, you dig into the grant controls within that failing policy.
Was a compliant device required?
Was an approved client app required?
Did multiple controls combine with that strict AND logic to create a roadblock?
Next, you scan for those hidden tripwires we discussed.
Was an authentication context involved?
Was the user trying to execute a sensitive action that triggered a
step-up requirement mid-session?
And finally, at the very bottom of the funnel, you check the session outcomes.
Was access truly denied at the front door, or was it technically granted but
crippled by a restricted session control?
The entire purpose of this meticulous methodology is to
find the failed requirement.
Everything you do before you find it is just gathering evidence.
And everything you do after you find it is applying a targeted remediation.
Which brings us to the final critical phase of the deep dive:
remediation and validation.
The scary part.
Yeah.
Let's say you faithfully followed the funnel.
You found the exact failing requirement.
It turns out a newly deployed conditional access policy is accidentally blocking
an entire department because it strictly requires a hybrid-joined Windows device,
and that department entirely uses Macs.
Well, classic.
You have to fix the policy.
But how do you execute that fix without causing a massive outage
for everyone else in the company?
Modifying a live production conditional access policy without testing it
is like changing the locks on an office building while hundreds of
people are still working inside.
You are absolutely gonna trap someone.
That operational risk is exactly why report-only mode and the what-if
tool must become your best friends.
They are your safety nets.
Let's explore the mechanical difference between those two tools because they
serve very different validation purposes.
I like to think of the what-if tool as a crash test simulator.
It's a hypothetical sandbox.
That's highly accurate.
The what-if tool lets you simulate a conditional access evaluation for
a highly specific scenario without generating any real-world traffic.
You manually plug in the user's name, the application they want, their
IP address, and their device state.
And the engine runs the math and shows you exactly how your
proposed fix would behave.
You can verify that your new rule works in theory before you ever
touch the production environment.
But theory isn't practice.
If what if is the simulator, then report-only mode is like
putting a ghost passenger in a real car on the actual highway.
It shadows real-world behavior.
Exactly.
Report-only mode allows you to deploy a policy into the production
environment, but it strips the policy of its enforcement teeth.
So it evaluates every single real-world sign-in against your new rule.
And it writes the would-be result to the logs, but it never actually blocks anyone.
It is a completely safe way to observe a policy's true impact across thousands
of diverse endpoints over a week or two.
Ensuring you don't accidentally lock out the CEO when you flip the switch to on.
Which perfectly reiterates the core operational lesson
of this entire deep dive.
Your remediation efforts must surgically target the specific
requirement that actually failed.
Do not try to fix an MFA policy if device compliance is the root cause.
And do not weaken your authentication strength requirements just because a
session control is graying out a download button exactly as it was designed to do.
The ultimate goal of troubleshooting conditional access is never to
blindly make the system less restrictive just to make an angry
user's error message disappear.
The goal is to make every single access decision understandable, evidence-based,
and mathematically precise.
If the telemetry proves that MFA succeeded but device compliance
failed, your job isn't to touch Entra.
Your job is to investigate why Intune isn't talking to that device.
That is the fundamental difference between true systems engineering just
guessing in the dark to close a ticket.
It requires a permanent mental shift from the simplistic statement MFA worked
to the nuanced reality of MFA worked perfectly, but this other highly specific
architectural requirement did not.
So we want to leave you with a lingering question to ponder as
you go back to your desk today.
Think about your current IT ticketing system.
How many of the so-called MFA failures currently sitting in your queue are
actually device compliance issues or authentication strength mismatches
secretly disguised as a broken login?
We highly encourage you to open your Entra sign-in logs today, pick just one of those
noisy tickets, and run it through the funnel to look at the actual evidence.
Right.
You've been listening to Support Engineering Weekly from
the Support Engineering blog.
Right.
For the full articles, references, and technical resources from today's
discussion, visit the URL blog.satan.ch.
Until next week, keep troubleshooting, keep learning, and keep engineering.
Thanks for listening to Support Engineering Weekly.