Skip to main content

Blog

Deleted compliance policies either lock everyone out or let every device in

Deleting a compliance policy feels like a configuration problem. With Conditional Access it is an access problem, and which kind depends on one tenant-wide setting that most admins set once and forget. Here is how it works, how to check your tenant in a minute and what to do in the first fifteen minutes.

By · Published · 5 min read

In short

  • Mark devices with no compliance policy assigned as decides how Intune treats devices without a compliance policy, including devices whose policies were just deleted.
  • Set to Not compliant, which Microsoft recommends with Conditional Access, deleted policies lead to blocked users as devices are evaluated again.
  • Set to Compliant, the default, deleted policies make the affected devices count as compliant without any rule being checked. Nobody calls the helpdesk.
  • In Microsoft Graph the setting is secureByDefault on /deviceManagement/settings. True means Not compliant.

The setting that decides

Intune has two layers of compliance. Device compliance policies are the rules you assign to groups. Compliance policy settings are tenant-wide and, in Microsoft's words, act like a built-in compliance policy that every device receives.

One of those tenant-wide settings is Mark devices with no compliance policy assigned as. It has two values:

  • Compliant, the default. Devices without a compliance policy are considered compliant.
  • Not compliant. Devices without a compliance policy are considered noncompliant.

Microsoft recommends Not compliant when you use Conditional Access, so that only devices confirmed as compliant reach your resources. That is good advice. It also changes what happens when compliance policies disappear.

What happens when the policies are gone

A device whose compliance policies were deleted no longer has a compliance policy assigned. From then on, the tenant setting decides its status as the device checks in and is evaluated again. It does not happen in the same second, but it does not wait for anyone to notice either.

Effect of deleted compliance policies, by tenant compliance setting
Tenant settingWhat devices becomeWhat users notice
Not compliantNoncompliantConditional Access policies that require a compliant device block email, Teams and other resources. Company Portal shows No compliance policies have been assigned.
Compliant (default)Compliant, with no rules checkedNothing. Devices that fail your encryption, OS version or Defender requirements keep their access.

The first case is loud: users are blocked and the helpdesk hears about it quickly. The second is silent, and silent is worse. Your Conditional Access policies still require a compliant device, but compliant no longer means anything. It can stay that way until someone opens the compliance report.

Check your tenant in a minute

In the Intune admin center, go to Endpoint security > Device compliance > Compliance policy settings. Or ask Microsoft Graph:

Microsoft Graph beta, read-only
GET https://graph.microsoft.com/beta/deviceManagement/settings

{
  "secureByDefault": false,
  ...
}

In the Graph reference, secureByDefault set to true means devices are noncompliant when no compliance policy targets them. My lab tenant still has the default, false.

While you are on that page, note the Compliance status validity period too. A device that does not report its compliance within that many days is treated as noncompliant. The default is 30 days.

Write both values down outside Intune. They are tenant settings, not policies, so a backup tool that only reads the policy lists misses them. They belong in the same offline kit as the items Microsoft Graph cannot back up.

TenuVault backs up Intune's tenant-wide compliance policy settings, including Mark devices with no compliance policy assigned as and the compliance status validity period. Drift detection flags changes to them, and a change to Mark devices with no compliance policy assigned as counts as critical. You can put the backed-up values back in place, and before anything is written you see each change and what it means for Conditional Access. In-place restore needs Pro or MSP. How the restore works.

The first fifteen minutes

  1. Confirm what happened. In the Intune admin center, open Tenant administration > Audit logs and filter for deletes. A deleted compliance policy appears as a Delete DeviceCompliancePolicy entry with the time and the account that made the change.
  2. Check the tenant setting. It tells you whether you are dealing with blocked users or with devices that count as compliant without being checked.
  3. Decide about the setting before you touch it. Switching Not compliant to Compliant gets blocked users back in, but it applies to every device without a compliance policy in the whole tenant. Make that call with whoever owns Conditional Access, write it down and set a time to switch it back.
  4. Recreate the policies from your most recent backup. Check that each restored policy has its actions for noncompliance, including the block action, and its assignments to the right groups.
  5. Let devices be evaluated again. Restored policies apply as devices check in. Users can speed this up with a sync or status check in Company Portal, and admins can sync a device from the admin center.
  6. No backup? Rebuild from what you know. Intune audit logs show which properties changed, but they do not hold the full policy. Your own documentation, an old export or a similar tenant is the fastest source.

The guide to restoring a deleted Intune policy covers the restore itself step by step, including new object IDs and group references.

Make the next time boring

  • Back up compliance policies with their actions for noncompliance, not only the rule settings. A backup without the block action cannot recreate the policy as it was.
  • Record the tenant compliance settings, including the validity period, and the Conditional Access policies that require a compliant device.
  • Limit who can delete compliance policies with Intune roles and scope tags, and review the audit log for deletes.
  • Practice the restore once in a test tenant, so the first time is not during an outage. The restore drill guide shows how.

Related reading

More posts on the TenuVault blog