Backing up Conditional Access policies in Entra External ID

Conditional Access policies are one of the few things in Entra with a genuine safety net: delete one and you have 30 days to restore it from the portal. That safety net is narrower than it looks: it covers deletion but not modification, it expires, and a restored policy does not always come back the way it left. This article covers what Microsoft protects, where the gaps are, and how EIDGuard fills them.

What Microsoft gives you

Conditional Access policies and named locations both support soft delete. A deleted policy is retained for 30 days and can be restored from Entra ID → Conditional Access → Deleted policies.

Two details in Microsoft's own guidance are worth knowing before you use it:

• Restore into report-only mode first. Microsoft warns that restoring a policy to its previous state "might have unintended consequences" and recommends report-only, then reviewing before enabling. A policy that was On when deleted comes back On unless you choose otherwise.
• Restored named locations lose their trusted flag. A named location that was marked trusted is not trusted again after recovery. Any policy that keyed off that trust behaves differently until you re-mark it, which is easy to miss, because the location itself looks restored.

Note also that Microsoft Entra Backup and Recovery does not apply here. It covers Conditional Access policies, but only in workforce tenants; External ID tenants are explicitly out of scope. See Does Microsoft back up Microsoft Entra External ID?.

Where the gap is

Modification. This is the important one. Soft delete triggers on deletion. If someone edits a policy, widens an assignment, removes a condition, flips a grant control, disables it, nothing was deleted, so nothing enters the recycle bin. There is no previous value recorded and nothing to restore from.

That matters more for Conditional Access than for most object types, because the common failure is not "the policy is gone." It is "the policy is still there and no longer does what we thought." A disabled MFA requirement looks completely normal in the policy list.

The 30-day edge. Policies protecting a seasonal or partner-facing application can go a long time before anyone notices they are missing. Past 30 days the policy is gone for good, for you and for Microsoft Support.

No point in time. A recycle bin restores one object as it was at deletion. It cannot answer "what did our Conditional Access posture look like before last month's change window?"

How EIDGuard covers it

Conditional Access policies and named locations are captured in every recovery point alongside the rest of your tenant configuration, which changes what you can do about all three gaps.

Property-level drift detection. Nightly verification compares each policy in the live tenant against your last known-good recovery point and reports differences down to the property. A row reading Different · CA03, Require MFA for partner administrators · state · enabled → disabled is the early warning that soft delete cannot give you, because nothing was deleted.

History beyond 30 days. Recovery points are retained for the period you configure, so "restore the policy as it was in June" is a question with an answer.

Restores come back disabled, always. EIDGuard recreates Conditional Access policies in a disabled state without exception. A restored policy can never lock anyone out before you have reviewed its assignments, the same caution Microsoft recommends, applied automatically rather than remembered.

A practical routine for change windows

Conditional Access changes are the ones most worth bracketing:

1. Take an on-demand backup immediately before the change (Run backup).
2. Make the change.
3. Compare that recovery point against the live tenant from the Drift page.

The report is then an exact record of what the change actually touched, which is frequently more than intended, especially where policy assignments overlap.

After a restore, verify behaviour rather than existence

A policy that exists is not the same as a policy that works. After restoring:

• Re-enable each policy deliberately, having read its assignments.
• Re-mark any restored named location as trusted, if it was before.
• Confirm the policy actually applies to the users and applications you expect, using report-only mode or the sign-in logs.