Microsoft Entra ID keeps deleted devices in a separate deleted-items area for a limited period. This allows administrators to recover a device that was removed accidentally or deleted during an administrative operation.
For a .NET application, the useful part is that Microsoft Graph provides APIs for working with deleted device objects. This means a recovery workflow can be built into an internal administration tool instead of requiring an administrator to manually search through the Microsoft Entra admin center every time a device needs to be restored.
The important distinction is between an active device and a deleted device.
When a device is deleted from the active directory, it is no longer returned by the normal devices collection. It becomes available through the deleted devices API until the retention period expires. Microsoft documents the Graph endpoint for listing deleted devices and restoring a deleted device.
This article explains how to find deleted devices, identify the correct device, restore it with Microsoft Graph, and build the operation into a .NET application safely.
What Happens When a Microsoft Entra Device Is Deleted
A device object represents a registered or joined device in Microsoft Entra ID.
For example, an organization might have devices such as:
BAIBHAV-LAPTOP
SALES-LAPTOP-014
DESKTOP-ACCOUNTING
SURFACE-EXEC-02
When one of these devices is deleted, it does not immediately become permanently unrecoverable.
Microsoft Entra ID places deleted device objects into the deleted-items collection. The object can then be queried through Microsoft Graph.
Conceptually, the lifecycle looks like this:
Active device
|
| Delete
v
Deleted device
|
| Restore
v
Active device
Or, if the retention period expires:
Deleted device
|
| Retention period expires
v
Permanently removed
The recovery window is therefore important. A recovery application should not assume that every deleted device will remain available indefinitely.
Why Automate Device Recovery
For a small organization, an administrator may manually restore a device.
For a larger environment, device recovery can become part of an operational workflow.
A service could:
Search recently deleted devices
Display device names and identifiers
Allow an authorized administrator to select a device
Restore the device
Record who performed the operation
Record when the operation occurred
Verify that the device returned to the active collection
This is especially useful when an organization manages many Windows devices and accidental deletion needs to be corrected quickly.
A simple architecture looks like this:
Administrator
|
v
.NET Administration Tool
|
v
Microsoft Graph
|
+-- List deleted devices
|
+-- Identify device
|
+-- Restore device
|
v
Microsoft Entra ID
The application should not automatically restore every deleted device. Device recovery is an administrative operation, so authorization and auditability matter.
Microsoft Graph Deleted Device API
Microsoft Graph exposes deleted directory objects through the directory deleted-items API.
For devices, the relevant resource is:
GET /directory/deletedItems/microsoft.graph.device
This returns deleted device objects that are still available for recovery. Microsoft documents the deleted device resource and its supported operations through the Graph API.
A specific deleted device can then be addressed using its object ID.
The recovery operation is:
POST /directory/deletedItems/{id}/restore
The important detail is that the ID refers to the deleted device object.
Do not use the device's display name as the recovery identifier.
Names are not guaranteed to be unique.
Device ID vs Object ID
This distinction causes many recovery mistakes.
A device can expose multiple identifiers.
For example:
Display name
BAIBHAV-LAPTOP
Object ID
8f3c....
Device ID
4c21....
The object ID identifies the Microsoft Entra directory object.
The device ID identifies the device registration itself.
When using the deleted-items Graph endpoint, your application should preserve and use the directory object ID returned by Microsoft Graph.
Do not assume that the device ID and object ID are interchangeable.
A recovery workflow should therefore display enough information for an administrator to verify the target:
Display name
Device ID
Object ID
Operating system
Trust type
Approximate deletion context
The object ID should be treated as the recovery key.
Required Permissions
Restoring a deleted device is a privileged directory operation.
Your application needs the appropriate Microsoft Graph permission for the operation, and an administrator may need to provide consent.
Microsoft's Graph documentation lists the supported permissions for deleted device operations and restore operations.
Do not solve permission errors by immediately requesting broad directory write access.
Instead:
Identify the exact API operation.
Check its required permission.
Add the least-privileged permission appropriate to the application.
Obtain administrator consent where required.
Test the operation in a controlled tenant.
The application identity should have only the directory permissions required for its actual job.
Create the .NET Project
A simple console application is enough to demonstrate the recovery workflow.
dotnet new console -n EntraDeviceRecovery
cd EntraDeviceRecovery
Install the Graph SDK and Azure Identity:
dotnet add package Microsoft.Graph
dotnet add package Azure.Identity
The Microsoft Graph SDK handles API requests, serialization, pagination support, and authentication integration.
Azure.Identity provides the authentication credential used by the Graph client.
Authenticate the Application
For an administrator-operated application, delegated authentication is often appropriate.
A simplified setup looks like this:
using Azure.Identity;
using Microsoft.Graph;
var scopes = new[]
{
"Device.ReadWrite.All"
};
var credential = new InteractiveBrowserCredential(
new InteractiveBrowserCredentialOptions
{
TenantId = "YOUR_TENANT_ID",
ClientId = "YOUR_CLIENT_ID"
});
var graphClient = new GraphServiceClient(
credential,
scopes);
The exact permissions and authentication model should be selected according to how the application will be deployed.
For example:
Interactive admin tool
|
v
Delegated permissions
|
v
Signed-in administrator
versus:
Background service
|
v
Application permissions
|
v
Application identity
A scheduled recovery service should not automatically receive the same permissions as an administrator-facing tool.
List Deleted Devices
Once authentication is configured, query the deleted devices collection.
A direct Graph request is:
GET /directory/deletedItems/microsoft.graph.device
In C#, the Graph SDK provides access to directory deleted items.
A request can be structured like this:
var deletedDevices =
await graphClient.Directory
.DeletedItems
.GraphDevice
.GetAsync(config =>
{
config.QueryParameters.Select =
new[]
{
"id",
"displayName",
"deviceId",
"operatingSystem",
"operatingSystemVersion",
"trustType"
};
});
The exact SDK property names can vary between Microsoft Graph SDK generations, so keep the SDK package version aligned with the documentation used by your project.
The important concept is to retrieve the deleted device object and retain its directory object ID.
Display Deleted Devices for Review
A recovery tool should not immediately restore whatever object appears first.
Instead, display a review list.
For example:
if (deletedDevices?.Value != null)
{
foreach (var device in deletedDevices.Value)
{
Console.WriteLine(
$"{device.DisplayName} | " +
$"{device.DeviceId} | " +
$"{device.Id}");
}
}
A more useful administrative interface would show:
Name: BAIBHAV-LAPTOP
Object ID: 8f3c...
Device ID: 4c21...
OS: Windows
OS Version: 11.x
Trust Type: AzureAD
The administrator can then verify the device before recovery.
This confirmation step is important because restoring the wrong device can create additional administrative confusion.
Find One Specific Deleted Device
For a recovery workflow, you will often want to find one device.
Do not search only by display name.
Names can be duplicated or changed over time.
A safer approach is:
Administrator input
|
v
Display name / device identifier
|
v
Search deleted devices
|
v
Show matching candidates
|
v
Administrator confirms object ID
|
v
Restore
If several devices have similar names, show all matching candidates instead of automatically selecting one.
For example:
Found 3 deleted devices:
1. SALES-LAPTOP-014
Object ID: A1...
2. SALES-LAPTOP-014
Object ID: B2...
3. SALES-LAPTOP-014
Object ID: C3...
This avoids restoring the wrong directory object.
Restore the Deleted Device
Once the correct object ID has been confirmed, call the restore action.
The Graph API operation is:
POST /directory/deletedItems/{id}/restore
In the Graph SDK, the operation follows the deleted device object's restore action.
Conceptually:
await graphClient.Directory
.DeletedItems[deviceObjectId]
.Restore
.PostAsync();
The exact generated SDK path can differ depending on the Graph SDK version, so verify the generated client API against the package version installed in your project.
The important part is that the restore request targets the deleted directory object's ID.
Verify the Restore
Do not treat a successful HTTP response as the end of the workflow.
After restoration, verify that the device is visible in the active device collection.
Conceptually:
GET /devices/{id}
If the object has returned to the active collection, the recovery workflow has completed successfully.
A production workflow should therefore be:
Find deleted device
|
v
Confirm object ID
|
v
Restore
|
v
Query active device
|
v
Verify
|
v
Audit result
This is more reliable than displaying “Restore successful” immediately after the POST request.
Handle the Deleted Device Retention Window
A deleted device is recoverable only while it remains in the deleted-items collection.
Your application should therefore distinguish between:
Device found in deleted items
and:
Device no longer exists in deleted items
If the device is missing, possible explanations include:
The wrong object ID was supplied.
The device was already restored.
The deleted device is no longer retained.
The device was permanently deleted.
The application does not have permission to retrieve it.
The query did not retrieve the expected page of results.
Do not tell the administrator that a device is permanently gone simply because the first query did not return it.
Investigate the reason first.
Handle Pagination
A tenant can contain many deleted objects.
Do not assume that one response contains every deleted device.
The API may return a next-link when additional results exist.
Your application should follow pagination when the operation is intended to search the entire deleted device collection.
The general pattern is:
Request page
|
v
Process devices
|
v
Next page available?
|
Yes
|
v
Request next page
|
v
Repeat
If your recovery tool searches only the first page, an administrator may incorrectly conclude that a deleted device does not exist.
This becomes more important in large tenants where many objects are deleted and restored over time.
Build a Device Recovery Service
Do not place Graph recovery calls directly inside UI event handlers.
Create a service boundary.
public interface IEntraDeviceRecoveryService
{
Task<IReadOnlyList<DeletedDeviceInfo>>
GetDeletedDevicesAsync(
CancellationToken cancellationToken);
Task RestoreDeviceAsync(
string objectId,
CancellationToken cancellationToken);
}
Use a model that contains only the fields required by the application:
public sealed record DeletedDeviceInfo(
string ObjectId,
string? DisplayName,
string? DeviceId,
string? OperatingSystem,
string? OperatingSystemVersion,
string? TrustType);
Then implement the Graph-specific logic inside the service.
This gives the application a clean separation:
UI
|
v
Device Recovery Service
|
v
Microsoft Graph
|
v
Microsoft Entra ID
If the Graph SDK changes later, the rest of the application does not need to know about those SDK changes.
Add an Explicit Confirmation Step
Device recovery should normally require confirmation.
For example:
Restore this device?
Name: SALES-LAPTOP-014
Device ID: 4c21...
Object ID: A1B2...
[Cancel] [Restore]
This is especially important in administrative applications.
A recovery button should not be equivalent to selecting a device and immediately issuing a privileged directory operation.
For higher-risk environments, you can also require:
The exact controls depend on the organization's security model.
Record an Audit Entry
Microsoft Graph tells your application what happened at the API level.
Your own application should also record the administrative action.
For example:
2026-11-11 11:42
Administrator: [email protected]
Action: Restore Entra device
Object ID: A1B2...
Device ID: 4C21...
Reason: Device deleted accidentally
Result: Success
Avoid storing unnecessary device information in application logs.
The audit record should contain enough information to explain the administrative action without turning ordinary application logs into a directory-data dump.
Handle Permission Errors
A failed restore does not always mean that the device cannot be restored.
The request may fail because the application does not have sufficient permissions.
Typical failure categories include:
Authentication failure
Permission failure
Device not found
Invalid object ID
Expired deleted object
Throttling
Transient network error
Service-side failure
Your service layer should translate these into meaningful application errors.
For example:
try
{
await RestoreDeviceAsync(
deviceObjectId,
cancellationToken);
}
catch (Exception ex)
{
Console.WriteLine(
$"Device restore failed: {ex.Message}");
}
The production version should use structured error handling rather than displaying raw exception text to administrators.
The administrator should see something actionable, such as:
The device could not be restored because the application
does not have the required Microsoft Graph permission.
Handle Throttling and Transient Failures
Administrative tools are less likely than high-volume synchronization services to hit Graph throttling, but the application should still handle it correctly.
Do not respond to every failure with an immediate retry loop.
A poor pattern looks like this:
Request failed
↓
Retry immediately
↓
Retry immediately
↓
Retry immediately
A better pattern uses bounded retry behavior with appropriate backoff for transient failures.
For a single interactive restore operation, the user should receive a clear error if the operation cannot complete within a reasonable time.
Do not create an infinite retry loop around a privileged directory operation.
Protect the Restore Operation From Duplicate Actions
Suppose an administrator clicks Restore twice.
The first request succeeds.
The second request may fail because the device is no longer in the deleted-items collection.
This is not necessarily a system failure.
The application should treat restore as an operation that changes state.
A useful flow is:
Deleted
|
| Restore
v
Active
Once the device becomes active, a second restore operation should be recognized as unnecessary.
Disable the restore button while the operation is in progress and refresh the device list after completion.
What Restore Does Not Mean
Restoring the directory object does not necessarily mean every aspect of the physical device is immediately healthy.
The application should not tell the administrator:
“Everything on the device is fixed.”
Restoration concerns the directory object.
Other systems may have their own state.
For example:
Microsoft Entra device object
|
+-- Intune management
+-- Compliance state
+-- Conditional Access
+-- Local Windows state
+-- Certificates
+-- User sign-in state
A restored Entra device should therefore be verified against the operational requirements of the organization.
If the device was deleted because of a security incident, restoring it may also require additional investigation.
Recovery After Accidental Deletion
Consider a practical scenario.
An administrator accidentally deletes a corporate laptop from Microsoft Entra ID.
The support team receives a request:
Device: SALES-LAPTOP-014
User: Sales employee
Problem: Device was deleted accidentally
The recovery application performs:
1. Search deleted devices.
2. Find SALES-LAPTOP-014.
3. Display Object ID and Device ID.
4. Administrator confirms the device.
5. Call restore.
6. Query the active devices collection.
7. Confirm that the device exists again.
8. Record the recovery action.
9. Ask the support team to verify downstream management state.
This workflow is much safer than exposing a button that simply restores the first matching device.
Testing Device Recovery
Do not test recovery for the first time against a production device.
Use a controlled test tenant and test device.
Test at least these scenarios:
1. Existing deleted device
2. Multiple devices with similar names
3. Device not found
4. Invalid object ID
5. Missing Graph permission
6. Already restored device
7. Expired deleted object
8. Large deleted-device collection
9. Pagination
10. Temporary Graph failure
11. Throttling
12. Duplicate restore request
Also verify the post-restore state.
A test is not complete just because the restore POST request returned successfully.
Common Mistakes
Searching only active devices
A deleted device will not appear in the normal active devices collection.
Use the deleted-items endpoint when investigating deleted objects.
Using the device ID as the restore identifier
The recovery API works with the deleted directory object's ID.
Do not confuse the device ID with the directory object ID.
Restoring by display name
Display names can be duplicated.
Always verify the object ID before performing the recovery.
Assuming deletion is permanent
Deleted device objects can remain recoverable for a limited period.
Check the deleted-items collection before concluding that the device is gone permanently.
Ignoring pagination
The device may exist on a later page of the deleted-device collection.
Treating restore as a complete device repair
Restoring the directory object does not automatically validate every management system associated with the physical device.
Granting excessive permissions
Recovery requires privileged access, but that does not mean the application needs unrestricted directory permissions.
Use the least privilege appropriate to the workflow.
Production Architecture
A practical recovery service can use the following architecture:
Administrator
|
v
WinUI / Web / Admin API
|
v
Authorization
|
v
DeviceRecoveryService
|
v
Microsoft Graph Client
|
v
Microsoft Entra ID
|
+-- Deleted devices
|
+-- Active devices
Add audit logging around the service:
Restore request
|
+-- Administrator
+-- Target object ID
+-- Reason
+-- Timestamp
+-- Result
|
v
Audit store
This provides traceability without coupling the UI directly to Microsoft Graph.
Advantages and Disadvantages
Advantages:
Device recovery can be integrated into an internal .NET administration tool.
Administrators can search deleted devices programmatically.
Recovery can be verified automatically.
Audit information can be attached to the administrative action.
The workflow can be combined with other device-management processes.
Graph SDK provides a strongly typed development model.
Disadvantages:
Recovery is a privileged directory operation.
Deleted objects are available only for a limited retention period.
Device ID and directory object ID can easily be confused.
Large tenants require proper pagination.
Restoring the directory object does not guarantee that downstream device-management state is correct.
Graph permissions must be configured carefully.
The recovery workflow requires additional authorization and auditing in production.
Production Checklist
Before deploying a Microsoft Entra device recovery tool, verify:
The application uses the correct Microsoft Graph permissions.
Administrator consent is configured where required.
Deleted devices are queried through the deleted-items API.
Directory object ID is used for restoration.
Device ID is displayed separately from object ID.
Display names are not treated as unique identifiers.
Pagination is handled.
Restore operations require confirmation.
Duplicate restore attempts are handled safely.
Graph errors are translated into useful messages.
Transient failures use bounded retry behavior.
Restore actions are audited.
ETL or application logs do not expose unnecessary directory information.
Post-restore verification is performed.
Downstream device-management state is checked when required.
Recovery is tested in a controlled environment before production use.
Summary
Microsoft Graph provides a practical way to automate the recovery of deleted Microsoft Entra device objects from a .NET application.
The core workflow is straightforward:
Query deleted devices
↓
Identify the correct object
↓
Confirm object ID
↓
Call restore
↓
Verify active device
↓
Record the recovery
The difficult part is not the restore request itself. The important engineering work is around that request.
A reliable recovery tool must distinguish device ID from directory object ID, handle pagination, enforce the right permissions, require administrator confirmation, deal with expired or already-restored objects, and verify the result after restoration.
It should also recognize the boundary between restoring a Microsoft Entra directory object and restoring the complete operational state of a physical device.
When those boundaries are handled correctly, Microsoft Graph can turn an otherwise manual recovery task into a controlled and auditable .NET workflow.
Join the conversation! Your thoughts help the community grow.