A resource lock is an Azure protection that blocks deletion or modification of a resource even when a user has broad permissions. CanNotDelete and ReadOnly locks are used to protect critical infrastructure, backups, and recovery assets. If locks are removed first, attackers can then dismantle the remaining controls.
Expanded Definition
A resource lock is a cloud governance control that restricts destructive or mutating actions on a resource, even when an administrator or automation identity otherwise has sufficient permissions. In Azure, locks are typically applied as CanNotDelete or ReadOnly, which creates an additional protection layer above normal role assignments and helps preserve critical services, backups, and recovery components. This matters because a lock is not the same as access control: an identity may still authenticate and be authorised for the subscription, yet still be prevented from deleting or changing a locked object.
From a security operations perspective, the lock functions as a safeguard against both accident and abuse. It is especially relevant for recovery assets, logging infrastructure, key network resources, and any control plane object that would be costly to rebuild during an incident. Guidance varies across vendors on how to model immutable or semi-immutable infrastructure, but the core idea is consistent: make high-value resources harder to alter without an explicit, deliberate removal step. NIST’s NIST Cybersecurity Framework 2.0 aligns with this protective mindset through governance, access control, and resilience outcomes.
The most common misapplication is treating a resource lock as a substitute for least privilege, which occurs when teams rely on the lock while leaving overly broad permissions, weak approval workflows, or unmanaged privileged accounts in place.
Examples and Use Cases
Implementing resource locks rigorously often introduces change-management friction, requiring organisations to weigh operational resilience against the speed of legitimate maintenance and incident response.
- A backup vault is placed under a CanNotDelete lock so that a compromised administrator cannot remove recovery points before encrypting the production environment.
- A production network security group is set to ReadOnly during a stabilisation period, preventing accidental or malicious rule changes while an incident is being investigated.
- A subscription-level lock is used for a shared logging or monitoring workspace so defenders retain evidence even if other cloud resources are being tampered with.
- A disaster recovery storage account is locked to protect replication data, reducing the chance that a malicious actor can erase the fallback copy after gaining broad cloud access.
- A platform team removes a lock only through an approved workflow before making a planned infrastructure change, then reapplies it after validation.
For cloud and identity teams, the key use case is defending against high-privilege misuse, including compromised administrator accounts and automation identities that can otherwise operate far beyond intended scope. That is why resource locks are often paired with tightly governed privileged access and change approval controls. In operational terms, the lock should be treated as a resilience control rather than a stand-alone security boundary.
Why It Matters for Security Teams
Security teams care about resource locks because deletion resistance can preserve the very assets needed to recover from an attack. If attackers gain privileged access, they often try to remove backups, disable telemetry, or alter infrastructure before defenders can respond. A lock slows that path and creates an extra control point that must be consciously bypassed. That makes it valuable in cloud hardening, incident readiness, and segregation of duties, especially where administrator rights are broad but should not be unlimited.
The identity connection is important: resource locks are only effective when the identities that can remove them are tightly controlled, monitored, and reviewed. In practice, the lock becomes part of a layered model that combines authorization, approval, and operational restraint. It does not replace role design, privileged access review, or alerting on change events, and it should never be the only barrier protecting critical resources.
Organisations typically encounter the impact of resource locks only after a destructive change, deletion attempt, or ransomware-driven tampering event, at which point the lock becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Resource locks reinforce restricted access and limit destructive actions on protected assets. |
| NIST SP 800-53 Rev 5 | CM-5 | Configuration change restrictions align with preventing unauthorised modification of resources. |
| NIST Zero Trust (SP 800-207) | PL-5 | Zero trust design reinforces controlled, policy-based access to critical resources and changes. |
Use locks with least-privilege permissions so privileged users cannot alter critical resources without approval.
