Defender for Cloud: Exemptions Not Persisting After Deletion — Reappear After Some Time

Andy Gibson - Admin 0 Reputation points
2026-09-10T10:54:14.96+00:00

I need this escalated to a human engineer with product knowledge of Microsoft Defender for Cloud and the Security Resource Provider specifically. The case summary I received does not reflect the diagnostic work already carried out, and I do not want another AI generated response repeating general Azure Policy troubleshooting steps that do not apply to this issue.

WHY GENERAL POLICY EXEMPTION TROUBLESHOOTING DOES NOT APPLY

An earlier response suggested az policy exemption commands and checking Microsoft.Authorization policyExemptions delete permissions. This does not apply. The resource type actually involved is Microsoft.Security standardAssignments, which is Defender for Cloud's own native exemption type, introduced with the January 2026 consolidated Exemptions view. This is a separate resource provider from Azure Policy exemptions, with no CLI equivalent. I confirmed this directly by capturing the browser network traffic behind the Environment Settings Exemptions page, which queries Azure Resource Graph specifically for type equals microsoft.security slash standardassignments. Our actual Azure Policy exemptions, 17 in total, confirmed via Get-AzPolicyExemption with the IncludeDescendent parameter, are correct and functioning normally. This issue is isolated to the Defender native exemption type.

THE ACTUAL ROOT CAUSE, NOW IDENTIFIED

The reappearing exemption count is not random or a simple caching delay. It is isolated almost entirely to two specific recommendations:

Guest accounts with read permissions on Azure resources should be removed Guest accounts with write permissions on Azure resources should be removed

The Defender for Cloud recommendations page shows these two recommendations with active resource counts of 367 and 35 respectively, both listed as type Subscriptions. Our tenant contains exactly 9 subscriptions in total. Every other recommendation in our environment shows accurate, sane active resource counts in the single or low double digits, matching the real number of affected resources.

This strongly indicates the underlying assessment data feeding these two specific recommendations is corrupted or duplicated at source, generating phantom subscription level findings at roughly 40 times the real count. We believe the exemption system is attempting to create and track one exemption per each of these duplicated phantom entries, which explains both the scale of the reappearing exemptions, approaching 300, and why this is isolated to only these two guest account recommendations rather than affecting exemptions generally across the tenant.

WHAT WE NEED

Please have an engineer investigate why the active resource count for these two specific recommendations is returning approximately 367 and 35 Subscriptions against a tenant with 9 real subscriptions, and whether this is the source of the exemption reappearance issue.

SEPARATE ISSUE ALSO STILL OPEN

Six Microsoft.Security standardAssignments records remain permanently undeletable. Their parent VM resources were deleted several months ago. These records are visible in the portal grid, are not returned by an Azure Resource Graph query against securityresources for this type, and return 404 Not Found when a DELETE is attempted directly via REST against their full resource ID, because the parent VM resource path in the scope no longer resolves. We need a supported method to remove these orphaned records, since the standard REST DELETE path cannot reach them.

Support request number 2609100050001040.

Microsoft Security | Microsoft Defender | Microsoft Defender for Cloud

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Konstantinos Lianos 830 Reputation points Student Ambassador
    2026-10-06T10:20:54.0466667+00:00

    Hello @Andy Gibson - Admin

    This looks related to the recent Defender for Cloud transition from grouped to individual recommendations, rather than a normal Azure Policy exemption issue.

    Microsoft specifically lists both recommendations you mentioned as deprecated:

    Guest accounts with read permissions on Azure resources should be removed Old ID: fde1c0c9-0fd2-4ecc-87b5-98956cbc1095 New ID: 422107c6-5b9a-46a6-bb1d-26ef1cc52d65

    Guest accounts with write permissions on Azure resources should be removed Old ID: 0354476c-a12a-4fcc-a79d-f0ab7ffffdbb New ID: 009678ce-adce-4c94-9cc8-cfc2bd0c6a06

    Microsoft also notes that during this transition the classic Defender views can show increased or unexpected resource counts, and that this doesn't necessarily represent the actual number of Azure resources. Existing governance, export, and exemption configurations should be updated to use the replacement assessment IDs.

    I would therefore first validate whether the ~367/35 entries belong to the old assessment IDs or the new ones before concluding that the assessment data itself is corrupted.

    Regarding the six orphaned Microsoft.Security/standardAssignments, your findings make sense. The documented DELETE API requires the original resource scope to still be addressable. If the parent VM no longer exists and both GET/DELETE return 404, I couldn't find a documented customer-side method to remove those orphaned records.

    For those six entries, opening/escalating the case to the Defender for Cloud / Microsoft.Security resource provider engineering team** for backend cleanup would be appropriate.

    If this answer helps, please mark it as Answered.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.