Secure Secrets and Keys with Azure Key Vault (SC-500)

Pick the service from three questions: do keys need hardware (HSM) protection, must the HSM be single-tenant with a customer-controlled security domain, and do you also need to store secrets and certificates? A Key Vault vault holds secrets, keys and certificates. Its Standard tier protects keys in software; its Premium tier adds HSM-protected keys on Microsoft's shared, multitenant HSMs and accepts bring your own key (BYOK) imports from an on-premises HSM. Azure Key Vault Managed HSM is a fully managed, single-tenant HSM pool: you activate it by downloading its security domain, which you, not Microsoft, then keep. Managed HSM stores keys only; it has no secret or certificate object types.

Azure Cloud HSM is a different product again: a single-tenant HSM cluster that you operate yourself at the infrastructure level. It does not plug into Azure services' customer-managed key (CMK) settings; Microsoft points CMK scenarios to Managed HSM.

When a workload needs both a single-tenant HSM for its encryption keys and somewhere to keep connection strings or API tokens, the minimum design is two services: a Managed HSM for the keys and a Key Vault vault (Standard is enough, because a secret is not an HSM key) for the secrets.

Microsoft's guidance is one vault per application per environment: it limits who can reach what, and it keeps a compromise of one app's identity from exposing another app's secrets.

Soft delete makes deleting a vault, or a key, secret or certificate inside it, recoverable for a retention period of 7 to 90 days (90 by default). Soft delete is always on for new vaults. The retention period is chosen when the vault is created and cannot be changed afterwards; to meet a different retention rule you create a new vault with the right value and move the objects into it. Azure Policy cannot change it either, because the service makes it immutable.

While a vault is soft-deleted its name stays reserved, so redeploying a vault with the same name fails. The fix is to recover the deleted vault (from the list of deleted vaults, or with the recover command), which brings back its keys, secrets, certificates, their versions and the vault's own properties in one operation. Purging releases the name but destroys the contents. Azure Backup does not back up a key vault as a resource, so there is no Recovery Services restore for a deleted vault.

What recovery does not restore: deleting a vault also deletes the services integrated with it. Microsoft names Azure RBAC role assignments and Event Grid subscriptions. After recovering a vault you must recreate both, or apps receive 403 errors and event-driven automation (for example a near-expiry function) silently stops.

Purge protection is an optional, irreversible setting: once enabled it can never be turned off. It does not stop deletion; it blocks the second, permanent step. A deleted vault or object stays in the soft-deleted state, recoverable, until the retention period ends, and no one can purge it early — not a Key Vault Purge Operator, not a subscription Owner. It uses the same retention interval chosen at creation; it does not force 90 days.

Services that encrypt data with a customer-managed key, such as Azure Storage, require the vault to have soft delete and purge protection, because losing the key makes the data unreadable.

Three vault switches let specific Azure platform services retrieve material from the vault on your behalf; each serves one scenario only:

For a template that references a secret (for example a SQL administrator password in a parameter file), two checks apply. The vault must have enabledForTemplateDeployment set, and the person or pipeline deploying must hold Microsoft.KeyVault/vaults/deploy/action on the vault's scope, so nobody can pull a secret merely by knowing the vault's resource ID. That permission grants the ability to deploy with the secret without granting read access to its value. Owner and Contributor include it; a custom role containing only that action keeps release engineers at least privilege.

These switches are permissions, not network rules. If the vault's firewall also blocks public traffic, the calling service must additionally be able to get through the firewall (see the trusted-services exception below).

Key Vault has two planes, and a role on one gives nothing on the other. The control plane (management plane) is Azure Resource Manager: creating and deleting vaults, changing tags, networking, the permission model and other vault properties. The data plane is the vault's own endpoint (https://<name>.vault.azure.net): listing, reading, creating and deleting keys, secrets and certificates, cryptographic operations, and recovering or purging deleted objects.

Key Vault Contributor is a control-plane role. On a vault that uses Azure RBAC it does not allow access to keys, secrets or certificates — a user with it can edit tags and network rules in the portal but gets an operation-not-allowed error on the Secrets page. It also lacks Microsoft.Authorization/roleAssignments/write, so it cannot grant itself a data role. Scope does not change this: a role assigned at a wider scope applies in more places but never gains actions it does not contain, and activating a role in PIM only makes its existing actions usable.

The two planes also log in different places. The subscription's Activity log records control-plane operations (vault updates, role assignments). Data-plane operations such as SecretGet or KeySign are recorded only in the vault's AuditEvent resource log, which is kept only when a diagnostic setting sends it to a Log Analytics workspace, storage account or event hub. To find out who read a secret, configure that diagnostic setting; adding Activity log categories never adds secret reads, and Key Vault publishes no Event Grid event for a read.

A vault authorizes data-plane access with one of two permission models, never both, and never split by object type. Azure RBAC (the recommended model) uses role assignments, which can be scoped to a management group, subscription, resource group, vault or an individual key, secret or certificate, and which work with PIM. Vault access policies (legacy) are a list of identities and permissions stored as a property of the vault.

The legacy model has a privilege-escalation path: access policies are a vault property, so anyone with Contributor (or Key Vault Contributor) on the vault's control plane can add an access policy for themselves and read every secret. Any fix that leaves data access defined by a vault property the Contributor can still write leaves that path open. Switching the vault to Azure RBAC does, because data access then requires a role assignment, which needs roleAssignments/write — a permission Contributor lacks.

Two behaviours to know when moving between models:

• Switching to Azure RBAC invalidates every access policy. Applications that relied on, say, a Get secret policy start receiving 403 Forbidden until an equivalent role (such as Key Vault Secrets User) is assigned. Assign the roles before you switch.
• The default changed. From Key Vault API version 2026-02-01, enableRbacAuthorization defaults to true when a vault is created, so a new vault uses Azure RBAC unless the template explicitly sets it to false. Existing vaults keep their current model, and no portal confirmation is involved.

Least privilege on an RBAC vault means choosing the narrowest built-in data role and the narrowest scope that still works. The roles that matter most:

Delegating access management. To let a team lead grant and remove access to their team's vault objects without being able to hand out other Azure roles, assign Key Vault Data Access Administrator. User Access Administrator and Role Based Access Control Administrator (without a condition you author yourself) can assign any role, including Owner. Key Vault Administrator sounds right but works with data and cannot assign roles.

Scope. Assign at the vault scope by default, with one vault per application. Microsoft discourages per-object assignments but lists a documented exception: a secret shared between applications. If another team's app must read exactly one secret from a vault holding many, assign Key Vault Secrets User on that secret alone; a vault-scope assignment would expose every secret.

Applications should authenticate with a managed identity (system- or user-assigned) rather than a stored client secret, which removes the last plaintext credential from the app. Managed HSM uses its own local RBAC with similar Crypto roles rather than Azure RBAC data roles.

The Key Vault firewall restricts which networks can reach the data plane. Public network access has three states: all networks, selected networks (only the rules below are admitted) and disabled (no public traffic except private endpoints and, while the bypass is on, the trusted Microsoft services described in the next section). The firewall does not filter control-plane calls through Azure Resource Manager.

• IP rules accept public IPv4 addresses and CIDR ranges only. Private (RFC 1918) ranges such as 10.0.0.0/8 are not valid, and service tags are not supported. On-premises callers that reach the vault through NAT appear as the NAT's public address, so that address is the rule to add.
• Virtual network rules admit specific Azure subnets that have the Microsoft.KeyVault service endpoint enabled. This is the way to admit VMs with private, dynamic addresses without a private endpoint. Traffic still goes to the vault's public endpoint; the service endpoint only carries the subnet's identity. It applies to traffic that originates in the subnet, not to on-premises traffic arriving over a VPN.
• A network security group rule on the client subnet controls what leaves that subnet; it does nothing to stop other networks reaching the vault.

The portal is a data-plane client too. When an administrator opens the vault in the portal, the vault's properties load (control plane), but listing keys, secrets or certificates is a data-plane call made from the administrator's browser. From a home IP that is not allowed, the list fails even though the role assignments are fine. The same machine's CLI calls fail the same way.

Private endpoints. A private endpoint (Azure Private Link) gives the vault a network interface with a private IP address in your virtual network. Combine it with public network access set to Disabled when clients must reach the vault only through private endpoints. Disabled does not switch off the trusted-services exception: services on that list can still reach the vault. For strictly private-only access, also turn the bypass off, or associate the vault with a Network Security Perimeter in Secure by perimeter mode, the one public-access mode that overrides the bypass. A service endpoint is the near-twin that does not keep traffic off the public endpoint: the vault keeps its public address.

DNS decides whether clients actually use the private endpoint. The vault's name (<name>.vault.azure.net) is a CNAME into privatelink.vaultcore.azure.net. Clients resolve it to the private IP only when a private DNS zone with exactly that name, holding the vault's A record, is linked to their virtual network. A zone named privatelink.vault.azure.net is never consulted. An approved connection on the endpoint proves only that the endpoint exists; check name resolution from the client itself to confirm the zone is linked. On-premises clients over VPN or ExpressRoute need their DNS servers to send vault.azure.net and vaultcore.azure.net lookups, through conditional forwarders, to a resolver that sees the private zone, such as Azure DNS Private Resolver; linking the zone to the hub VNet alone helps only resolvers inside Azure.

The Allow trusted Microsoft services to bypass this firewall exception lets a defined list of Azure services reach a vault whose public access is limited to selected networks, and it keeps working when public network access is Disabled; only Secure by perimeter mode or turning the exception off stops it. Services on the list include the Azure Resource Manager template deployment service (passing secure values from parameter files), Azure Storage and other services that use customer-managed keys, Azure Disk Encryption and Azure Backup. Two rules govern it:

• Bypassing the firewall is not authorization. A trusted service still needs permission: a role or access policy for its identity, or the matching vault access configuration switch.
• Services that run customer code are not trusted. Azure DevOps (Microsoft-hosted pipeline agents) and your own applications running on App Service or Functions are not on the list, because anyone can run code there.

For Microsoft-hosted Azure DevOps agents blocked by the firewall, the options are to allow the agents' published IP ranges (broad and shared with other customers) or, better, to run self-hosted agents in a virtual network the vault allows (or reach the vault through a private endpoint). Permissions and network reachability are separate checks: a caller must pass both, and fixing one never fixes the other.

A private endpoint helps clients in its virtual network; it does not give the Resource Manager deployment service a path. When a template deployment fails to fetch a secret after the vault was locked to selected networks with no exceptions, enabling the trusted-services bypass is the fix.

Keys rotate through rotation policies, secrets through SecretNearExpiry events and a function that changes the value at its source, and certificates through issuers and lifetime actions; each object type has its own tooling.

Keys: rotation policies

A key rotation policy makes Key Vault generate a new key version on a schedule. It has an expiry time for new versions and lifetime actions: Rotate (create a new version, triggered a period after creation or before expiry) and Notify (publish a near-expiry event; requires an expiry time). For zero-touch rotation, the consuming service must reference the key with a versionless key URI, so it moves to the newest version on its own (services can take up to a day or more to pick it up). A versioned URI pins the old version and needs a manual update.

Autorotation only works when Key Vault can generate the new material itself. For a key whose material is imported from an on-premises HSM, use the Notify action: it emits a KeyNearExpiry event through Event Grid, and a subscriber (an Azure Function or Logic App) runs the import workflow.

Secrets: event-driven rotation

Rotation policies apply to keys, not secrets. A secret such as a SQL password must also change at its source, which Key Vault cannot do. The pattern is: set an expiration date on the secret, subscribe to its SecretNearExpiry Event Grid event, and have a function generate a new password, apply it to the database and store it as a new secret version. An expiration date on its own is metadata — when it passes, the value simply becomes expired and no new version appears. Key Vault's Event Grid events include new versions, near expiry, expiry and access policy changes; there is no read event.

Certificates: issuers and lifetime actions

A certificate's policy sets its issuer and a lifetime action: AutoRenew or EmailContacts, triggered a number of days before expiry or at a percentage of lifetime.

Issuer integration exists only for the partnered CAs; an internal CA cannot be registered as an enrolling issuer. When policy says a private key must never leave the vault, create the certificate in the vault (it generates the key pair and a CSR carrying only the public key; the certificate stays pending), have the CA sign the CSR, and Merge Signed Request to complete it. Any workflow that generates the key pair outside the vault breaks the rule, and only the merge operation completes a pending certificate. For manually renewed certificates, add certificate contacts on the vault and an EmailContacts lifetime action so Key Vault emails the team before expiry.

Azure Policy has built-in definitions that audit keys, secrets and certificates (for example, requiring expiration dates or rotation policies); they report compliance but never rotate or renew anything (governance is covered in the Azure Policy lesson).

Defender for Cloud protects secrets in two directions: Microsoft Defender for Key Vault watches access to the vaults you have, and agentless secrets scanning finds secrets that are sitting outside any vault.

Defender for Key Vault

Defender for Key Vault is the threat-protection plan for vaults, enabled on the subscription. It analyzes vault access and raises alerts for unusual or potentially harmful activity — access from a suspicious IP address or a Tor exit node, an identity suddenly reading an unusual number of secrets, unusual applications or users — with no detection rules to write. Diagnostic logs in Log Analytics would need custom queries; Defender CSPM and Azure Policy look at configuration, not live access.

Microsoft's response to an alert: contact the owner of the identity to confirm whether the activity was legitimate, and never dismiss an alert just because the identity is familiar — stolen credentials of a known app look exactly like that. If it was not legitimate, restrict the vault firewall to trusted networks and resources, restrict or remove the identity's permissions, and rotate the secrets, keys and certificates that were accessed, then update the apps. Containment means cutting off access and replacing the exposed material; settings that hide alerts or protect against deletion do not contain a leak.

Secrets scanning with Defender CSPM

Agentless secrets scanning looks for plaintext credentials, such as connection strings, keys and tokens, in three places, and the plan you need depends on the place:

The free Foundational CSPM tier and Defender for Key Vault include no secrets scanning. Repository scanning needs both pieces: the Defender CSPM plan and the Azure DevOps (or GitHub) connector, because Defender for Cloud cannot see repositories that are not onboarded.

Remediating findings such as Machines should have secrets findings resolved: treat the exposed value as compromised, so rotate the credential, store the new value in Key Vault and have the app read it at runtime through a managed identity, then remove the plaintext. Until the plaintext is removed and the credential rotated, the finding describes a live exposure, whatever else is configured.