Restore deleted Conditional Access policies with Entra Backup and Recovery

To restore a deleted Conditional Access policy, open Entra ID > Conditional Access > Deleted policies within 30 days of the deletion and select Restore, ideally in report-only mode. To undo a bad change to a policy that still exists, use Microsoft Entra Backup and Recovery: pick a daily backup from the last seven days, run a difference report scoped to Conditional Access policies, review what changed, and recover only the affected policy.

Who this is for and what you will have at the end

This guide is for identity administrators who manage Conditional Access and need a tested procedure for the day someone deletes the wrong policy, removes a named location, or edits an exclusion that locks people out. It covers the two built-in recovery mechanisms Microsoft Entra ID now provides and when each one applies.

At the end you will have:

• A clear rule for choosing between soft-delete restore and Backup and Recovery.
• A portal and Microsoft Graph PowerShell procedure for restoring deleted Conditional Access policies and named locations.
• A procedure for rolling back modified policies with difference reports and scoped recovery jobs.
• A verification and troubleshooting checklist, plus the controls that stop the next incident from becoming permanent.

If a broken policy is already blocking sign-ins, the companion guide on AADSTS53003 blocked by Conditional Access shows how to find the policy responsible from the sign-in logs.

Soft delete or Backup and Recovery: which one to use

Microsoft Entra ID has two separate recovery paths. They overlap, but they answer different questions.

Soft delete handles deletions. When a Conditional Access policy or named location is deleted, it isn't removed immediately. It moves to a soft-deleted state for 30 days with all properties maintained, then it's hard deleted. Soft delete also covers users, Microsoft 365 Groups, cloud security groups, application registrations, service principals and administrative units.

Microsoft Entra Backup and Recovery handles both deletions and modifications. It takes a backup of supported objects automatically once a day, keeps up to seven days of backup history, and lets you compare any backup with the current tenant and recover objects to their backed-up state. For Conditional Access policies and named location policies, all properties are in scope.

Backup and Recovery uses soft delete under the hood. It restores soft-deleted objects rather than recreating them, so object IDs and references stay intact.

Prerequisites

• A workforce tenant. External ID and Azure AD B2C tenants aren't supported by Backup and Recovery.
• Microsoft Entra ID P1 or P2 licenses for Backup and Recovery.
• For soft-delete restore of policies and named locations: at least the Conditional Access Administrator role. The Graph restore API supports Conditional Access Administrator and Security Administrator.
• For Backup and Recovery: Microsoft Entra Backup Reader to view backups, difference reports and recovery history; Microsoft Entra Backup Administrator to create difference reports and start recovery. Global Administrator includes all Backup Administrator permissions.
• For the PowerShell steps: the Microsoft Graph PowerShell SDK, including the beta module Microsoft.Graph.Beta.Identity.SignIns. The deleted-items endpoints for Conditional Access are currently in the Microsoft Graph beta API.

Step 1: Confirm what happened in the audit log

Before restoring anything, establish whether the policy was deleted or modified, by whom and when. Recovery decisions depend on the answer.

1. Sign in to the Microsoft Entra admin center as at least a Reports Reader.
2. Browse to Entra ID > Monitoring & health > Audit logs.
3. Set the Date range, and from the Service filter select Conditional Access.
4. Look for the activities Delete Conditional Access policy, Update Conditional Access policy, Delete named location and Update named location.
5. Open a row and check the Modified Properties tab, which shows old and new values as JSON.

If you send audit logs to Log Analytics, the same information is in the AuditLogs table:

AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName in ("Delete Conditional Access policy", "Update Conditional Access policy", "Delete named location", "Update named location")
| project TimeGenerated, OperationName, InitiatedBy, TargetResources
| order by TimeGenerated desc

Audit data is kept for 30 days by default. Note the time of the bad change: for Backup and Recovery you need a backup taken before that time.

Step 2: Restore a deleted Conditional Access policy

In the Microsoft Entra admin center

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
2. Browse to Entra ID > Conditional Access > Deleted policies.
3. Select the ellipsis (...) at the far right of the policy you want to restore.
4. Select Restore.
5. In the Restore Conditional Access policy? dialog, choose whether to restore the policy in Report-only mode or in the state it had when it was deleted, which might be On. Then select Restore.

Microsoft warns that restoring a policy to its previous state might have unintended consequences and recommends restoring in report-only mode first, reviewing the results, and only then enabling it. That matters most for block policies and for policies whose included or excluded groups have changed since the deletion.

With Microsoft Graph PowerShell

The beta module exposes list and restore cmdlets for deleted policies. Listing deleted policies needs Policy.Read.All; writing Conditional Access policies uses Policy.ReadWrite.ConditionalAccess.

Import-Module Microsoft.Graph.Beta.Identity.SignIns
Connect-MgGraph -Scopes "Policy.Read.All", "Policy.ReadWrite.ConditionalAccess"
 
# List soft-deleted Conditional Access policies with their deletion time
Get-MgBetaIdentityConditionalAccessDeletedItemPolicy |
    Select-Object Id, DisplayName, State, DeletedDateTime
 
# Restore one policy by ID
$policyId = "59f2aa7a-4c49-4baa-932f-0300792e06c2"
Restore-MgBetaIdentityConditionalAccessDeletedItemPolicy -ConditionalAccessPolicyId $policyId

The restore call takes no request body and returns the restored policy with an empty deletedDateTime. Unlike the portal dialog, it doesn't offer a report-only choice, so switch the policy to report-only straight away and review it before you turn it back on:

Import-Module Microsoft.Graph.Identity.SignIns
 
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyId -BodyParameter @{
    state = "enabledForReportingButNotEnforced"
}

The valid state values are enabled, disabled and enabledForReportingButNotEnforced.

Step 3: Restore deleted named locations

Named locations follow the same 30-day soft-delete model, with one important difference: a named location marked as trusted can't be deleted, and a named location recovered from soft delete is not marked as trusted. Policies that rely on the trusted flag behave differently until you review the location and mark it trusted again.

In the portal:

1. Sign in as at least a Conditional Access Administrator.
2. Browse to Entra ID > Conditional Access > Named locations > Deleted named locations.
3. Select the ellipsis (...) next to the location, select Restore, and confirm in the Restore selected Named location? dialog.

With Microsoft Graph PowerShell, list deleted locations and restore one with the matching beta cmdlet:

# List soft-deleted named locations
Get-MgBetaIdentityConditionalAccessDeletedItemNamedLocation |
    Select-Object Id, DisplayName, DeletedDateTime
 
# Restore one named location
$locationId = "1a4c0633-332f-4691-a27a-fd8334938a62"
Restore-MgBetaIdentityConditionalAccessDeletedItemNamedLocation -NamedLocationId $locationId

Restore named locations before restoring policies that reference them, so the policy conditions point at an existing location when you review them.

Step 4: Roll back a modified policy with Backup and Recovery

Soft delete can't help when a policy was edited rather than deleted. Backup and Recovery can, provided the change happened after one of the retained daily backups.

Create a difference report

1. Sign in to the Microsoft Entra admin center as at least a Microsoft Entra Backup Administrator.
2. Go to Backup and recovery > Backups. Choose the most recent backup taken before the bad change, and select Create difference report.
3. Apply a filter to limit the scope. Choose Include only certain types of objects and select Conditional Access policies (add named location policies if they changed too), or Include only specific objects by their ID and enter the policy object ID. You can enter up to 100 object IDs.
4. Select Create difference report.

The report moves through Loading data, In progress and Completed. The first report against a backup loads the backup data first; Microsoft's planning estimate is up to one hour for tenants with up to 50,000 objects and up to two and a half hours above one million objects. Later reports against the same backup skip the loading step. Only one difference report or recovery job can run in a tenant at a time.

Review the report

Open the completed report from Backup and recovery > Difference reports. For each changed object you see:

• Changed attributes: the Report value (current) next to the Backup value.
• Changed links: relationship differences with the action recovery would take.
• Recovery action: Update (revert attributes or links), Restore (restore a soft-deleted object) or Soft delete (remove an object created after the backup).

Read the recovery actions carefully. Recovery returns every in-scope object to its backup state:

So if a colleague legitimately created a new Conditional Access policy after the backup, recovering all Conditional Access policies from that backup soft-deletes it. Scope by object ID when only one or two policies are wrong.

Run the recovery

From the completed report, select Recover. Recovery uses the same scope as the report and doesn't allow further filtering. To fix one high-priority policy without a full recovery job, open its changed attributes panel and select Recover this object.

A difference report is a point-in-time comparison. Recovery always applies against the tenant's current state, so if the policy was changed again after you created the report, create a fresh report before recovering. Recovery actions apply directly to the tenant and can't be undone automatically, although every change is written to the audit log.

You can also start from Backup and recovery > Backups > Recover backup without a report, but Microsoft recommends always running a difference report first.

Verify the recovery

1. Open Backup and recovery > Recovery History and confirm the job status is Completed. The page shows the backup timestamp and ID used, start and completion times, and the number of objects and links modified. History is kept for seven days.
2. Open the restored policy and compare users, groups, exclusions, target resources, conditions and grant controls with the backup values from the difference report.
3. Check the audit log for the recovery's Update Conditional Access policy entries.
4. Leave restored policies in report-only mode long enough to review results on the Report-only tab of sign-in log entries, then switch Enable policy to On.
5. For restored named locations, confirm the IP ranges or countries and set the trusted flag again where it's needed.

Troubleshooting

Prevent the next incident

Recovery is the safety net, not the control. Three measures reduce how often you need it:

• Protect hard deletion. Add a protected action for microsoft.directory/deletedItems/delete so that permanently deleting soft-deleted objects requires satisfying a Conditional Access policy, such as phishing-resistant MFA. Protected actions can also cover microsoft.directory/conditionalAccessPolicies/delete and microsoft.directory/namedLocations/delete. Exclude an emergency access account from that policy.
• Document the known-good state. Backups only go back seven days. Export Conditional Access policies and named locations regularly with Microsoft Graph and keep the JSON under version control, as Microsoft's recoverability guidance recommends.
• Monitor deletions. Stream audit logs to Log Analytics or Microsoft Sentinel and alert on the delete activities listed in Step 1.

Conditional Access is one control point in a wider access model; the Zero Trust remote access architecture shows where it sits alongside device trust and network controls.

Checklist

• Audit log reviewed: deleted or modified, who, and when.
• Deleted named locations restored first, then reviewed and re-marked as trusted where needed.
• Deleted policies restored in report-only mode within the 30-day window.
• Modified policies rolled back from a backup taken before the change, using a difference report scoped by object type or ID.
• Recovery History shows Completed; restored settings match the backup values.
• Policies returned to On only after report-only results look correct.
• Protected actions configured for hard deletion; regular JSON exports in place.

References

• Microsoft Entra Backup and Recovery overview
• Supported objects and recoverable properties in Microsoft Entra Backup and Recovery
• Backup, difference report, and recovery model
• Create and review difference reports
• Recover objects using Microsoft Entra Backup and Recovery
• Review recovery history
• Troubleshoot Microsoft Entra Backup and Recovery
• Soft deletion in Microsoft Entra Backup and Recovery
• Recover from deletions in Microsoft Entra ID
• Restore conditionalAccessPolicy (Microsoft Graph beta)
• Restore a namedLocation (Microsoft Graph beta)
• List policyDeletableItem objects (Microsoft Graph beta)
• Use audit logs to troubleshoot Conditional Access policy changes
• What are protected actions in Microsoft Entra ID?