Conditional Access and settings backup
Back up Conditional Access in every tenant, with a way back.
A copy of the settings that are hardest to rebuild. See exactly what changed and when, and put a policy back through an approved change.


Why this is hard today
Conditional Access is the setting most likely to be changed in a hurry and the hardest to rebuild. When someone adds an exclusion or deletes a policy, putting it back means remembering exactly how it was set, in every tenant you look after.
How ConfigCheckup solves it
What is backed up
Conditional Access policies, named locations, SharePoint and OneDrive sharing, user and guest permissions, authentication methods, security defaults, cross-tenant access defaults, and Intune compliance policies and configuration profiles.Every change, field by field
An account excluded from MFA, a policy switched to report-only, sharing opened to anyone: shown with the old and new value and the date.Deleted policies come back
A deleted Conditional Access policy is created again from its last version.Restores you can undo
A restore is a dry run, approval and a recorded way back, like every other change.
Connect
The backup uses the read permissions the assessment already has.
Backed up automatically
After every assessment, and every day on every plan. Only changes are stored, the last 30 versions of each setting.
Restore when needed
Pick the version, check the dry run, approve.
Every version, and the way back


Settings backups for the demo tenant: a deleted Conditional Access policy and a changed exclusion, field by field, with Restore this version. Demo workspace.
Check it yourself.
- Every change is shown field by field, with the old value, the new value and the date.
- Only changes are stored, and the last 30 versions of each setting are kept.
- A Conditional Access restore always needs two people to approve it; a sharing restore follows the tenant’s own rule. Each is dry-run first and can be rolled back. Check it: A Conditional Access restore always needs two people to approve it; a sharing restore follows the tenant’s own rule. Each is dry-run first and can be rolled back.
- It covers settings, not mailboxes, files or Teams content, and says so.
What it can’t see
Said plainly, so you know what you are buying.
- Everything backed up can be put back as an approved change, except the authentication methods policy, which is kept to compare and set back by hand.
- An Intune policy deleted from the tenant is shown but not created again: Microsoft needs its compliance actions and assignments as well, so it is rebuilt by hand from the backed-up version. Profiles holding keys or certificates (Wi-Fi, VPN, email, certificate and custom profiles) are compared only.
- Intune configuration profiles means the template profiles; Settings Catalog, Endpoint security and Administrative templates policies are not backed up yet.
- Groups, users and apps a policy refers to must still exist for Microsoft to accept a restore.
- Restores need the automation app, which the tenant adds separately.
It reads settings and activity records, never content, with permissions your tenant’s admin grants. Every permission and role, and why
Questions.
Is this a full tenant backup?
No. It covers security and sharing settings, not mailboxes, files or Teams content. Use a data backup product for those.
How much history is kept?
The last 30 versions of each setting. A version is stored only when something changed.
Plans: Daily backups on every plan; approved restores with Automate.
What each plan includesConfigCheckup
See it on your own tenants.
The findings and figures come from your tenant, not from averages.
14 days of daily monitoring and alerts, every finding with its fix guide, and reports on up to 3 tenants, from your first connected tenant. No card. Then choose the plan that fits.