Backing Up Entra ID and Microsoft 365 Configuration: What the Recycle Bin Covers and Misses

The settings backup most plans forget

If a tenant were wiped tomorrow, mail and files could come back from a backup service. But the rules that decide who may sign in, from which devices, to which apps, would be gone too. Rebuilding Conditional Access from memory takes days and invites mistakes, and during that time the tenant is either open or locked. The same goes for Intune device configuration and for the app registrations that line-of-business software uses to sign in.

There are two kinds of loss to plan for. One is deletion, by accident, by a script or by an attacker with admin rights. The other is a wrong change: a policy edited, a setting switched off, a secret rotated. They need different protection.

What Entra soft delete covers

Microsoft Learn's guide to recovering from deletions says soft-deleted objects enter a suspended state where they keep their properties and can be restored for 30 days. After that they are permanently deleted. The object types that support soft delete are users, Microsoft 365 Groups, cloud security groups, application registrations, service principals, administrative units, Conditional Access policies and named locations.

• Conditional Access policies: restorable from the Deleted policies page in the Entra admin center, by a Conditional Access Administrator. Microsoft says to review the policy after restoring to ensure it behaves as expected.
• Application registrations and service principals: deleting an app registration soft deletes it, and restoring it also restores its service principal. Microsoft notes that the service principal's previous policies, such as Conditional Access policies, are not restored.
• Users and groups: restorable for 30 days, with properties and group memberships kept for cloud security groups and Microsoft 365 Groups.
• The audit log records a delete event for every removal, which helps you see what happened and when.

What it does not cover

Microsoft is direct about the limit: all other item types are hard deleted and cannot be restored. Your administrators and Microsoft cannot restore hard-deleted items, and they must be re-created. The page also stresses preparing processes and documentation for that case. That list of other types is long. In practice it includes much of the configuration around identity, such as many tenant settings and policies that are not on the soft-delete list. Intune profiles and policies are managed inside Intune and are not among the soft-delete types Entra lists, so a deleted or overwritten profile needs your own copy to rebuild from.

Three more gaps matter in real incidents. Soft delete is a deletion feature, so an edited policy has no earlier version in the recycle bin. The 30‑day window can pass unnoticed, for example if a deletion is found during a quarterly review. And an attacker or careless administrator with enough rights can remove soft-deleted objects permanently.

Microsoft 365 Backup is about content

Microsoft 365 Backup is described in Microsoft Learn as protecting SharePoint sites, OneDrive accounts and Exchange mailboxes, with fast restore after events such as ransomware or accidental deletion. It is worth having for that purpose, but it is not an export of your Entra configuration. Treat identity and device configuration as a separate item in the backup plan.

What to export and how

Microsoft Graph is the interface that exposes these settings to scripts. Microsoft's documentation lists operations for Conditional Access policies, applications, service principals and Intune. A scheduled job can read them and save each as a JSON file. What to include:

• Conditional Access policies and named locations, plus authentication strength definitions.
• App registrations and enterprise applications: names, owners, redirect addresses, API permissions and consent grants. Never export or store secret values, and keep a note of which secrets exist and when they expire.
• Intune device compliance policies, configuration profiles, app protection policies and enrollment settings.
• Groups that policies depend on, with their membership rules.
• Authentication method settings, administrator role assignments and any custom roles.
• Domain, mail flow and Exchange Online settings that you could not rebuild from memory.

There are also commercial and open-source tools that do this for you. Whichever you pick, check that they cover the objects above, that they run on a schedule and that they keep versions, so you can see what changed between two days.

Where to keep the copies

• Store exports outside the tenant. A copy that sits in the tenant can be deleted by the same stolen admin account that damaged the tenant.
• Use a location with versioning and, where you can, write-once retention, so old copies cannot be overwritten.
• Keep access narrow. The exports show how your security is built and may contain internal names and addresses.
• Log the job's result and alert when it fails or when the output suddenly shrinks.

Prove it works

Once a quarter, pick one item and restore it into a test tenant or a spare policy name: a Conditional Access policy, a device profile, an app registration. Time it and write down what was missing from the export. Pair this with the break-glass test for emergency access accounts, because you want a way into the tenant while you restore. Our article on running a Microsoft 365 restore test covers the same habit for mail and files.

We set up scheduled configuration exports for Microsoft 365 and Entra, keep them outside the tenant and run the restore drill with you.

Sources

• Recover from deletions in Microsoft Entra ID (Microsoft Learn)
• Recoverability best practices (Microsoft Learn)
• Restore a soft deleted enterprise application (Microsoft Learn)
• Overview of Microsoft 365 Backup (Microsoft Learn)
• List Conditional Access policies, Microsoft Graph API (Microsoft Learn)
• Use the Microsoft Graph API with Intune (Microsoft Learn)
• List applications, Microsoft Graph API (Microsoft Learn)

This article is general information, not legal or technical advice for your environment. Product menus, license names and provider rules change; check the vendor's current documentation before you act. Last reviewed November 9, 2026.

Next article

Next · RegulationWriting the Customer Responsibility Matrix Section of a System Security Plan: Shared Responsibility With a Cloud ProviderWhen you keep controlled information in a cloud service, your system security plan has to show who does what for each requirement. The provider publishes a customer responsibility matrix. Your job is to turn it into specific, evidenced statements about your own side. Here is how to write that section and what an assessor looks for.8 min read

Related reading

• InfrastructureRPKI and ROAs for Regional Networks: What a ROA Says, Route-Origin Validation and ARIN Hosted RPKI8 min
• InfrastructureSeparating Global Networks: VRFs, VLANs and VXLAN-EVPN Across Datacenters10 min