First-Time Login From Unmanaged Device

Purpose: Detection spec and response procedure for when a user authenticates to Entra from a device that is not enrolled in Intune (unmanaged).

Audience: Rory Detection source: Entra ID SignInLogs → identity agent in bedrock-hub

---

Why This Matters

All workforce devices that access ePHI systems must be enrolled in Intune and subject to Cortex XDR, BitLocker, and Conditional Access device compliance policies. A login from an unmanaged device indicates:

• A user accessing from a personal or unknown device (policy violation)
• A compromised credential being used from an attacker-controlled machine
• A new device that has not yet been enrolled (benign but needs remediation)

Unmanaged device logins are especially dangerous for privileged accounts — an unmanaged device has no EDR, no disk encryption enforcement, and may be already compromised.

---

What "Unmanaged" Means

A device is unmanaged if it is not one of:

• Entra-joined — Windows device fully joined to the Entra tenant (TrustType == "AzureAD")
• Hybrid-joined — Windows device joined to both on-premises AD and Entra (TrustType == "ServerAD")
• Entra-registered — typically macOS/iOS/Android with Intune enrollment (TrustType == "Workplace")

A device that passes Conditional Access device compliance check is effectively managed. The KQL below flags devices where Conditional Access did not evaluate a compliant device claim.

---

Detection KQL

Add this to runbooks/kql-query-reference.md and implement in the identity agent (agents/entra/identity_agent.py):

// First-time login from unmanaged device — last 4 hours
// "Unmanaged" = device is not compliant per Conditional Access, or device trust type is empty
let managed_devices = SignInLogs
    | where TimeGenerated > ago(30d)
    | where DeviceDetail.trustType in ("AzureAD", "ServerAD", "Workplace")
    | where ConditionalAccessStatus == "success"
    | distinct UserPrincipalName, tostring(DeviceDetail.deviceId);
SignInLogs
| where TimeGenerated > ago(4h)
| where ResultType == 0   // successful sign-in
| where DeviceDetail.trustType == "" or DeviceDetail.isCompliant == false
    or DeviceDetail.deviceId == ""
| extend DeviceId = tostring(DeviceDetail.deviceId)
| extend TrustType = tostring(DeviceDetail.trustType)
| extend IsCompliant = tostring(DeviceDetail.isCompliant)
| extend OS = tostring(DeviceDetail.operatingSystem)
| join kind=leftanti managed_devices
    on UserPrincipalName, $left.DeviceId == $right.DeviceDetail_deviceId
| project TimeGenerated, UserPrincipalName, IPAddress, Location,
    AppDisplayName, DeviceId, TrustType, IsCompliant, OS,
    ConditionalAccessStatus, RiskLevelDuringSignIn
| order by TimeGenerated desc

Simplified version (checks only for empty trust type — lower false positive rate, use first):

SignInLogs
| where TimeGenerated > ago(4h)
| where ResultType == 0
| where DeviceDetail.trustType == "" or isnull(DeviceDetail.trustType)
| where UserPrincipalName !endswith "#EXT#"   // exclude guest accounts
| project TimeGenerated, UserPrincipalName, IPAddress, Location,
    AppDisplayName, tostring(DeviceDetail.operatingSystem),
    RiskLevelDuringSignIn, ConditionalAccessStatus
| order by TimeGenerated desc

---

Severity

Condition	Severity
Standard user, unmanaged device, first time	MEDIUM
Privileged account (Global Admin, Security Admin, any PIM-eligible role), unmanaged device	HIGH
Break-glass account, any device state	CRITICAL (always)
High risk sign-in + unmanaged device (RiskLevelDuringSignIn == "high")	HIGH
External IP + unmanaged device + new location	HIGH

---

ioc_key Format

PROD:account:{UserPrincipalName}:unmanaged_device_login

---

Response Triage

1. Open SecOps finding — note account, IP address, location, device OS, app accessed
2. Check whether this is a new device enrollment in progress:
   • Entra Portal → Devices → All devices → search by account owner — is there a recent device registration in the last 48 hours?
   • If yes and it's a legitimate new device: allow enrollment to complete, then close finding with note
3. Check whether the user was aware of the sign-in:
   • Contact the user directly (Teams/email/Slack) — "Did you just sign in from a new device or new location?"
   • If the user says no: treat as compromised credential (see below)
4. Check the sign-in IP against threat intel:

   SignInLogs
   | where TimeGenerated > ago(7d)
   | where IPAddress == "<ip>"
   | summarize Accounts = make_set(UserPrincipalName), Count = count()

   If the same IP is hitting multiple accounts: spray pattern — escalate to runbooks/kill-chain-credential-dumping-response.md

---

Response — Unrecognized Device / User Denies the Login

Treat as a compromised credential:

1. Disable the account in Entra immediately: Entra → Users → [user] → Edit → Account status: Blocked
2. Revoke all active sessions: Entra → Users → [user] → Revoke sessions
3. Force MFA re-registration: Entra → Users → [user] → Authentication methods → Delete all methods
4. Check what apps and data the unmanaged login accessed:

   SignInLogs
   | where TimeGenerated > ago(4h)
   | where UserPrincipalName == "<account>"
   | where DeviceDetail.trustType == ""
   | project TimeGenerated, AppDisplayName, IPAddress, ConditionalAccessStatus

5. If ePHI apps were accessed (SharePoint with PHI, SecOps platform, DDE environment): initiate breach risk assessment per compliance/hipaa-breach-notification-procedure.md
6. Escalate to Rory

---

Response — Known Device, Not Yet Enrolled

The user recognizes the login but the device isn't enrolled yet (common for new laptops being set up):

1. Verify the device is a legitimate company device (check purchase records or user confirmation)
2. Walk the user through Intune enrollment before re-enabling full access
3. As a temporary measure: Conditional Access can be scoped to allow unmanaged access to non-sensitive apps only
4. Close the finding with a note: "Device enrollment in progress — user confirmed, expected completion by [date]"

---

Conditional Access Enforcement

Ideally, Conditional Access should block unmanaged device logins to sensitive apps rather than just alerting. If that policy is not yet in place:

• Review runbooks/conditional-access-reference.md for adding a device compliance requirement to the CA policy covering ePHI-adjacent apps (Azure Portal, SharePoint, SecOps platform)
• This converts unmanaged device logins from a detective control to a preventive control

---

Related Documents

• runbooks/conditional-access-reference.md — CA policies and device compliance
• runbooks/mfa-operations.md — MFA reset procedures
• runbooks/entra-identity-operations.md — account disable and session revocation
• runbooks/kill-chain-credential-dumping-response.md — if the login looks like a spray or compromised credential
• compliance/hipaa-breach-notification-procedure.md — if ePHI was accessed