Azure Security built-in role

Locks Contributor

Reads, creates, updates, and deletes Azure management locks. A lock can impose CanNotDelete or ReadOnly restrictions that override the permissions of users and roles, but locks apply only to Azure control-plane operations and do not protect or restrict data-plane operations.

Control-plane actions (3)

• Microsoft.Authorization/locks/read
• Microsoft.Authorization/locks/write
• Microsoft.Authorization/locks/delete

Data-plane actions (0)

None — this role grants no data-plane (data access) actions.

Excluded actions (0)

None

Assignable scopes (1)

• /

Practical scope

Locks can be applied to a subscription, resource group, or individual resource, not to a management group. A parent lock is inherited by existing and future child resources, and the most restrictive lock in the inheritance chain takes precedence. Assign this role only at the boundary whose locks the principal is authorized to control.

Common use cases (2)

• Apply CanNotDelete locks to critical subscriptions, resource groups, or resources to prevent accidental deletion.
• Maintain or remove management locks during a reviewed deployment, migration, recovery, or decommissioning workflow.

Prerequisites (3)

• Identify the exact resource hierarchy and choose CanNotDelete or ReadOnly after reviewing service-specific side effects.
• Document the lock owner, purpose, notes, removal approval, and operational break-glass procedure.
• The assigning administrator needs Microsoft.Authorization/roleAssignments/write at the scope where Locks Contributor is assigned.

Best practices (3)

• Prefer CanNotDelete when the requirement is deletion protection; use ReadOnly only after testing every required POST and control-plane operation.
• Assign directly at the protected boundary and separate lock administration from routine resource administration.
• Review inherited and extension-resource effects before applying or removing a parent lock and automate lock deployment through reviewed infrastructure code where practical.

Security considerations (3)

• Deleting a lock removes a protection that overrides ordinary RBAC permissions and can expose critical resources to deletion or modification.
• ReadOnly locks can block operations that appear non-mutating, including POST-based key listing, VM start or restart, role assignment, and some service automation.
• Locks do not protect blob, database, or other service data when the request uses a data-plane endpoint.

Assignment guidance

Assign Locks Contributor to a small governance or platform group at the subscription, resource group, or resource boundary it protects. Require change approval for lock removal, test service behavior before ReadOnly locks, and never describe a management lock as a data-protection control.

Editorial sources (5)

• Azure built-in roles for Security →

  Supports: Description, Security considerations. Retrieved 2026-07-16.

• Steps to assign an Azure role →

  Supports: Prerequisites, Assignment guidance. Retrieved 2026-07-16.

• Understand scope for Azure RBAC →

  Supports: Practical scope, Best practices, Assignment guidance. Retrieved 2026-07-16.

• Best practices for Azure RBAC →

  Supports: Best practices, Assignment guidance. Retrieved 2026-07-16.

• Lock your Azure resources to protect your infrastructure →

  Supports: Practical scope, Common use cases, Prerequisites, Best practices, Security considerations, Assignment guidance. Retrieved 2026-07-16.

Official Microsoft Learn documentation →