What Happens When Microsoft Defender Detects a Threat on an Intune Device?

Zero Trust architecture treats Defender as the stage that keeps watching after access is already granted, feeding back into the next decision. This post is what that feedback loop actually looks like in practice, stage by stage, from the moment something goes wrong on a real device to the moment access is legitimately restored.

Threat
 ↓
Defender
 ↓
Risk Detection
 ↓
Intune
 ↓
Compliance State
 ↓
Conditional Access
 ↓
Access Blocked
 ↓
Investigation
 ↓
Remediation
 ↓
Compliance Restored
 ↓
Access Restored

The Scenario Running Through This Post

An employee opens an email attachment that looks like an invoice. It's not. The payload attempts to read lsass.exe's memory to harvest cached credentials, the exact technique an ASR rule and Credential Guard both specifically defend against, but the story here is what happens when a device gets flagged, not whether the attempt itself succeeds.

Stage 1: Threat, the Moment Something Goes Wrong

The attachment executes and attempts its LSASS memory read. This is the raw event, on the device, before any security product has reacted to it yet.

Stage 2: Defender, Detecting It in Near Real Time

Microsoft Defender for Endpoint's behavioural sensors catch the attempt as it happens, this is exactly the kind of live-behaviour detection that a static compliance checklist structurally can't see. Defender generates an alert, correlating the specific process, the memory-access attempt, and the parent process chain that led to it, and this typically happens within seconds to minutes of the actual behaviour, not on any scheduled cycle.

Stage 3: Risk Detection, a Score Gets Calculated

The alert feeds into a machine risk score for this specific device, Low, Medium, or High, based on the severity and category of active alerts. A single credential-theft attempt is a serious signal and typically pushes the device to at least Medium, often High, risk.

Stage 4: Intune, Receiving the Signal

This only works if the Microsoft Defender for Endpoint connector is configured in Intune (Endpoint Security → Microsoft Defender for Endpoint), and if a compliance policy has the specific setting "Require the device to be at or under the machine risk score" configured with a threshold (Clear, Low, Medium, or High).

Stage 5: Compliance State, Flipping to Non-Compliant

With the integration configured, Intune's compliance engine picks up the new risk score at its next evaluation and compares it against the policy's threshold. A device now scored High risk, against a policy requiring "at or under Low," fails that specific compliance rule. The device's compliance state changes from Compliant to Non-compliant, and this result syncs to the device's object in Microsoft Entra ID, the same mechanism that carries any compliance signal into an access decision.

Stage 6: Conditional Access, Reading the Updated Signal

At the device's next sign-in, or its next token refresh, Conditional Access evaluates any policy with Require device to be marked as compliant as a grant control, and reads the now-updated Non-compliant attribute from Entra ID. The full mechanics of this specific read are covered here.

Stage 7: Access Blocked

The sign-in fails the compliance grant control. The user sees a message pointing them toward the device being out of compliance, not a generic access-denied error, and Outlook, Teams, and SharePoint access through that device stop working for that account.

Stage 8: Investigation

An analyst opens the alert in the Microsoft Defender portal, reviewing the device timeline, the specific process tree, and how the detection maps to known attack techniques. The goal here is scoping: did the LSASS access attempt actually succeed, did anything move laterally from this device, is this an isolated event or part of something larger.

Stage 9: Remediation

Depending on what the investigation found, remediation ranges from fully automated to entirely manual.

For this scenario, remediation likely includes confirming the credential-theft attempt didn't succeed (checking for any subsequent sign-ins using this user's credentials from unfamiliar locations), removing the malicious file, and resetting the affected user's password as a precaution regardless of whether the attempt was confirmed successful.

Stage 10: Compliance Restored

Once the threat is remediated, Defender's risk score for the device decreases, this isn't instant either, it reflects the absence of new alerts and the resolution of existing ones over the following evaluation cycles, not a single button that immediately zeroes the score. Once the score drops back under the compliance policy's threshold, Intune's next evaluation reports the device Compliant again, and that result syncs back to Entra ID exactly the way the Non-compliant result did in Stage 5.

Stage 11: Access Restored

The next sign-in re-evaluates Conditional Access against the now-current, Compliant status, and access is granted normally. From the user's perspective, the entire incident may have shown up as nothing more than a few hours of being unable to reach email, with the actual detection, containment, and remediation having happened entirely behind that.

The Full Loop, Timed Honestly

Has this exact chain fired for real in your environment, or did you find out during an actual incident that the connector wasn't configured? Drop a comment, that gap is more common than most tenants realise until it's tested under real conditions.