Key vaults should have Role-Based Access Control (RBAC) enabled

Azure Key Vault should use the Azure RBAC permission model for data-plane access to keys, secrets, and certificates, rather than legacy access policies. Data access is managed through role assignments at the vault.

Control-plane Contributors can grant themselves data-plane rights, enabling secret or key exfiltration and unauthorized crypto operations. Without Azure RBAC, data access relies on coarse access policies.

What this control checks

Key vaults must have Role-Based Access Control (RBAC) enabled

Common pitfalls

Recovered vaults lose their role assignments

Role assignments disappear when a Key Vault has been deleted (soft- delete) and recovered. Afterwards it will be required to recreate all role assignments.

Missing enableRbacAuthorization is flagged

The policy flags a vault when enableRbacAuthorization does not exist or equals false.

Audit evidence

Evidence that deployed resources meet this control: Azure Policy compliance results for the built-in policy definition "Azure Key Vault should use RBAC permission model" (12d4fa5e-1f9f-4c21-97a9-b99b3c6611b5); Prowler check keyvault_rbac_enabled (prowler azure --checks keyvault_rbac_enabled); PowerPipe control azure_compliance.control.keyvault_rbac_enabled.

Framework-specific interpretation

PCI DSS v4.0: Mapped to 3.5.1.1 (Primary account number (PAN) is secured wherever it is stored.), 3.5.1.3 (Primary account number (PAN) is secured wherever it is stored.), 3.6.1 (Cryptographic keys used to protect stored account data are secured.) and 17 more clauses.

NIS2 Directive (EU 2022/2555): Mapped to 9.2.c (the relevant entities approach to key management, including, where appropriate, methods for the following:), 9.2.c.iv (storing keys, including how authorised users obtain access to keys;) and 9.2.c.v (changing or updating keys, including rules on when and how to change keys;).

Framework mappings

The clauses this control is mapped to in each framework.

PCI DSS v4.0

3.5.1.1: Primary account number (PAN) is secured wherever it is stored.
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
3.6.1: Cryptographic keys used to protect stored account data are secured.
3.6.1.2: Cryptographic keys used to protect stored account data are secured.
3.6.1.3: Cryptographic keys used to protect stored account data are secured.

15 more clauses

3.6.1.4: Cryptographic keys used to protect stored account data are secured.
3.7.1: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
3.7.2: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
3.7.4: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
3.7.6: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
3.7.7: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
7.2.1: Access to system components and data is appropriately defined and assigned.
7.2.2: Access to system components and data is appropriately defined and assigned.
7.2.3: Access to system components and data is appropriately defined and assigned.
7.2.5: Access to system components and data is appropriately defined and assigned.
7.3.1: Access to system components and data is managed via an access control system(s).
7.3.2: Access to system components and data is managed via an access control system(s).
7.3.3: Access to system components and data is managed via an access control system(s).
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
8.2.8: If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session

NIS2 Directive (EU 2022/2555)

9 Cryptography

CIS Azure Benchmark v4.0.0

9.3.6 Ensure that Role Based Access Control for Azure Key Vault is enabled

CIS Azure Benchmark v5.0.0

8.3.6 Ensure that Role Based Access Control for Azure Key Vault is enabled

RBI Cyber Security Framework for UCBs

Annex I (1.3)

BSI C5:2025

CRY-10.01AC For the secure storage of cryptographic keys, the cloud service provider uses a suitable software or hardware security module.
CRY-10.01B The cloud service provider has documented and implemented technical measures for the secure storage of cryptographic keys. This includes ensuring separation of the key management system from the application and middleware layers, defining how authorised users gain access and...
CRY-14.01B The cloud service provider has documented and implemented procedures to deactivate cryptographic keys once they expire. These procedures ensure that: - Expired keys are no longer used for encryption purposes, but may still be used for decryption if necessary;- Expired keys are no...
CRY-19.01B The cloud service provider implements procedures and technical safeguards to ensure the secure handling of cryptographic keys managed by cloud service customers. In these procedures, the following aspects are considered: - Secure integration of customer-managed keys into the cloud...
PSS-07.02B The cloud service provider distributes credentials using additional security mechanisms to verify the identity of the recipient (e.g. multi-factor authentication), validate the request and protect the credentials.

CIS Azure Benchmark v1.5.0