Conditional Access vs Identity: Who Actually Decides?

What if I told you that the most powerful security signal inside
Microsoft 365 might not be who’s knocking at the door, but what
the identity does after you let them in? Most admins obsess over
Conditional Access policy settings. But identity-based threat
signals don’t stop once access is granted. Want to know when and
how those signals actually talk to each other—and what that means
for your security posture?


Who’s Actually in Control? The Gatekeeper vs. The Watcher


If you've ever set up Conditional Access in Azure AD, you know
the drill: build your policy, test it, and assume you've got a
competent bouncer standing guard at the door. We tend to picture
Conditional Access as this sharp-eyed, clipboard-wielding
gatekeeper who checks credentials with the thoroughness of a
high-end nightclub security guard. You either match the guest
list—right country, right device, right risk score—or you don’t
even make it to the velvet rope. For many IT shops, this is where
most of the mental energy goes. You worry about location, require
compliant devices, make sure Multi-Factor Authentication is in
play, and basically stack every requirement you can in hopes of
keeping the bad actors out. It feels satisfying, like
triple-locking the front door of your house and heading out for
the weekend.But here’s the catch. Once Conditional Access opens
that door, most admins finally take a breath and move on. It’s
easy to forget that attacks don’t always happen at the entry
point. Threats often show up after the system gives the green
light. That focus on the front door is natural, but it exposes a
giant blind spot. The reality is, hackers aren’t always standing
outside, rattling the doorknob. Sometimes, they’re quietly
invited in—valid password, legitimate device—and the real danger
starts after the initial handshake.Let’s pause for a second and
think about what Conditional Access—and only Conditional
Access—sees. It checks the basics. Are you logging in from a
weird place? Does your device meet company standards? Have you
passed all the MFA hoops? It’s a solid checkpoint, but it’s
surprisingly forgetful. Once you’re through, it barely glances
back. It doesn’t monitor your next steps, and it doesn’t care if
you wander into the VIP section or start rifling through the
safe. That’s not in its job description. It stands at the door
and assumes everyone follows the rules once inside.That’s where
Defender for Identity rolls in, and honestly, it brings a totally
different energy. If we keep going with the nightclub analogy,
Defender for Identity is less like the person at the door and
more like the security team watching upstairs on the monitors.
The bouncer focused on who enters; Defender for Identity cares
about who’s sneaking behind the bar, who’s talking their way into
restricted areas, and who’s spiking the punch. It tracks the
behavior of identities post-login by watching Active Directory
and cloud signals for odd access patterns, lateral movement, or
even attempts to use techniques like Pass-the-Hash or credential
dumping. It’s not just about having a valid ticket—it’s about
what you do once you’re inside the building.A scenario we see all
the time goes something like this: A user passes all the
Conditional Access tests—familiar device, verified location,
proper MFA—and gets in without any hassle. Admins see the log and
feel good. But an hour later, that same user account starts
accessing SharePoint files never touched before or poking at
admin portals it shouldn’t even know exist. Conditional Access
gave its stamp of approval because, in the moment, everything
looked right. Defender for Identity, on the other hand, starts
raising its hand: “This behavior doesn’t fit—something’s up.”
Sometimes, the alerts pile up while the people monitoring the
Conditional Access logs are none the wiser.These systems don’t
always agree. Conditional Access can trust an account based on
how polished their paperwork looks, while Defender for Identity
starts sweating over weird behavior that doesn’t match the user’s
normal habits. Imagine the gatekeeper nodding someone inside, and
five minutes later, the security camera catches that same person
wandering into staff-only areas. Now you’ve got a real-time
debate—one tool saying, “all clear,” the other hinting, “no,
seriously, check this one out.”What’s tricky is that neither
piece actually has the final word at all times. Admins love a
simple “yes/no” moment, but the reality is more like a
negotiation. Sometimes Conditional Access has the decisive say
and blocks access, especially if you’re logging in from Minsk on
a jailbroken phone. Other times, it lets the user through, and
only after some mischief does Defender for Identity trigger an
alarm that demands another look—or even pulls the plug on that
session. It’s rarely one and done. Security here is dynamic, and
the system’s “final call” shifts depending on the situation. Some
days it’s the gatekeeper’s world; other days the watcher behind
the scenes quietly takes over.But here’s the pain point—and
honestly, it keeps showing up in real organizations. If
Conditional Access and Defender for Identity aren’t tuned into
each other, it’s not hard for suspicious activity to slip by. The
bouncer might let someone “standard” inside, only for the watcher
to spot a pattern hours later that should have raised a flag from
the start. Both roles are important—but if they’re not talking,
the whole layered security model starts to look a little shaky.
And that’s where the real blind spots start growing. The big
question, then: when these two tools run in silos, what are you
missing? Because as much as we want a single source of truth for
access, a lot can fall through the cracks when these two don’t
sync up.


Blind Spots: Where Separate Tools Create Real Risk


If you’ve worked in enterprise IT lately, you already know the
feeling: one browser tab open for the Azure portal with your
Conditional Access policies, another tab for Defender for
Identity, and maybe a third for emails or Teams pings about
yesterday’s alert review. Conditional Access lives one
life—almost like it’s managing guest lists and dress codes—and
Defender for Identity operates quietly, surfacing cryptic alerts
over here in its own universe. This is what a lot of admin setups
actually look like right now. You get two separate dashboards,
with two sets of notifications, and unless you go out of your way
to create custom automations, information just doesn’t naturally
travel between them. A user looks clean according to Conditional
Access, so they’re inside, no questions asked. If Defender for
Identity waves a red flag later? Well, someone has to see it at
the right time, tucked away in a different part of the security
center.Let’s say it’s 1:47am. Your on-call admin finally nods off
and a user logs in from the company laptop. It’s the same device
they’ve used all week, nothing fancy. Conditional Access is
satisfied because technically, every box ticks green: familiar
device, familiar IP, policy says “go ahead.” The problem is, that
account belongs to a project manager who never, ever works past
dinner, let alone in the middle of the night. Defender for
Identity, working in the background, actually catches this
late-night activity and notices something new—the user is poking
around folders labeled “Finance – Sensitive” and “HR Restricted.”
Suddenly, there are failed access attempts, and then—oddly—a
bunch of files are downloaded in quick succession.Now, in a fully
integrated world, that sequence of events would pop up as one
clear “this isn’t right” signal. But when you treat these tools
like they're on parallel tracks, what happens is more subtle—and
more dangerous. Maybe the admin who checks Conditional Access
logs comes in the next morning, reviews the login, and moves on.
Meanwhile, someone else, maybe from a different team, is reading
emails about the batch of Defender for Identity alerts, trying to
piece them together with other events. There’s a lag. Context
gets lost. Nobody connects the dots quickly enough.Attackers take
full advantage of this. Once they get inside with legit
credentials—maybe via phishing, maybe something darker—they move
slow. They mimic regular user patterns just enough to stay out of
Conditional Access’s line of sight. Then, using privileges the
real user shouldn’t even have, they start their lateral movement:
mapping shares, searching for credentials in files, looking for
stale administrator accounts. Because the original access point
was “approved,” and your tools aren’t automatically swapping
insights, these activities don’t trigger an instant escalation.
Skilled attackers live in that gap for days, sometimes weeks. The
best-case scenario? You catch them because someone finally
reviews both sources and pieces the story together. Worst
case—you only find out after financial data leaks or ransomware
drops.In Microsoft’s own case analysis from recent years, you’ll
see this play out over and over. They’ve tracked breaches where
Conditional Access was configured right out of the box, blocking
obvious risky sign-ins or device anomalies. But because Defender
for Identity wasn’t set to send risk signals back—or wasn’t
actively monitored—attackers spent weeks crawling through the
network, exfiltrating data or prepping lateral movement. The
incident post-mortems almost always talk about alert fatigue,
fragmented logs, and missed tea leaves that only made sense in
hindsight. It turns out, having the best tools running in
parallel doesn’t matter much if nobody integrates the story
they’re telling.Even the basics like risk scores and logs start
to lose value in these silos. One system kicks out “low risk”
based on location and device health; meanwhile, the other is
quietly logging a steady stream of suspicious access attempts or
protocol use. Unless someone cross-references these, risky
patterns fall into the cracks. Security teams get stuck in
reactive mode—always a step behind—because they’re wading through
duplicated noise instead of actionable signals. More than once,
organizations have assumed they had every angle covered, only to
discover months later that their separation let a persistent
attacker walk out with customer lists or IP.The reality is that
logging in from a safe device just isn’t enough anymore,
especially if nobody’s closing the gaps between tools. If you
leave Conditional Access and Defender for Identity running on
separate tracks, you’re basically locking your front door,
feeling good, but forgetting the side windows and the service
hatch in the basement are still open. The attacker isn’t going to
tell you which route they’re taking—and neither of your tools,
alone, has the whole picture. So, what actually changes when
Conditional Access and Defender for Identity start sharing
intelligence, and your alerts finally talk to your policies?
Because that’s where the risk curve can bend a lot faster—when
signals actually loop together and cover each other’s blind
spots.


Signals in Sync: The Feedback Loop That Makes You Smarter


Imagine if the moment someone started snooping around places they
shouldn’t, your security system automatically raised the bar on
what that person was allowed to do—right as it happened, not an
hour or a day later. That’s what organizations get when
Conditional Access and Defender for Identity start working
together, actually sharing their signals instead of living in
separate silos. Instead of asking IT to play detective with
scattered alerts and after-the-fact logs, the system itself
pushes an update to the “front door” policy every time a user or
device starts behaving strangely. Suddenly, you’re not waiting on
someone to spot an alert manually or connect the dots while
reading through dozens of email notifications—your defenses react
right away, matching every risky move with a swift
response.Setting up this kind of feedback loop means Conditional
Access doesn’t just look at risk at the exact second of login.
Now, it listens to the ongoing stream of signals pouring in from
Defender for Identity. We’re not talking about hours or days
between event and response. The connection can be nearly instant.
Defender for Identity notices something odd—let’s say a user
who’s usually all about OneNote suddenly tries downloading entire
folders from SharePoint and pokes at admin tools they’ve never
used. Instead of only an alert popping up in a dashboard, that
risk score gets sent straight to Conditional Access. The policy
tightens up immediately, prompting for more authentication or
even stopping the session in its tracks if the risk is high
enough.It’s not always a neat, one-size-fits-all rule. Sometimes
Defender for Identity is the only one in the room who can see
what’s really happening. You can have a device that looks
completely healthy to Conditional Access—clean patch level,
compliant with Intune, nothing weird on the surface. But Defender
for Identity catches a surge in Kerberos ticket requests or sees
NTLM used in odd places, something that lines up more with
lateral movement than everyday work. These aren’t the signals you
want to trust to a static checklist. They’re behavioral, based on
how identities actually interact with resources across the
network. And when Conditional Access can “hear” those alerts,
what started as a green-light session suddenly becomes far more
restricted.Take a normal Monday: a user logs in from their desk,
MFA passes, no VPN tunnels or flagged IPs. Everything is textbook
up front. But something in their behavior catches Defender for
Identity’s attention—they suddenly attempt to access dozens of
SharePoint sites they’ve never touched before, and a script
starts running against a file share. Maybe it’s nothing, maybe
it’s the early phase of an attack, but right then Conditional
Access takes that new risk score and immediately flips on
stricter controls. That could mean re-authenticating, cutting the
session, or requiring Managed Device—a wall goes up as soon as
the system senses danger. The user’s experience changes in
real-time depending on what’s actually happening under the
hood.That “under the hood” logic isn’t just about identity.
Device posture, on its own, now actually plays into both sides of
this loop. If a device is marked as compromised by Microsoft
Defender, for example, Conditional Access doesn’t just restrict
access. Those details go straight into Defender for Identity’s
view of the world as well. So as the user moves between cloud and
on-prem apps, the visibility layer is always adapting, factoring
in device trust, account behavior, and even application context.
The feedback loop isn’t just one-way—it’s more like a
conversation that keeps all eyes on the target as things
shift.It’s easy to see the benefits here when something actually
goes wrong, but there’s another angle: over time, your system
learns. Logs from Conditional Access and Defender for Identity
are unified, so investigations become less about finding the
“needle in the haystack” and more about following a timeline with
actual context. If a user really is compromised—or even just
makes a few honest mistakes—it’s far simpler to follow the
sequence: when the risk shifted, which controls kicked in, and
what clues were missed or acted on. The more events the system
sees, the sharper it gets at flagging truly abnormal behavior,
filtering out the noise and letting IT focus on real signals
instead of false alarms.It’s a much different experience from
manually stitching together logs or guessing at threat levels
from two separate dashboards. The smarter your signals, the
smarter your defenses—and the less your team needs to chase down
every “just in case” scenario every time someone’s login goes
slightly sideways. Not only does this feedback loop close
security gaps, but it calls out genuine issues before they
snowball. Still, for all the promise, it’s not magical. Quickly
adapting defenses are powerful, but you need some way to verify
you’re filtering out real risk—not just generating an endless
pile of alerts. So, how do you tell if this setup is genuinely
improving your security—or just burying you in more data? That’s
where the rubber actually meets the road for IT operations.


Measuring Success: Is Your Identity Security Actually Resilient?


If you’ve spent any time managing security in Microsoft 365, you
know it’s easy to build a fortress that looks good on paper—but
figuring out if it actually works is a different story. Plenty of
organizations layer Conditional Access and Defender for Identity,
crank up every setting they can find, then cross their fingers
and hope for the best. The problem isn’t just technical
complexity; it’s measurement overload. You spin up a pilot,
switch on a dozen alerts and policies, wait… and then the
avalanche hits. The notifications never stop. New login, new
location, possible lateral movement, potential impossible travel,
risk detected, session limited, and before you know it, you’re
drowning in all the digital noise. So who’s actually reading
these? Which ones matter? And how do you know whether your system
is catching the real attacks or just flagging every shadow on the
wall?This is where a lot of security teams quietly admit they’re
running blind. The dashboards fill up, but there’s rarely a clear
answer to the most important question: are we any safer than last
month? Or have we just trained everyone to ignore alerts unless
something blows up? The reality is, most organizations discover
gaps only after something slips through—when an investigation
uncovers suspicious activity no one saw in real time, or a user
reports their own credentials being used elsewhere. Retrospective
visibility isn’t much comfort when you’re explaining an incident.
You need real, practical ways to tell if your controls work as
intended before the breach, not after.So, what does good
measurement actually look like when Conditional Access and
Defender for Identity are integrated the way they’re supposed to
be? For starters, you don’t just count how many alerts came
through. Quality matters more than volume. Look at indicators
that show you’re moving the needle: are attackers spending less
time inside before being detected and removed? That’s “dwell
time”—a metric any SOC analyst can explain in their sleep. When
you reduce dwell time, breaches become much harder to monetize.
Then there’s response time. How long does it take from the first
sign of a suspicious login or odd file access until the user’s
session is limited, or an investigation kicks off? In a
real-world environment, shaving minutes off that timeline can
mean the difference between a harmless failed attempt and an
expensive breach.Fewer successful phishing attempts is another
sign you’re heading in the right direction—especially if
defenders are using these tools to step up requirements after a
risky sign-in, or to automatically trigger an investigation when
something unusual pops up. Stronger audit trails count, too. When
an incident actually does occur, can you follow what happened
from the first login all the way through file access, privilege
escalation, and remediation action? Granular logging isn’t just
about compliance; it’s about making investigations fast, clear,
and less stressful—all while proving to auditors and executives
that security does more than just stack up alerts.The real win
with a connected Conditional Access and Defender for Identity
setup is not just more data—it’s actionable, story-rich metrics.
Instead of a wall of unrelated signals, you start seeing “blocked
risky session”—where access was halted when behavior shifted, not
just when a blacklist matched. You see “identity threat
confirmed”—not a generic high risk, but a reasoned,
evidence-based escalation. Trends in user behavior start to
surface: you notice whether lateral movement attempts fall after
changing a policy, or if privileged account logins become more
predictable. It’s the difference between searching for a needle
in a haystack and having the haystack shrink every
month.Protocols matter here, too. Classic Active Directory
signals—think Kerberos tickets and NTLM authentication—support
much more than logon success rates. Once you’re tracking which
service tickets get requested after login, or how many NTLM
attempts show up after hours, you start building a fuller story.
Add user behavior analytics (UBA) on top, and it becomes possible
to tell whether yesterday’s 3am file transfer was a real threat
or just some forgotten batch job. And because both tools now feed
into each other, these insights aren’t just sitting in a
silo—they shape policies and trigger remediation right when the
risk peaks.Just look at Microsoft’s own public case studies.
There’s the large healthcare provider who cut their average
attacker dwell time from days to under four hours after
connecting identity threat signals to Conditional Access
enforcement. Or the global electronics giant that stopped a
credential stuffing attack mid-stream, not just because they
caught the login, but because Defender for Identity recognized
odd internal movement and automatically limited the session.
Metrics improved across the board: false positives dropped,
incident response times shrank, and audit-trail storytelling got
easier.There are a few habits that actually make a difference as
you measure progress. Start by tracking risk score trends over
time—if you’re doing it right, you should see fewer unexplained
spikes. Regularly audit your policies, not just for coverage but
also for unnecessary friction. When was the last time you
reviewed which controls kick in for which behaviors? Don’t just
wait for a real attack to test your system—run simulated attacks,
phish yourself, or use Microsoft’s own Secure Score. Watch how
quickly sessions get flagged or limited, then adjust as
needed.Ultimately, if measuring your feedback loop shows a steady
drop in time-to-detect, blocked risky sessions, and staff who are
actually responding to meaningful alerts, you’re doing it right.
If not, you’re just spinning your wheels with more dashboards.
The next challenge is deciding how far to go—and what “good
enough” actually looks like for your environment.


Conclusion


If you’re approaching identity security as a patchwork of
disconnected tools, real resilience is going to slip through your
fingers. The reality is, every alert and every policy makes more
sense—and works harder—when your signals actually talk to each
other. Take a hard look at your own environment: are Conditional
Access and Defender for Identity sharing context, or are you just
hoping no alert gets missed? If you’ve got feedback loops or
integration stories, drop them in the comments. And if you want
to keep sharpening your own strategies, hit subscribe for more
practical ways to outsmart the next threat.


Get full access to M365 Show - Microsoft 365 Digital Workplace
Daily at m365.show/subscribe