Directory identity
Validate object ID and device ID, display name, join type, enabled state, registration date, activity timestamp, owner, operating system, profile, physical identifiers, and certificate-backed local state.
Microsoft Entra device identity evidence
Microsoft Entra Device Registration Review Guide
Turn the tenant device list into defensible identity evidence. Reconcile Microsoft Entra registered, joined, hybrid joined, pending, duplicate, stale, disabled, managed, compliant, owner, activity, certificate, and access states before trusting a device claim or deleting an object.
Review objective
Prove which device identity is real, current, governed, and safe to trust
Microsoft Entra device registration creates a directory identity that applications and Conditional Access can use as a signal. That object is not the physical endpoint, the Intune record, the Autopilot record, or proof that a device is secure. A professional review connects those records and records why each device should remain enabled, be remediated, be disabled for observation, or be deleted after dependencies are protected.
Management and posture
Correlate Intune device ID, MDM authority, last check-in, ownership, primary user, enrollment profile, compliance, Defender status, Autopilot assignment, encryption, and recovery-key custody.
Access evidence
Confirm sign-in logs present the intended device ID, trust type, managed and compliant claims; then test Conditional Access in report-only or controlled scope before changing device objects.
Boundary: Microsoft Entra registration is not the same as MDM enrollment. A registered personal device can exist without Intune management, while a compliant claim depends on supported management, policy, check-in, and token conditions. Do not infer ownership, security, or authorization from the display name alone.
Evidence reconciliation
Read every signal in its own system and time window
The Entra admin center can export the device inventory with identity, join, management, compliance, owner, platform, registration, and activity fields. Those fields are an excellent baseline, but several are approximate, delayed, empty by design, or populated by another service. Record the export time, filters, role used, timezone, and query so reviewers can reproduce the result.
| Signal and source | What it can support | What it does not prove | Required corroboration |
|---|---|---|---|
| Join type / trustType | AzureAD represents Entra joined, ServerAD hybrid joined, and Workplace Entra registered. | It does not prove current management, compliance, ownership, health, or successful device authentication. | Match device ID to local status, Intune, sign-in claims, expected deployment model, and lifecycle owner. |
| Enabled / accountEnabled | Shows whether the directory device object is permitted to authenticate. | Enabled is not the same as active, healthy, compliant, supported, or assigned. | Review activity, sign-ins, owner, endpoint inventory, exceptions, and the reason an object remains enabled. |
| Activity timestamp | ApproximateLastSignInDateTime supports lifecycle and stale-device screening. | It is not a real-time audit trail. Updates have cadence and variance; some active devices can have a blank value. | Use sign-in logs, Intune last check-in, endpoint telemetry, owner confirmation, and business lifecycle records. |
| Owner / registeredOwners | Identifies the user recorded as owner when a device was joined or registered. | It may not equal the current primary user, asset custodian, purchasing owner, or support contact. | Compare Intune primary user, HR status, CMDB/asset record, deployment ticket, shared-device design, and exception owner. |
| isManaged / MDM | Indicates a management relationship or MDM authority in the exported directory view. | It does not prove the endpoint recently checked in or received every required policy. | Open the matching Intune record and verify device ID, enrollment, last check-in, ownership, policy, apps, and actions. |
| isCompliant | Supports a device compliance signal when Intune and Entra correlation is functioning. | It is not a vulnerability scan, configuration audit, or guarantee that every control is healthy. | Verify compliance policy assignment, grace period, last evaluation, setting-level state, sign-in claim, and token timing. |
| Registration date | Shows when the directory object was created and helps identify reinstall or re-registration patterns. | It does not prove purchase date, first use, warranty, physical identity, or the last rebuild. | Compare serial/hardware hash, CMDB, Autopilot, deployment record, device certificate, and previous object IDs. |
| Audit log | Records device creation, owner changes, settings changes, disable/delete operations, and bulk exports. | Retention and licensing limits apply; the log does not replace endpoint or sign-in telemetry. | Preserve relevant events with initiator, target, correlation, timestamp, approval, and ticket reference. |
Inventory baseline
Build a review dataset that can survive challenge
Export narrowly enough to finish the review but broadly enough to find unexpected device populations. Keep raw exports read-only and produce a working copy with decision columns. For large tenants, use repeatable filters or Microsoft Graph with least-privileged access, pagination, query timestamps, and documented selection logic.
Identity keys
Directory object ID, device ID, Intune device ID, serial number, hardware hash, certificate thumbprint, and any CMDB key.
State
Join type, profile type, enabled, registered, pending, managed, compliant, ownership, enrollment profile, and shared/VDI indicators.
People
Registered owner, Intune primary user, recent sign-in users, asset custodian, business unit, support group, and exception owner.
Activity
Registration time, Entra activity timestamp, Intune last check-in, sign-in evidence, Defender last seen, and HR/asset lifecycle dates.
Platform
Operating system and version, model, manufacturer, device name, edition, encryption, secure boot, TPM, and supported lifecycle.
Dependencies
Conditional Access filters, groups, LAPS, BitLocker recovery keys, Autopilot, Windows Hello, certificates, VPN, applications, and writeback.
Decision
Keep, remediate, re-register, merge documentation, disable/observe, delete, retain by exception, owner, due date, and evidence.
Risk
Privileged user, sensitive workload, unknown owner, stale identity, duplicate object, pending hybrid join, unsupported OS, or control bypass.
Change record
Approval, ticket, before/after object IDs, export hash, operator, timestamp, rollback window, validation result, and closure.
Finding classification
Separate data-quality problems from access-control failures
| Finding | Initial status | What to verify | Disposition |
|---|---|---|---|
| Expected active device | Verify | Device ID, owner/custodian, local certificate state, Intune record, recent activity, sign-in claims, compliance, and support status. | Keep with evidence and review date; remediate any mismatch rather than silently accepting it. |
| Pending hybrid object | Investigate | Entra Connect scope, service connection point, userCertificate, connectivity to registration endpoints, scheduled task, and dsregcmd diagnostics. | Repair supported registration or retire the obsolete dependency. Pending is hybrid-only and cannot provide normal device authorization. |
| Duplicate display name | Correlate | Object and device IDs, certificate thumbprint, serial, owner, registration/activity dates, Intune, Autopilot, rebuild history, and current sign-ins. | Identify the authoritative object, document dependencies, disable the candidate, observe, then delete only after validation. |
| Stale activity | Screen | Timestamp limitations, Intune check-in, sign-ins, Defender, leave/repair/storage status, loaner/seasonal/VDI design, and owner response. | Use a tenant-approved inactivity threshold plus corroboration; do not delete solely on one approximate timestamp. |
| Unknown or former owner | Assign | HR status, asset record, shared-device model, primary user, recent users, department, sponsor, and support ownership. | Assign a current custodian, rebuild/re-enroll if custody is uncertain, or retire through the approved offboarding process. |
| Managed but not compliant | Remediate | Policy assignment, last check-in, setting-level failures, grace period, OS support, certificate, token, CA result, and exception. | Restore evaluation and control state; do not change directory join merely to mask a compliance failure. |
| Registered but unmanaged | Decide | BYOD policy, app protection, enrollment eligibility, ownership, user registration quota, resource sensitivity, and CA behavior. | Allow by explicit BYOD design, enroll/manage, restrict to protected app access, or revoke/remove registration. |
| Disabled device object | Observe | Reason, ticket, affected sign-ins, recovery material, dependent credentials, replacement object, rollback window, and owner. | Retain through the observation period; delete after business and technical validation confirms no required dependency. |
Eight-stage runbook
Review, contain, validate, and clean up without breaking users
Authorize the scope
Define tenant, platforms, business units, device populations, inactivity threshold, roles, reviewers, data handling, maintenance window, exclusions, success criteria, and rollback authority. Freeze unplanned bulk deletion during the review.
Capture immutable baselines
Export Entra devices and audit activity; capture Intune, Autopilot, Defender, CMDB, HR, and sign-in datasets. Record query/filter, UTC timestamp, source, operator, row count, and file hash. Keep the raw evidence separate from the working register.
Normalize and correlate
Join records on durable keys instead of names. Normalize case, timezone, nulls, operating-system labels, and owner identifiers. Preserve one-to-many relationships so rebuilds, re-registrations, shared endpoints, and duplicate records remain visible.
Validate high-risk populations
Prioritize privileged users, administrators, executives, regulated workloads, unknown owners, unmanaged registrations, unsupported platforms, duplicate IDs, pending hybrid objects, disabled devices, and CA exclusions. Sample normal populations to test review quality.
Prove the live endpoint
On representative Windows devices, capture local join state and device authentication. Match DeviceId and tenant to the directory object; verify certificate validity, TPM/key protection, PRT context where relevant, Intune identity, network path, and expected user experience.
Test access impact
Use sign-in logs, Conditional Access What If, report-only results, device filters, and controlled accounts. Confirm the intended trustType, deviceId, managed/compliant claims, emergency-access exclusions, unsupported clients, and negative cases before enforcement or cleanup.
Disable before deleting
Back up recovery keys and dependent data, record the current object, obtain approval, disable the candidate, observe business and sign-in impact, notify support, and keep a defined rollback window. Deletion is the final lifecycle action, not the discovery method.
Close and operationalize
Re-export affected populations, verify audit entries, reconcile counts, attach before/after IDs, close exceptions, update CMDB/runbooks, assign recurring review metrics, and monitor reappearance. Report residual risk and decisions to IT and business owners.
Endpoint validation
Use local registration evidence to prove the cloud object
For Windows troubleshooting, run the command in the affected user context when Microsoft documentation requires it and preserve only the fields needed for the ticket. Device state explains whether the endpoint is Entra joined or hybrid joined; WorkplaceJoined is shown in the user-state section for registered devices. The local DeviceId must match the cloud object under review.
dsregcmd /status
Capture
- AzureAdJoined, DomainJoined, WorkplaceJoined, tenant and DeviceId
- DeviceAuthStatus and certificate validity
- Key provider and TPM protection
- PRT status and user/tenant context when relevant
- Diagnostic error phase, client error, server message, and time
- Automatic Device Join task and required endpoint connectivity for hybrid
Protect
- Redact tokens, secrets, recovery keys, user PII, and unrelated tenant data
- Do not paste full command output into public tickets or chat
- Record object IDs carefully; display names are not unique keys
- Use change approval before leave, unregister, rejoin, wipe, retire, or delete
- Retest normal and denied access after repair
- Preserve before/after evidence and the recovery path
Safe stale and duplicate cleanup
Disable, observe, and protect dependencies before deletion
Microsoft describes the Entra activity value as a lifecycle signal with update cadence and variance, not an audit record. Define “stale” for each population and require corroboration. A 90-day office laptop, a seasonal kiosk, a loaner, a persistent VDI device, a lab machine, and a nonpersistent VDI identity do not share one lifecycle.
Before disabling
- Identify the physical endpoint and current user/custodian
- Confirm the authoritative object and replacement object, if any
- Review sign-ins, Intune, Defender, CMDB, HR, and service tickets
- Check Conditional Access filters, groups, certificates, and application dependencies
- Back up BitLocker recovery information and validate its custody
- Review Autopilot, Windows Hello, LAPS, writeback, and shared-device implications
After disabling
- Monitor help desk, sign-in failures, owner confirmation, and business workflow
- Keep the disable timestamp, operator, reason, approval, and rollback deadline
- Re-enable immediately if the action affects an authoritative live endpoint
- Delete only after the observation period and dependency checklist pass
- Verify the deletion audit event and post-change inventory
- Investigate unexpected re-registration instead of repeatedly deleting the symptom
Important service boundary: Intune device cleanup rules hide inactive records in Intune; they do not delete the Microsoft Entra device object and do not issue wipe or retire actions. Entra deletion is separate and can delete BitLocker keys stored on that directory object. Coordinate both services explicitly.
Common review failures
Prevent false trust and destructive cleanup
These patterns create misleading inventories, access outages, audit gaps, and recurring duplicate objects.
Trusting the device name
Names are reused after rebuilds and can be changed. Correlate object ID, device ID, certificate, serial/hardware identity, owner, timestamps, management record, and sign-in evidence.
Calling registration “enrollment”
Registration provides a directory identity; Intune enrollment establishes management. Document both states so unmanaged BYOD and failed enrollment do not appear controlled.
Using activity as an audit log
The approximate activity timestamp is intentionally coarse and may be blank. Use it to screen candidates, then corroborate with sign-ins, Intune, Defender, tickets, and owners.
Deleting Pending objects blindly
Pending is a hybrid-join registration failure state. Diagnose synchronization, client registration, connectivity, certificate, task, and scope before deciding whether to repair or retire.
Assuming compliant means secure
Compliance is a policy signal at a point in time. Verify assigned policies, evaluation, setting-level state, check-in, token claims, vulnerability/EDR evidence, and exceptions.
Deleting recovery material
Removing an Entra device can remove BitLocker recovery keys stored on it and affect Autopilot or credential workflows. Export and validate authorized recovery custody first.
Evidence and operations
Deliver a decision register, not a screenshot collection
The final package should let an auditor, IT manager, or support engineer reproduce what was reviewed, understand why each change was safe, identify residual exceptions, and reverse a wrong decision. Store evidence according to access, privacy, retention, and legal requirements; avoid collecting tokens, passwords, recovery keys, or user data in the general report.
Minimum closeout: scope and roles, raw export references and hashes, correlation method, finding register, approvals, exception list, before/after object IDs, disabled/deleted inventory, audit-log evidence, access validation, rollback outcomes, residual risk, owners, due dates, and the next review date.
Related ecosystem guides
Connect device inventory to architecture, management, access, and lifecycle
Entra Join vs Hybrid Join PlanningChoose the target identity architecture and migration path for device populations.
Microsoft Intune Device ManagementCoordinate enrollment, configuration, compliance, applications, updates, and support.
Conditional Access Policy ReviewValidate device claims, filters, report-only results, exclusions, and access impact.
Microsoft 365 User ProvisioningConnect identity, licenses, groups, authentication, device readiness, and first-day validation.
Microsoft 365 Administrator ToolsUse practical assessment and administration resources for tenant operations.
Microsoft 365 Managed ServicesGet help with implementation, monitoring, remediation, documentation, and ongoing operations.
Meet Ali Hassani, CISOReview 25+ years of IT, cybersecurity, compliance, Microsoft infrastructure, and operations experience.
Discuss the device identity reviewPlan a scoped review for Orange County, Los Angeles County, or Southern California operations.
Authoritative Microsoft references
- Manage device identities in the Microsoft Entra admin center
- Manage stale devices in Microsoft Entra ID
- Troubleshoot device registration with dsregcmd
- Understand and troubleshoot Pending devices
- Use device filters in Conditional Access
- Understand Microsoft Intune device cleanup rules
- Review registered owners with Microsoft Graph
- Understand Microsoft Entra registered devices
Frequently asked questions
Microsoft Entra device registration review FAQ
Is a Microsoft Entra registered device automatically managed by Intune?
No. Registration creates a device identity for organizational access; MDM enrollment is a separate relationship. A registered device can be unmanaged, managed by Intune, protected through app-protection controls, or restricted by Conditional Access. Review registration and enrollment separately.
Can we delete every device older than 90 days?
Not safely from one timestamp alone. The Entra activity timestamp is approximate, updates on a cadence, can be blank, and is not an audit log. Apply a documented threshold by population, corroborate Intune check-in, sign-ins, endpoint telemetry, asset/HR lifecycle, owner response, and dependencies, then disable and observe before deleting.
What does Pending mean in the Entra device list?
Pending applies to Microsoft Entra hybrid joined devices that were synchronized from on-premises Active Directory but have not completed client registration. They cannot provide normal device authentication or authorization, including a Primary Refresh Token or device-based Conditional Access. Diagnose the registration path before cleanup.
Why do two device objects have the same name?
Rebuilds, re-registration, failed hybrid registration, user registration, migration, naming standards, and stale records can create duplicates. A shared name does not identify the live object. Compare device/object IDs, certificate thumbprint, serial or hardware identity, owner, dates, Intune, Autopilot, and sign-in evidence.
Does deleting an Intune device cleanup record delete the Entra device?
No. Intune cleanup rules hide devices that have not checked in within the configured period; they do not wipe or retire the endpoint and do not remove the Entra device identity. Coordinate Intune cleanup and Entra lifecycle as separate operations.
What is the safest deletion sequence?
Back up the original inventory and dependent recovery material, confirm the authoritative endpoint and replacement, obtain approval, disable the candidate, observe sign-in and business impact, validate recovery and rollback, delete after the approved window, preserve the audit event, and verify the post-change inventory.
IT Perfection Microsoft 365 and endpoint support
Make device trust depend on clean, proven identity data
IT Perfection helps organizations in Irvine, Orange County, Los Angeles County, and Southern California reconcile Microsoft Entra, Intune, Conditional Access, Autopilot, endpoint, and asset evidence; remediate registration failures; stage safe cleanup; and establish repeatable device identity operations.
Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience.
This guide is for initial planning and operational guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, or legal/compliance review. Validate current licensing, roles, retention, device behavior, Microsoft documentation, and tested rollback procedures in your tenant before implementation.
