Back to controls

Enable Role Based Access Control for Azure Key Vaults

The recommended way to access Key Vaults is to use the Azure Role-Based Access Control (RBAC) permissions model.

Category

Controls

Medium

Applies to

Microsoft Azure

Coverage

null controls, 1 queries

Asset types

1 covered

Overview

The recommended way to access Key Vaults is to use the Azure Role-Based Access Control (RBAC) permissions model.

Azure RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources. It allows users to manage Key, Secret, and Certificate permissions. It provides one place to manage all permissions across all key vaults.

Rationale

The new RBAC permissions model for Key Vaults enables a much finer-grained access control for key vault secrets, keys, certificates, etc., than the vault access policy. This, in turn, will permit the use of privileged identity management over these roles, thus securing the key vaults with JIT Access management.

Impact

Implementation needs to be properly designed from the ground up, as this is a fundamental change to how key vaults are accessed/managed. Changing permissions to key vaults will result in a loss of service as permissions are re-applied. For the least downtime, map your current groups and users to their corresponding permission needs.

Remediation guidance

Remediate from Azure Portal

Key Vaults can be configured to use Azure role-based access control on creation.

For existing Key Vaults:

  1. Open the Key Vault using the Open in Azure button.
  2. Select Access configuration
  3. Set the Permission model radio button to Azure role-based access control, taking note of the warning message
  4. Click Save
  5. Select Access Control (IAM)
  6. Select the Role Assignments tab
  7. Reapply permissions as needed to groups or users

Remediate from Azure CLI

To enable RBAC Authorization for each Key Vault, run the following Azure CLI command:

az keyvault update --resource-group <resource_group> --name <vault_name> --enable-rbac-authorization true

Remediate from PowerShell

To enable RBAC authorization on each Key Vault, run the following PowerShell command:

Update-AzKeyVault -ResourceGroupName <resource_group> -VaultName <vault_name> -EnableRbacAuthorization $True

Multiple Remediation Paths

Azure

SERVICE-WIDE (RECOMMENDED when many resources are affected): Assign Azure Policy initiatives at management group/subscription scope and trigger remediation tasks.

az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>

ASSET-LEVEL: Apply the resource-specific remediation steps above to the listed non-compliant resources.

PREVENTIVE: Embed Azure Policy checks into landing zones and IaC workflows to block or auto-remediate drift.

References for Service-Wide Patterns

  • Azure Policy overview: https://learn.microsoft.com/en-us/azure/governance/policy/overview
  • Azure Policy remediation: https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources
  • Azure Policy initiative structure: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/initiative-definition-structure

Operational Rollout Workflow

Use this sequence to reduce risk and avoid repeated drift.

1. Contain at Service-Wide Scope First (Recommended)

  • Azure: assign policy initiatives at management group/subscription scope and run remediation tasks.
az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>

2. Remediate Existing Affected Assets

  • Execute the control-specific Console/CLI steps documented above for each flagged resource.
  • Prioritize internet-exposed and production assets first.

3. Validate and Prevent Recurrence

  • Re-scan after each remediation batch.
  • Track exceptions with owner and expiry date.
  • Add preventive checks in IaC/CI pipelines.

Query logic

These are the stored checks tied to this control.

Azure key vaults not using RBAC

Connectors

Microsoft Azure

Covered asset types

KMSVault

Expected check: eq []

{
  kmsVaults(where: { enableRbacAuthorization: false }) {
    ...AssetFragment
  }
}
Cyscale Logo
Cyscale is an agentless cloud-native application protection platform (CNAPP) that automates the contextual analysis of cloud misconfigurations, vulnerabilities, access, and data, to provide an accurate and actionable assessment of risk.

Stay connected

Receive new blog posts and product updates from Cyscale

By clicking Subscribe, I agree to Cyscale’s Privacy Policy


© 2026 Cyscale Limited

LinkedIn icon
Twitter icon
Facebook icon
crunch base icon
angel icon