From Gatekeeper to Watcher: Bridging Pre-Auth and Post-Auth Security

By Mirko Peters · 2026-08-11

Welcome back to the podcast and our accompanying technical deep dive! If you have ever felt like your identity security strategy has a blind spot right after a user…

Welcome back to the podcast and our accompanying technical deep dive! If you have ever felt like your identity security strategy has a blind spot right after a user successfully logs in, you are definitely not alone. For years, organizations have heavily relied on pre-authentication controls to keep the bad guys out, treating the front door like the final frontier of security. But what happens once an adversary slips past that door with a valid token or a stolen set of credentials? That exact dilemma was the centerpiece of our recent episode, Conditional Access with Defender for Identity Signals. In this post, we are going to expand on those concepts and break down how you can fuse your pre-auth gatekeeper with your post-auth watcher to build truly resilient identity architecture.

The Core Idea (TL;DR)

To truly understand modern identity protection, you need to look at your tools as specialized roles working together in real-time:

• Conditional Access (CA) is your bouncer. It is exceptionally great at making pre-auth decisions based on who is trying to get in, where they are coming from, and their device posture.
• Defender for Identity (DfI) is your CCTV system combined with your floor security. It excels at monitoring post-auth behavior, lateral movement, and internal anomalies.
• Real resilience only happens when post-auth risk raises pre-auth friction automatically and dynamically—right there, in-session.

Mental Model

Let's refine the mental model of how these components interact within your ecosystem:

• Gatekeeper (CA): Evaluates who is logging in, where they are, device posture, risk-at-sign-in, and enforces immediate session controls.
• Watcher (DfI + M365 Defender): Hunts for lateral movement, abnormal resource access patterns, Kerberoasting, NTLM abuse, and unexpected privilege escalations.
• Feedback loop: The Watcher flags suspicious behavior, which in turn raises the user risk or session risk score. This forces the Gatekeeper to immediately tighten controls by stepping up MFA, blocking access entirely, or restricting the active session.

Integration Blueprint (what to enable, in order)

Getting these systems to talk to each other requires a structured rollout. Here is the blueprint you should follow:

1. Risk-aware CA (baseline)
   • Entra ID Protection: turn on User risk and Sign-in risk evaluation.
   • Create CA policies:
     • Block when User risk = High (or require a password change if your helpdesk workflows support it).
     • Require MFA when Sign-in risk ≥ Medium.
     • Require compliant device for medium-to-high sensitivity apps; use device filters for unmanaged endpoints to route them straight into restricted session controls.
2. Let the watcher talk to the gatekeeper
   • Ensure DfI is actively streaming alerts into Microsoft 365 Defender and Sentinel (if you use it for SIEM/SOAR).
   • Automate "Confirm compromised" actions on users for high-severity DfI alerts. This sets User risk = High in Entra ID Protection, causing your CA policies to react instantly.
   • Automation path: M365 Defender Incident → Logic App or Power Automate → Graph Security/Identity Protection API (/riskDetections, /riskyUsers:confirmCompromised) → optional Force sign-out.
   • Turn on Continuous Access Evaluation (CAE) on all supported apps (Exchange, SharePoint, Graph) so policy changes actually terminate live tokens.
3. Session control for containment
   • For unmanaged or risky sessions, deploy Defender for Cloud Apps (session proxy) directly from CA:
     • CA → Use Conditional Access App Control (monitor first, then block data exfiltration like downloads, copy/paste, printing, and syncing).
   • Pair this with MDE device risk → Intune compliance → CA "Require compliant device" for all sensitive applications.
4. Privileged identity guardrails
   • PIM must enforce Just-in-Time access; require MFA + compliant device + no risky user state before elevation is permitted.
   • Implement a CA policy to Block privileged roles if user risk ≥ Low (yes, even Low risk) to force immediate triage before an administrative role can be assumed.

“If This, Then That”: Map DfI Signals to CA Actions

Mapping specific detection signals from Defender for Identity to automated Conditional Access and response actions bridges the gap between passive observation and active defense:

Start by running these in audit/monitor mode for 1 to 2 weeks, then flip responses to enforce mode per alert class as your confidence grows.

Sample Policies (practical, minimal)

To put these strategies into production, here are four foundational policies you should configure:

1. Block when user risk = High
   • Assign: All users (exclude break-glass accounts), All cloud apps
   • Conditions: User risk = High
   • Grant: Block access
2. Step-up on sign-in risk
   • Assign: All users, High-value apps (Admin portals, Exchange, SharePoint, Entra admin center)
   • Conditions: Sign-in risk ≥ Medium
   • Grant: Require MFA + Require compliant device (or managed device)
3. Session contain unmanaged
   • Assign: All users, SharePoint/OneDrive/Teams
   • Device state: Hybrid/Compliant = bypass; Unmanaged = enforce
   • Session: Use Conditional Access App Control (Block downloads)
4. Privileged elevation guard
   • Assign: Directory roles = Privileged administrative roles
   • Conditions: User risk ≥ Low OR Sign-in risk ≥ Medium
   • Grant: Require MFA + Require compliant device; Block if risk ≥ High

Automation Playbooks (ready-to-wire)

Automation is the secret sauce that reduces your Mean Time to Contain (MTTC). Here are two playbooks you can build today:

Playbook A: DfI high-severity alert → Contain identity

• Trigger: M365 Defender incident tagged with IdentityThreatHigh
• Actions:
  1. Graph API – confirm user compromised (sets User risk to High)
  2. Entra ID – revoke refresh tokens immediately
  3. Intune/MDE – device isolate (if a single primary device is associated)
  4. ServiceNow/JSM – create an incident ticket with the timeline and collected artifacts
  5. Notify the SOC and user owner via a Teams adaptive card with a one-click rollback button in case of false positives

Playbook B: Anomalous SharePoint access burst

• Trigger: Defender alert “Unusual file download”
• Actions:
  1. Tag user with UnderInvestigation via AAD extension attributes
  2. Transition user to a CA policy that routes them to App Control (blocking downloads and printing)
  3. Launch an eDiscovery hold on affected SharePoint sites (optional, depending on compliance needs)
  4. Auto-expire containment in 72 hours unless the SOC manually extends it

Hunting & Useful Queries

Proactive hunting helps you catch gaps before attackers exploit them. Use these queries in M365 Defender Advanced Hunting:

Spike in SharePoint site access by a user compared to their 30-day baseline:

let lookback=30d;
let recent=1h;
let baseline = CloudAppEvents
    | where Timestamp between (ago(lookback) .. ago(recent))
    | where Application == "SharePoint" and ActionType == "FileAccessed"
    | summarize uniqSites=dcount(SiteUrl) by AccountUpn;
CloudAppEvents
| where Timestamp >= ago(recent)
| where Application == "SharePoint" and ActionType in ("FileDownloaded","FileAccessed")
| summarize curSites=dcount(SiteUrl), dls=sumif(1, ActionType=="FileDownloaded") by AccountUpn
| join kind=leftouter baseline on AccountUpn
| where curSites > 3 * coalesce(uniqSites,1) or dls > 500

Sign-in risk spikes tied closely to later DfI alerts:

let riskySignIns = IdentityLogonEvents
| where RiskLevelDuringSignIn in ("medium","high")
| project AccountUpn, Timestamp, RiskLevelDuringSignIn;
let dfiAlerts = IdentityDirectoryEvents
| where EventType startswith "DefenderForIdentity"
| project AccountUpn, DfiTime=Timestamp, AlertType=EventType;
riskySignIns
| join kind=inner dfiAlerts on AccountUpn
| where DfiTime between (Timestamp .. Timestamp + 4h)

Metrics That Prove It Works

When reporting back to leadership, you need metrics that show tangible risk reduction. Track these key performance indicators:

• Mean Time To Contain (MTTC) for identity incidents (time from alert generation to CA enforcement) ↓
• Attacker dwell time (time from initial suspicious action to full remediation) ↓
• Blocked risky sessions (policy-fired events) ↑ while the false-positive rate ↓
• Risky users backlog age (open cases older than 24 hours) ↓
• Token revocation latency (measured in seconds) ↓
• Privileged elevation failures due to risk (caught early before damage occurs) ↑ then normalizing over time
• Secure Score across Identity, Devices, and Apps ↑ with no corresponding spike in helpdesk tickets

30/60/90 Rollout Strategy

Avoid trying to change everything overnight. Use this phased timeline:

Days 0–30 (Foundations)

• Enable Entra User and Sign-in risk settings and deploy CA baseline policies in audit mode, then move to enforce.
• Onboard Defender for Identity into M365 Defender; validate alerts and core entity mappings.
• Turn on Continuous Access Evaluation (CAE) for supported apps and integrate MDE device risk with Intune compliance.

Days 31–60 (Feedback & Containment)

• Build Playbooks A and B in Logic Apps; test them extensively in a dry-run state.
• Pilot App Control for unmanaged sessions with 2 to 3 collaborative business teams.
• Implement the PIM elevation guardrail policy.

Days 61–90 (Enforce & Measure)

• Flip your automated playbooks to full enforce mode for high-confidence alerts.
• Stand up an identity security workbook (in Sentinel or Power BI) tracking the metrics listed above.
• Conduct a quarterly purple-team drill to validate your MTTC, token revocation speed, and CA policy flips in a live-fire scenario.

Common Pitfalls (and Safer Defaults)

Watch out for these common missteps during your implementation:

• Pitfall: Relying solely on CA's sign-in risk → Fix: Also react to user risk and post-auth DfI alerts.
• Pitfall: Having no CAE configured, allowing stale tokens to keep compromised sessions alive → Fix: Enable CAE and bake token revocation directly into your automated playbooks.
• Pitfall: Blocking file downloads broadly across the enterprise, causing a user revolt → Fix: Apply App Control selectively only when sessions are unmanaged or risky.
• Pitfall: Alert storms and false positives caused by aggressive auto-compromise workflows → Fix: Gate your automations behind multi-signal verification (e.g., DfI high alert + unusual download volume + off-hours access).
• Pitfall: Break-glass accounts accidentally locked out by automated risk policies → Fix: Exclude two heavily monitored break-glass accounts and rotate their credentials quarterly.

Copy/Paste Artifacts

To help you communicate these changes across your organization, use these ready-made snippets:

CAB one-liner for executives:

We’ve successfully connected post-login user behavior to our access control decisions. If an account starts acting unusually, we add security friction or block access in-session. That drastically shrinks attacker dwell time without slowing down normal day-to-day work.

Change note for administrators:

• New Conditional Access policies may prompt step-up MFA or block access when anomalous risk is detected. Active authentication tokens can now be revoked mid-session based on telemetry. Break-glass accounts remain explicitly excluded. Please monitor the Identity Resilience workbook for impact analysis.

Owner-friendly Teams notification card (automated):

• “We noticed unusual file activity originating from your account. We have applied temporary protections (such as disabling downloads on unmanaged devices). If this was you, simply click Acknowledge; if not, please click Report immediately.”