# Use Azure resource locks as a deletion guard—not a backup or permission boundary > Azure resource locks can block deletion or modification at management scope and inherit to child resources, but authorized users can remove locks and data-plane operations may not be affected. - Canonical URL: https://update.dsesecurity.com/updates/azure-resource-lock-deletion-guard-boundaries/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:59+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Azure resource locks can block deletion or modification at management scope and inherit to child resources, but authorized users can remove locks and data-plane operations may not be affected. ## Potentially affected Azure subscriptions, resource groups, and resources where accidental management-plane deletion or modification would cause material disruption. ## DSE recommendation Apply CanNotDelete selectively to critical resources, control lock-management permissions, test deployment and recovery workflows, and retain independent backup and data-plane controls. ## Article Bottom line: Azure Resource Manager locks can prevent deletion or make a resource read-only at the management plane. Locks inherit from a parent scope, and the most restrictive applicable lock controls the resource. They are guardrails against authorized management mistakes, not backups, immutable security boundaries, or universal blocks on data operations. ## Source fact: what Microsoft documents Microsoft’s [resource-lock documentation](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources) defines two levels. CanNotDelete permits authorized updates but blocks deletion. ReadOnly permits reads but blocks updates and deletion. Locks can be assigned at subscription, resource-group, or resource scope and inherited by child resources. Microsoft distinguishes lock behavior from Azure RBAC. A user may have permission to modify a resource but still be blocked by a lock; a user with appropriate lock-management permission can remove the lock. The page documents that locks apply to control-plane operations sent to Azure Resource Manager and may not block data-plane operations. It also lists resource-specific consequences: read-only locks can disrupt operations that use control-plane writes even when the action sounds observational or operational. ## What the source does not establish A lock does not create a recoverable copy, stop data deletion through every service API, prevent compromise by someone who can remove the lock, or make an application available. A lock at the wrong scope can block deployments, scaling, secret rotation, backup configuration, monitoring, or legitimate incident response. The presence of a lock does not prove that protected data is immutable. ## Applicability questions - Is the concern accidental resource deletion, unintended configuration change, data deletion, or all three? - Which operations use the Azure control plane versus the service’s data plane? - Should the lock be at resource, resource-group, or subscription scope, and what unrelated children inherit it? - Who can create or remove locks and who approves temporary removal? - Which deployment, backup, autoscale, monitoring, rotation, and incident workflows perform blocked writes? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Select critical resources whose accidental deletion has material consequence and prefer CanNotDelete unless a tested need justifies ReadOnly. - Apply at the narrowest useful scope and inventory inherited resources before creation. - Restrict lock-management permissions and require a ticket, approver, purpose, and short window for removal. - Test infrastructure deployment, maintenance, backup, monitoring, scaling, rotation, and recovery with the lock present. - Keep independent backup, immutability, data authorization, and recovery controls for the relevant service. ## Verification and evidence - Preserve lock name, level, scope, inheritance, owner, rationale, and approval. - Demonstrate an authorized deletion is blocked and an expected allowed update still succeeds for CanNotDelete. - Record data-plane tests separately; do not infer their result from a management-plane rejection. - Audit lock creation and removal and alert on unplanned changes at critical scopes. ## Official references - [Lock your Azure resources to protect your infrastructure](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources) — Microsoft ## Primary reference - Name: Lock your Azure resources to protect your infrastructure - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Use Azure resource locks as a deletion guard—not a backup or permission boundary,” DSE Security, https://update.dsesecurity.com/updates/azure-resource-lock-deletion-guard-boundaries/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.