Recovering deleted users and groups in Entra

Soft delete vs hard delete: the recovery window you’re actually working with

When you delete a user or group in Entra, it usually enters a soft-deleted state first. Soft-deleted objects are hidden from normal lists but remain recoverable for a limited retention period (commonly up to 30 days, depending on object type and service behavior).

Soft delete (recoverable)

• The object moves to a Deleted users or Deleted groups view.
• You can restore it with most properties intact (including object ID in many cases).
• Access typically remains broken until the restore completes and entitlements re-evaluate.

Hard delete (permanent)

• The object is permanently removed (often via “Delete permanently”).
• Restore is not available; you must recreate and reassign access.
• Downstream workloads (mailboxes, OneDrive, app data) may have their own retention rules.

The operational takeaway: treat deletion recovery like incident response. Move quickly, restore correctly, and verify everything that matters (identity, licensing, MFA methods, group memberships, app assignments, and logs).

Permissions and prerequisites

You’ll need the right Entra role to restore directory objects. Commonly used roles include Global Administrator, User Administrator (for users), and roles that can manage groups (often Groups Administrator or equivalent in your org’s delegation model).

If your organization uses role-based delegation heavily, review your Entra RBAC design so the people responsible for recovery can actually perform the restore when it matters. See: Role-based access control in Microsoft Entra.

Restore deleted users in the Entra admin center

The Entra admin center provides a dedicated “Deleted users” view (your recycle bin for users). This is the fastest path for a one-off restore.

Steps (UI)

1. Sign in to the Microsoft Entra admin center (entra.microsoft.com).
2. Go to Identity > Users.
3. Open Deleted users.
4. Select the deleted user.
5. Click Restore user.

What “restore user” usually brings back

• User object and core attributes.
• Group memberships and app assignments (in many scenarios), but expect exceptions.
• Sign-in ability once access, policies, and licensing re-evaluate.

Common surprises after restoring a user

• Licenses: you may need to reassign licenses or wait for group-based licensing to reapply.
• MFA: authentication methods can behave differently depending on how they were managed.
• Conditional Access: restored users re-enter policy evaluation—blocked sign-ins might be “working as designed.”
• UPN / proxy addresses: if the original UPN was reused while the user was deleted, you may need to adjust during recovery.

If you’re troubleshooting sign-in behavior after a restore, exporting and reviewing Entra logs is often the fastest way to pinpoint whether the issue is policy, risk, device state, or authentication method related. See: How to export Entra ID logs efficiently.

Restore deleted groups in the Entra admin center

Deleting groups is especially disruptive in modern environments because groups often drive: app assignments, conditional access targeting, RBAC, licensing, and access to shared resources.

Steps (UI)

1. Sign in to the Microsoft Entra admin center (entra.microsoft.com).
2. Go to Identity > Groups.
3. Open Deleted groups.
4. Select the deleted group.
5. Click Restore group.

Group restore notes you should know

• In the recovery window, Entra can typically restore Microsoft 365 groups and (in supported scenarios) cloud security groups.
• Restoration can preserve membership and ownership, but always verify critical entitlements afterwards.
• Access tied to that group usually remains broken until the group is restored and access control systems re-evaluate.

If your access model relies on clean identity and group lifecycle management, it’s worth aligning group governance with your broader Entra identity management practices. See: Manage identities in Microsoft Entra ID.

Restore via Microsoft Graph PowerShell (single restore and bulk restore)

The UI is great for one-off restores, but PowerShell is often better when you need speed, repeatability, auditing, or bulk recovery (for example, after an automation error). Microsoft’s direction is to use Microsoft Graph PowerShell for directory operations.

Connect to Microsoft Graph PowerShell

# Install once (PowerShell 7+ recommended)
# Install-Module Microsoft.Graph -Scope CurrentUser

# Connect with appropriate scopes
Connect-MgGraph -Scopes "Directory.ReadWrite.All"

List deleted users and groups

# List deleted directory objects (generic)
Get-MgDirectoryDeletedItem -All

# Filter to users (example: look for a UPN fragment in additional properties)
# In practice, you may prefer to locate by display name or export and search.
Get-MgDirectoryDeletedItem -All | Where-Object {
  $_.AdditionalProperties["userPrincipalName"] -like "*alex*"
}

# Filter to groups (example: display name contains "Finance")
Get-MgDirectoryDeletedItem -All | Where-Object {
  $_.AdditionalProperties["@odata.type"] -eq "#microsoft.graph.group" -and
  $_.AdditionalProperties["displayName"] -like "*Finance*"
}

Restore a deleted user or group by ID

# Restore by deleted item ID (DirectoryObject ID from deleted items)
$deletedObjectId = "00000000-0000-0000-0000-000000000000"
Restore-MgDirectoryDeletedItem -DirectoryObjectId $deletedObjectId

Bulk restore (example workflow)

A practical bulk pattern is: export the deleted objects you care about, review, then restore by ID. Below is a simple approach for restoring all deleted users that match a naming pattern.

# Export candidates
$deletedUsers = Get-MgDirectoryDeletedItem -All | Where-Object {
  $_.AdditionalProperties["@odata.type"] -eq "#microsoft.graph.user" -and
  $_.AdditionalProperties["userPrincipalName"] -like "*@contoso.com"
}

$deletedUsers |
  Select-Object Id,
    @{n="UserPrincipalName";e={$_.AdditionalProperties["userPrincipalName"]}},
    @{n="DisplayName";e={$_.AdditionalProperties["displayName"]}} |
  Export-Csv ".\deleted-users.csv" -NoTypeInformation

# Restore all exported users (use with care)
Import-Csv ".\deleted-users.csv" | ForEach-Object {
  Restore-MgDirectoryDeletedItem -DirectoryObjectId $_.Id
}

When PowerShell is the right choice

• You need to restore many objects fast.
• You want a repeatable recovery runbook (including pre/post checks).
• You need to integrate restoration into an incident workflow.

Special case: hybrid / directory-synced users and groups

If your Entra tenant is synchronized from on-premises Active Directory (for example via Entra Connect / cloud sync), restoring in the cloud isn’t always the correct “source of truth” fix.

Rule of thumb

• Cloud-only object deleted → restore in Entra (UI or Graph) is typically correct.
• Synced object deleted on-prem → restore it in on-prem AD first, then let sync rehydrate it in Entra.

Why it matters: if the authoritative object is still missing on-prem, sync may delete it again (or create confusing mismatches). Treat hybrid identity like a replication system: fix the authoritative directory, then allow the cloud directory to converge.

If your hybrid environment also uses password writeback and self-service resets, keep that integrated flow healthy so restored users can recover access cleanly without helpdesk escalations: Enable Azure AD Password Writeback: Step-by-step guide.

Post-restore validation checklist (don’t skip this)

Restoration is only the first step. You want to confirm that the user/group is not just present, but functional in the ways your business cares about.

For restored users

• Sign-in works: confirm sign-in succeeds (or confirm the expected policy block).
• Licenses applied: direct assignment or group-based licensing has re-applied.
• Group memberships: critical security groups and licensing groups are correct.
• App access: enterprise apps and roles that depend on the user are correct.
• MFA / authentication methods: confirm method availability and reset only if necessary.
• Audit trail: identify who deleted the object and from where; preserve evidence if needed.

For restored groups

• Membership is intact (especially owners and privileged members).
• Assignments are intact: app assignments, role assignments, and access packages that reference the group.
• Policy targeting: Conditional Access or other policies that target the group behave as expected.

If you see sign-in failures or lockouts after recovery, review your lockout protections and sign-in controls so you can distinguish “broken” from “correctly blocked” quickly: Azure AD account lockout policy.

Prevention and detection: reduce the chance you’ll need this runbook

Recovery is important, but reducing deletion incidents (and detecting them fast) is even better. Here are practical controls that consistently pay off:

1) Limit who can delete users and groups

• Use least privilege and delegated administration.
• Prefer Privileged Identity Management (PIM) with just-in-time elevation for high-impact roles.
• Validate your RBAC design: Role-based access control in Microsoft Entra.

2) Monitor deletions like security events

• Alert on deletion operations for users and groups.
• Export audit logs to your SIEM and investigate unusual patterns quickly.
• Build a “who/what/where” habit with logs: How to export Entra ID logs efficiently.

3) Use guardrails for identity lifecycle

• Automate joiner/mover/leaver processes and reduce manual deletes.
• For hybrid environments, ensure “source of truth” processes are documented and followed.
• Keep identity operations aligned with your overall Entra identity management approach: Manage identities in Microsoft Entra ID.

Further reading (official docs)

• Restore or permanently remove a recently deleted user (Microsoft Learn)
• Restore a deleted Microsoft 365 group or cloud security group (Microsoft Learn)
• Recover from deletions in Microsoft Entra ID (Microsoft Learn)
• Restore-MgDirectoryDeletedItem (Microsoft Graph PowerShell)
• Restore deleted directory object item (Microsoft Graph REST)