Episode Details

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 WatcherIf 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