Back up Conditional Access policies

Understand the additional backup scope

Conditional Access belongs to Entra ID, so it is separate from the Intune policy types in the ordinary backup selection. The service is off for each tenant until you turn it on. Updating TenuVault does not automatically start collecting access policies that you did not choose to include.

The saved policy contains its configuration and state, including who it covers, application references, conditions, grant controls and session controls. References to users, groups and applications are not backups of those objects. Keep identity recovery and emergency access procedures alongside the policy backup rather than assuming an access rule can recreate its targets.

Enable and verify the service

Open Settings, then Services and permissions. Select the tenant and turn on Include in backups for Entra Conditional Access. Read the Backup and Restore badges: they show whether the existing app registration has the permissions each operation needs. Enabling the service does not grant those permissions.

For delegated backups, the documented read permission is Policy.Read.All, with a suitable Entra role such as Security Reader or Global Reader. Restores additionally require Policy.ReadWrite.ConditionalAccess and an appropriate administrator role. Grant restore access only when that workflow is required, then use Check again to inspect the current sign-in's permissions.

If the service is enabled but cannot be read, TenuVault leaves its three types out and names the missing permission in the backup log. The rest of the backup can still run. Inspect the result and confirm the Conditional Access objects are present instead of treating a completed Intune backup as proof that this optional scope was captured.

Include the scope in unattended runs deliberately

Manual backups and scheduled runners can have different permissions. The optional Backup Reader needs its setup run with IncludeConditionalAccess to receive the read-only application permission. Without that permission, scheduled reader backups omit these types even when a manual backup made with your sign-in includes them.

For cloud backups, set the Azure Automation variable TenuVaultIncludeConditionalAccess to true and grant Policy.Read.All to the managed identity. Verify an actual run and the saved result after changing those settings. A checkbox in the desktop service setup is not proof that a separately configured cloud identity can read the same scope.

Backup Reader never receives permission to change Conditional Access. Restores use your own sign-in. This separates routine capture from the ability to write access rules, while still requiring you to maintain a working recovery identity and the permissions needed during an incident.

• Configure Azure-backed backups

Read the restore safeguards before applying

When TenuVault recreates an enabled policy, the new policy starts in report-only. A policy saved as off remains off when created. Replacing a live policy writes the backed-up configuration without introducing more enforcement than the live policy currently has; a previously enabled snapshot can therefore be restored as report-only.

The restore review warns about changes to exclusions, grant controls and session controls. Inspect the result in Entra and check sign-in impact before deciding whether to enable enforcement yourself. Do not treat a successful configuration restore as a request to immediately turn on every recovered access rule.

Microsoft-managed policies are retained for drift detection and are never recreated or overwritten by TenuVault. Review or change their supported state and exclusions in Entra. A backup entry for one of these policies is evidence for comparison, not a promise that the restore wizard can write it back.

Resolve references and dependencies

Named locations and custom authentication strengths are restored before policies that refer to them, and references within that restore are pointed at the new objects. Select the necessary dependencies together and inspect any item the plan refuses. Built-in strengths are portable service definitions and are not recreated from backup.

TenuVault checks references before writing a policy. A known missing excluded account or group stops the policy, because the exclusion would protect nobody. A missing named location or authentication strength also blocks it. When a reference cannot be checked because permission is missing, the warning says so; review it in Entra rather than interpreting an unreadable reference as valid.

Cross-tenant work needs additional care because source identities do not automatically exist in the target. Copy supported dependencies in the same run where appropriate and reconcile the target users and groups separately. An access-policy backup cannot make the source tenant's group IDs meaningful in another tenant.

Access-policy recovery checklist

Keep a dated record of the service scope, runner identity and backup result. Test the recovery procedure in a controlled environment while you can still check the source. Store the recovery key and emergency access instructions where an admin can reach them without depending on the access rules being recovered.

• Confirm the optional service is enabled and the actual runner can read it.
• Check custom strengths, named locations and policy references in the saved copy.
• Review blockers, warnings and the written policy state after a restore.
• Validate sign-in impact in Entra before enabling recovered enforcement.