Registered Isn't Compliant: The Conditional Access Gap Attackers Use After Token Theft

After a successful Adversary-in-the-Middle attack, the attacker has your user's session token — including the MFA claim attached to it. Session revocation is the obvious response. The less-obvious problem is what the attacker does between stealing the token and you revoking the session.

In modern AiTM tradecraft, one of the first moves is to register the attacker's own device against your tenant, as the compromised user. The stolen token satisfies MFA requirements on the registration endpoint. The device arrives in Entra ID as an "AzureAd"-trust-typed, user-registered device. And if your Conditional Access policy requires a registered device rather than a compliant one — which a surprising number of policies do — the attacker's device now satisfies the condition. They authenticate from their own machine, with a valid token, from a device your tenant trusts enough to let past the CA wall.

Registered and compliant are not the same control

The vocabulary matters here because the CA policy picker puts the two options next to each other. "Require device to be marked as compliant" is the strong control. It requires an active Intune compliance attestation — an MDM-managed device that has recently checked in, passed compliance policies, and been marked compliant by Intune. "Require registered device" (typically expressed as a filter on device.trustType -ne "None") is weaker. It accepts any device the user has registered against their Entra tenant. Registration is a lightweight operation. Compliance requires Intune enrollment, a compliance policy, and a check-in.

The attacker cannot produce a compliant device. They would need Intune enrollment, a real device passing your compliance policy, and network visibility from Intune back to the device. They can produce a registered device. Registration only requires the user's session — which the AiTM gave them.

An attacker-registered device shows up in Entra ID audit logs as a Register device event. The initiating user is your compromised user. The initiating IP is the attacker's. The device name typically does not match your organization's naming convention. And the device's compliance state, queried from Entra, is null — because it is not Intune-managed.

The KQL query that surfaces the pivot

In an AiTM investigation, the device registration query runs in parallel with the other credential-theft checks. It is one of the small number of queries that directly evidences attacker-controlled persistence.

// Device registration events during the attack window
AuditLogs
| where TimeGenerated between (datetime(2026-05-01 07:00) .. datetime(2026-05-01 20:00))
| where OperationName in (
    "Add registered owner to device",
    "Add registered users to device",
    "Register device",
    "Add device"
  )
| extend TargetUPN = tostring(TargetResources[0].userPrincipalName)
| where TargetUPN has "the-compromised-user" or
        tostring(InitiatedBy.user.userPrincipalName) has "the-compromised-user"
| project TimeGenerated, OperationName,
          InitiatedByUser = tostring(InitiatedBy.user.userPrincipalName),
          InitiatedByIP = tostring(InitiatedBy.user.ipAddress),
          TargetDevice = tostring(TargetResources[0].displayName),
          TargetDeviceId = tostring(TargetResources[0].id),
          DeviceOS = tostring(TargetResources[0].modifiedProperties[0].newValue)
| order by TimeGenerated asc

The output names the attacker's device, shows the registration timestamp, and confirms the initiating IP. The follow-up query takes the device ID from the output and hunts for subsequent sign-ins from it:

// Post-registration authentications using the attacker's device
SigninLogs
| where TimeGenerated between (datetime(2026-05-01 10:47) .. datetime(2026-05-02 23:59))
| where UserPrincipalName == "the-compromised-user@yourdomain.com"
| extend DeviceId = tostring(DeviceDetail.deviceId)
| extend DeviceName = tostring(DeviceDetail.displayName)
| extend IsCompliant = tostring(DeviceDetail.isCompliant)
| extend TrustType = tostring(DeviceDetail.trustType)
| where DeviceId == "the-suspect-device-id"
| project TimeGenerated, AppDisplayName, IPAddress, Location,
          DeviceName, IsCompliant, TrustType, ResultType
| order by TimeGenerated asc

The two fields that expose the attack: TrustType will be "AzureAd" (registered, not Intune-managed), and IsCompliant will be null or "false". If your CA policy required compliance, those sign-ins would have been blocked. They were not.

Why "registered or compliant" is a common misconfiguration

A CA policy built from Microsoft's templated "Require compliant, hybrid-joined device, OR MFA" option provides layered coverage for managed-device scenarios and a fallback for everyone else. The trade-off that makes the bypass possible is the OR. Under the OR, an attacker who has already produced an MFA-satisfying token simply does not need the device-compliance path at all. Token replay satisfies the MFA leg of the OR. The compliance leg is optional in that evaluation.

A similar gap opens when a policy requires "registered device" on the theory that any device-level attestation is better than none. The attacker's registered device satisfies the condition exactly as the real user's would. The control is present but produces no protection.

The effective control, when the threat model includes AiTM, is Require device to be marked as compliant with no OR. For unmanaged-device scenarios where that is too strict, the compensating control is phishing-resistant MFA (FIDO2 or Windows Hello for Business) — which an AiTM proxy cannot intercept because the authentication bind includes the origin domain in the credential exchange. The combination protects against both the token-theft-and-replay path and the registered-device bypass path.

Preventive detection: the broader hunt

If one user experienced an attacker-registered device pivot, run the broader hunt against all users. The query filters for device registrations where the device name does not match your naming convention and the initiating IP is outside your normal range:

// Hunt for anomalous device registrations across all users
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName in ("Add registered owner to device", "Add device", "Register device")
| extend TargetDevice = tostring(TargetResources[0].displayName)
| extend InitiatedByIP = tostring(InitiatedBy.user.ipAddress)
| extend InitiatedByUser = tostring(InitiatedBy.user.userPrincipalName)
| where TargetDevice !startswith "WS-"         // Your naming convention prefixes
       and TargetDevice !startswith "LAPTOP-"
       and TargetDevice !startswith "SRV-"
| where not(ipv4_is_in_range(InitiatedByIP, "your-corporate-range/24"))
| join kind=leftouter (
    SigninLogs
    | project SignInTime = TimeGenerated, UserPrincipalName, RiskLevelDuringSignIn
  ) on $left.InitiatedByUser == $right.UserPrincipalName
| where abs(datetime_diff('minute', TimeGenerated, SignInTime)) < 5
| project TimeGenerated, InitiatedByUser, InitiatedByIP, TargetDevice, RiskLevelDuringSignIn
| distinct *
| order by TimeGenerated desc

The signal to watch for: registrations that correlate in time with medium-or-high-risk sign-ins from unusual IPs. A genuine user registering a new laptop from a hotel WiFi produces a low-risk sign-in because the user has established sign-in history. An attacker registering a device through a stolen session produces a higher-risk signal at the time of the initial token acquisition — not necessarily at the registration itself. The join on sign-in risk within the five-minute window is what makes the hunt reliable.

What to do this week

• Audit your CA policies for the "registered device" wording. Any policy that says "Require registered device" or uses device.trustType -ne 'None' in a filter accepts attacker-registered devices. If compliance is the real intent, change the grant to Require device to be marked as compliant.
• Check for "OR MFA" constructions. Policies that allow compliant device OR MFA fall back to MFA, which an AiTM-replayed token satisfies. Tighten to AND where the application justifies it.
• Run the broader hunt query against the past 30 days of AuditLogs. Any attacker-registered device persistence from a historical AiTM incident still has access to your tenant today.
• Add the IF-CAP-006-style finding template to your AiTM investigation playbook. The template names the registered device, the registration timestamp, the initiating IP, the subsequent sign-ins, and the CA policy that failed to block them. It is the evidence chain your CISO needs to approve the CA policy change.
• Consider FIDO2 for roles exposed to AiTM risk. Finance, executive assistants, and any role that authorizes wire transfers. Phishing-resistant MFA is the only MFA method an AiTM proxy cannot transparently replay.

Next week

A walkthrough of a single AiTM investigation from alert to containment, showing how the device-registration pivot integrates into the broader identity-compromise investigation — the Entra ID audit log queries, the Exchange mailbox review, the service-principal persistence check, and the session revocation sequence. If this post surfaced a policy gap you want to close end-to-end, next week's post is the operational companion.