Blog
What happens when a Microsoft Intune policy is deleted, and how to recover
Learn what happens when a Microsoft Intune policy is deleted, how devices are affected, who deleted it, and how to recover.
G2 Names Nerdio a Leader Across Fall 2026 Reports for Desktop as a Service Read the blog
Blog
Learn what happens when a Microsoft Intune policy is deleted, how devices are affected, who deleted it, and how to recover.
Table of Contents
A configuration profile has disappeared from the Microsoft Intune admin center. Nobody owns up to it, and devices are misbehaving.
The deletion is the smaller problem. Intune has no recycle bin, the settings the policy applied can stay on devices after the policy is gone, and if what vanished was a compliance policy, your Conditional Access policies quietly start granting access on a tenant default instead of an evaluated result. What you can recover depends almost entirely on what you set up before the delete button was clicked.
This guide is for Intune administrators and endpoint owners responding to an accidental policy deletion.
Deleting a Microsoft Intune policy permanently removes it from the admin center, but the settings it applied may stay on your devices.
Anyone doing Intune management at scale has met the aftermath, where a setting that no policy claims still gets enforced on every device.
The same behavior applies to physical endpoints and Windows Cloud (the umbrella term for the Windows 365 and Azure Virtual Desktop portfolio). Many enterprises run both. From Intune's perspective, policy removal and removing its assignment produce the same result, but device behavior varies by platform. Microsoft's troubleshooting documentation breaks it down like this:
|
Platform or profile type |
Behavior after deletion or unassignment |
|
Wi-Fi, VPN, certificate, and email profiles |
Removed from all supported enrolled devices |
|
Android |
For settings not covered by the profile-specific removal behavior above, Android keeps the settings on the device |
|
iOS/iPadOS |
All settings removed, except Allow voice roaming, Allow data roaming, and Allow automatic synchronization while roaming |
|
Windows |
Depends on the configuration service provider (CSP) behind each setting |
Windows requires extra care because behavior varies by CSP. The same troubleshooting documentation explains: "Some CSPs remove the setting, and some CSPs keep the setting, also called tattooing." A tattooed setting keeps its configured value after the policy is gone. Removing standard configuration policies can likewise leave modified settings intact, according to a Microsoft Q&A answer.
After an admin removes a user from an assigned group, settings removal can take "up to 7 hours or more", and Windows devices need the Microsoft Entra ID user to sign in and sync for settings to be removed. Microsoft recommends creating a new policy, configuring the setting to Not configured, and assigning it; when the policy applies, users should regain control of the setting. To actively rewrite tattooed settings to an intended value, admins can deploy another policy with the desired configuration to the affected devices.
A deleted compliance policy can change your security posture by causing affected devices to fall back to the tenant-wide compliance setting.
When an admin deletes or unassigns a compliance policy, affected devices fall back to the tenant-wide setting "Mark devices with no compliance policy assigned as," found under Endpoint security > Device compliance > Compliance policy settings. The default value is Compliant. Microsoft's own documentation states that "Devices that aren't sent a device compliance policy are considered compliant," and recommends changing the setting to Not compliant for any tenant using Conditional Access.
The default Compliant fallback affects Conditional Access after an accidental deletion. For affected devices with no remaining compliance policy, your Conditional Access policies keep granting access based on the tenant's Compliant fallback rather than an evaluated policy.
Nothing in the console turns red. The devices report compliant, which is what makes this the first thing to check. Intune records the deletion in the audit log, and Microsoft's troubleshooting documentation notes that an unassigned compliance policy can still show as assigned in the admin center and stay in effect until the device syncs, which is by design. Either way, the console view lags the change.
Other policy types behave differently:
The right recovery steps therefore depend on the type of policy that was deleted.
Intune audit logs record every create, update, delete, assign, and remote action. Microsoft enables auditing for all customers and admins cannot disable it. Intune retains audit logs of user and device actions for two years and deletes them automatically after that, so attribution stays available inside that window.
To find a deletion:
The Graph API returns up to two years of audit events, while the admin center's date filter offers a previous-year range, though some Microsoft community guidance cites 30 days of UI-visible history.
For long-term retention and Intune reporting that outlives those windows, teams can route audit logs to Azure Monitor. Supported destinations include Log Analytics workspaces and storage accounts. Event Hubs are also supported, and a storage account with retention set to 0 keeps data indefinitely.
Preventing a recurrence requires controls that keep one person from deleting a production policy without a second check.
Intune offers no recycle bin or native restore function for deleted policies. Microsoft's Entra recovery guidance is blunt about the equivalent situation: "Hard-deleted items need to be recreated and reconfigured. Avoiding unwanted hard deletions is best."
Your recovery paths for the policy itself come down to two options.
Intune audit logs record what changed and who changed it, and the Graph API auditEvents resource exposes modifiedProperties arrays containing the oldValue and newValue for each changed property. The recorded property values are not an importable policy payload. Rebuilding means reading property values one by one and re-entering them by hand, which is workable for a five-setting compliance policy and miserable for a settings catalog profile with dozens of configured values.
If something captured the policy before it disappeared, a real restore is possible:
Each recovery path needs preparation that happened before the delete button was clicked. Without it, you're reconstructing by hand from audit data, which makes the audit log your first stop either way.
The incident response should follow this order:
Microsoft ships several native controls that, combined with policy backup tools, reduce who can delete covered policies, require a second approver, and provide a recovery path:
Microsoft provides the native controls, and scheduled backups can rely on Graph-based tools. Teams assemble these guardrails by hand across separate admin surfaces. Intune management with Nerdio consolidates that work, because Nerdio Manager for Enterprise backs up Intune policies automatically and gives you a restore path after a deletion.
Nerdio Manager backs up Intune policies automatically and restores them after a deletion. Native Intune cannot. That one difference decides whether the morning after a deletion is a restore or a rebuild.
Backups run on a daily schedule or automatically when a policy is updated in Nerdio Manager. Versioning with rollback shows what changed and when, so policy drift becomes something you read rather than reconstruct. Nerdio's write-up on fixing Intune at scale works through the same failure mode from the other direction.
Intune policies govern laptops, Cloud PCs, and supported settings on Azure Virtual Desktop session hosts across Windows Cloud. Intune provisions and governs Windows 365 Cloud PCs directly.
Azure Virtual Desktop session hosts are stricter. Microsoft supports only a few templates there (trusted, SCEP, and PKCS certificate profiles, plus device tunnel VPN) and directs admins to the settings catalog for everything else, which makes pre-deletion JSON exports the import path that matters most on Intune multi-session hosts. One deleted baseline can hit physical endpoints and Windows Cloud at the same time, so a restore path has to cover both.
If you're a managed service provider (MSP) running Intune across client tenants, Nerdio Manager for MSP provides centralized policy management across customer environments.
A vanished policy can leave devices misconfigured and, in the compliance-policy case, weaken Conditional Access, so pre-deletion guardrails are essential. Get a demo to see how Nerdio Manager handles Intune policy backup and restore across your Windows 365 and Azure Virtual Desktop environment, or try it free in your Azure tenant.
No, Intune has no recycle bin or native restore for deleted policies. Audit logs record the old and new values of changed properties for up to two years via the Graph API, which supports manual reconstruction. A true restore requires a backup taken before the deletion. That can be a Settings Catalog JSON export, a Graph-based backup tool, or a platform like Nerdio Manager that backs up policies automatically.
Not reliably. Supported Wi-Fi and VPN profiles, along with certificate and email profiles, are removed from enrolled devices, and iOS/iPadOS removes all settings except three roaming settings. For settings not covered by those profile-specific rules, Android keeps the settings on the device. Windows behavior depends on each CSP. Some Windows CSPs keep the setting after deletion, a behavior Microsoft calls tattooing, and after a user is removed from an assigned group, removable settings can take up to 7 hours or more to clear.
You can open Tenant administration > Audit logs in the Intune admin center and filter by category and activity to find the delete audit entry, such as "Delete DeviceCompliancePolicy." The record includes the policy name and the "Initiated by" actor. Microsoft enables auditing for every tenant and admins cannot disable it, and Intune keeps these records for two years before deleting them automatically.
To rewrite tattooed Windows settings, assign a new policy with the intended value. Setting the policy to Not configured returns control of the setting to users when the policy applies.
Learn more about Nerdio Manager