Azure Security built-in role

Key Vault Reader

Reads Key Vault and object metadata for certificates, keys, and secrets without reading sensitive values such as secret contents or key material. It cannot change Key Vault objects or role assignments, but its control-plane Actions can create and manage classic metric alerts and support tickets. It works only with the Azure RBAC permission model.

Control-plane actions (9)

• Microsoft.Authorization/*/read
• Microsoft.Insights/alertRules/*
• Microsoft.Resources/subscriptions/resourceGroups/read
• Microsoft.Support/*
• Microsoft.KeyVault/checkNameAvailability/read
• Microsoft.KeyVault/deletedVaults/read
• Microsoft.KeyVault/locations/*/read
• Microsoft.KeyVault/vaults/*/read
• Microsoft.KeyVault/operations/read

Data-plane actions (2)

• Microsoft.KeyVault/vaults/*/read
• Microsoft.KeyVault/vaults/secrets/readMetadata/action

Excluded actions (0)

None

Assignable scopes (1)

• /

Practical scope

Assign at the individual vault for metadata inspection. Parent-scope assignments are inherited by child vaults and extend classic-alert and support-ticket authority across the parent scope. Microsoft recommends vault-per-application boundaries and generally recommends vault-level rather than individual-object role assignments.

Common use cases (2)

• Inventory key, secret, and certificate names, versions, attributes, tags, dates, and lifecycle metadata without reading protected contents.
• Monitor expiry, rotation, or configuration state for audit and support workflows that need no object changes.

Prerequisites (2)

• The vault must use Azure RBAC and the principal must not require secret values, private keys, or cryptographic operations.
• The assigning administrator needs Microsoft.Authorization/roleAssignments/write at the vault or parent scope.

Best practices (3)

• Use this role when the Key Vault data-plane requirement is metadata-only, and account for its ancillary classic-alert and support-ticket Actions at the chosen scope.
• Assign at one vault and maintain separate vaults by application and environment.
• Treat names, tags, versions, expiration dates, and object inventory as sensitive operational metadata and monitor access.

Security considerations (3)

• Metadata can reveal credential names, certificate subjects, key purpose, versions, expiration schedules, and application architecture.
• The role cannot read secret contents or key material and cannot perform cryptographic operations.
• A broad parent assignment exposes metadata for every inheriting vault and permits classic-alert and support-ticket changes even though protected values remain unavailable.

Assignment guidance

Assign Key Vault Reader on the specific vault for inventory, monitoring, or audit. Add Key Vault Secrets User, Certificate User, or a crypto role only when the principal has a separately approved need for protected content or operations.

Related roles (2)

• Key Vault Secrets User: Adds secret-content read access, including the secret portion of a certificate with a private key.
• Key Vault Certificate User: Adds complete certificate-content read access beyond metadata.

Editorial sources (6)

• 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.

• Grant permission to applications to access an Azure key vault using Azure RBAC →

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

• Secure your Azure Key Vault →

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

Official Microsoft Learn documentation →