Identify Non-Compliant or Unenrolled Devices Accessing Corporate Data

Conditional Access and Intune compliance policies are only effective if every device touching corporate data is actually enrolled and evaluated. In practice, gaps open up quickly: personal phones that slipped past enrollment, contractor laptops, legacy devices that fell out of compliance, or sign-ins where Azure AD could not capture a device ID at all.

This recipe correlates two data sources — the Intune managedDevices inventory and the Entra ID signIns audit log — to produce a single report of every user/device pair that accessed corporate data in the last 7 days while being either non-compliant or not enrolled. SharePoint Online and OneDrive access is flagged separately because those workloads typically host the most sensitive data.

When to run it:

• Weekly or monthly as part of a device hygiene review
• Before tightening a Conditional Access policy to require compliant devices (to understand blast radius)
• After a compliance baseline change, to find devices that fell out of compliance
• During incident response when unmanaged access is suspected

After running this recipe you will have:

• A CSV report of every non-compliant or unenrolled device that accessed corporate data in the last 7 days, grouped by user and device
• A count of sign-ins per device and the specific resources accessed (SharePoint, Exchange, Teams, etc.)
• A separate flag column highlighting devices that accessed SharePoint Online or OneDrive
• A list of currently enrolled-but-non-compliant devices from Intune for remediation
• Enough evidence to justify (or scope) a Conditional Access policy requiring device compliance

Data volume and API throttling

The signIns endpoint can return tens of thousands of records per week in a mid-sized tenant. Always paginate with @odata.nextLink and cap your result set (e.g. 10,000 rows) to avoid throttling (HTTP 429). Add a $top=500 to reduce round trips.

Device ID correlation is imperfect

Not every sign-in has a deviceDetail.deviceId. Sign-ins from browsers in private mode, legacy auth, or some mobile apps will have a blank device ID. Treat these as Unknown (No Device ID) rather than assuming they are safe.

Do not enumerate SharePoint sites by display name

The Graph /sites endpoint does not support tenant-wide enumeration via $filter=contains(displayName,...). Use the resource names that appear in the sign-in log (Office 365 SharePoint Online, OneDrive) as your sensitivity signal instead, or cross-reference against a curated list of sensitive site IDs you maintain separately.

Licensing

Reading sign-in logs via Graph requires Entra ID P1 or P2. Without it, the /auditLogs/signIns endpoint returns 403.

Privacy and retention

Sign-in logs contain IP addresses, locations, and user identities. Handle the output CSV as confidential and follow your data retention policy before archiving.

Do not act on the report without review

Some "unmanaged" sign-ins are legitimate — service accounts, break-glass accounts, or approved BYOD covered by App Protection Policies rather than MDM. Review before blocking.