Skip to main content

G2 Names Nerdio a Leader Across Fall 2026 Reports for Desktop as a Service Read the blog

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.

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.

What happens on devices when an Intune policy is deleted

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.

Why a deleted compliance policy is the highest-stakes case

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:

  • Security baselines don't reverse themselves. Per Microsoft Learn: "When a setting is no longer managed by a baseline profile, that setting doesn't reset on the device."
  • App protection policies don't themselves trigger a selective wipe when deleted. Admins initiate a selective wipe request separately in the admin center. Protection simply goes inactive for unassigned users, with a 12-hour retry interval on policy delivery timing.
  • Enrollment restrictions are the forgiving case. Intune ships one default policy per restriction type and applies it to all user and userless enrollments until a higher-priority policy is assigned, so deleting a custom restriction drops enrollments back to that default. Restrictions also only evaluate at enrollment.

The right recovery steps therefore depend on the type of policy that was deleted.

How to find out who deleted the policy

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:

  1. Sign in to the Microsoft Intune admin center and go to Tenant administration > Audit logs.
  2. Filter by Date, then Add filters > Category (Compliance, Device, and so on) and Apply.
  3. Add an Activity filter if you want to narrow to deletes specifically.
  4. Look for a delete audit entry such as "Delete DeviceCompliancePolicy," which includes the deleted policy's name. The "Initiated by" field shows who ran the action and where.

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.

Recovery options without a recycle bin

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.

Reconstructing from audit logs

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.

Restoring from a backup made before the deletion

If something captured the policy before it disappeared, a real restore is possible:

  • Settings Catalog JSON export
    The admin center natively exports Windows settings catalog policies as .json files (Devices > Manage devices > Configuration, then Export JSON from the ellipsis menu) and can import them to create a new policy. This only works if you exported before the deletion.
  • Graph API scripting
    You can recreate policies by POSTing JSON to the appropriate Graph endpoint; Microsoft's PowerShell samples repository demonstrates the export and import patterns by workload.
  • Open-source tooling
    The IntuneCD project (Python, pipeline-driven backups with change history), IntuneManagement project (PowerShell export/import including assignments), Microsoft365DSC project (tenant configuration snapshots with drift monitoring), and the IntuneBackupAndRestore module all support restoring from prior backups.

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.

Your first hour after an Intune policy deletion

The incident response should follow this order:

  1. Pull the audit log entry. Identify the policy and the timestamp. Then check the "Initiated by" actor. Query Graph auditEvents data for the modifiedProperties old values to use as rebuild material if no backup exists.
  2. If it was a compliance policy, check the tenant fallback immediately. If "Mark devices with no compliance policy assigned as" still reads Compliant, your Conditional Access policies are trusting a compliance state nothing is evaluating. Change the fallback to Not compliant before rebuilding anything.
  3. Establish what actually changed on devices. Reporting reflects the deletion only after devices sync, so a clean-looking console early on tells you nothing. Sync a representative device from each affected platform and check the settings the policy governed.
  4. Recreate the policy. Use an available backup or JSON export. If neither exists, rebuild the policy from the audit log property values.
  5. Handle tattooed settings deliberately. On Windows, deploy a new policy that explicitly sets every affected value and assign it to the impacted devices.
  6. Add the missing guardrail. Turn on automated policy backups, enable Multi Admin Approval for configuration and compliance policies, and strip the Delete permission from day-to-day roles.

Preventing the next accidental deletion

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:

  • Custom RBAC roles
    Intune permissions break down into discrete actions including Delete. Custom roles that withhold the Delete action on Device configurations keep routine operators out of destructive territory. Microsoft's own RBAC guidance: "Don't use the Intune Administrator role for day-to-day Intune administration."
  • Scope tags
    Roles control what actions an admin can take; scope tags control which objects they can see. Merge behavior is where this goes wrong. An admin in multiple role assignments with different scope tags gets merged permissions, which can grant broader access than intended.
  • Multi Admin Approval
    MAA access policies can protect device compliance policies and device configuration policies created through the settings catalog, an expansion Microsoft announced in February. With a policy in place, creating, editing, or deleting a covered resource requires a second administrator's approval, and the requesting admin enters a business justification that becomes part of the approval request.
  • Privileged Identity Management
    PIM provides time-bound, approval-gated elevation for destructive roles like Intune Administrator. It requires a Microsoft Entra ID P2 or Microsoft Entra ID Governance license.
  • Scheduled policy backups
    Graph-based tools such as IntuneCD run in a pipeline, so teams keep current exports of Intune policies without anyone remembering to click Export JSON.
  • Drift detection
    Microsoft Entra tenant governance can capture configuration as code across 200+ resource types and scan for drift every six hours.

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.

How Nerdio Manager backs up and restores Intune policies

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.

Automated backups and rollback

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.

Coverage across Windows Cloud environments

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.

Multi-tenant policy management for MSPs

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.

Frequently asked questions about what happens when a Microsoft Intune policy is deleted

Ready to get started?