Secure secrets and keys by using Azure Key Vault

A production connection string parked in an App Service application setting is one copy-paste away from a source-control commit and one screenshot away from a support ticket. Move that value into Azure Key Vault and the application stops carrying it at all: at startup it presents an identity of its own and asks the vault for the current value (Key Vault overview^[1]). Everything else on this page follows from that move, because once a value lives in a vault you own decisions about who may read it, from where, how it ages, and what tells you somebody tried.

The previous page in this domain covers the caller: Privileged Identity Management, conditional access, authentication methods, and the managed identity an Azure resource uses to prove who it is. This page covers the vault on the other side of that call. The governance page that follows describes the controls sitting above any single resource, such as Azure Policy definitions, resource locks, and role assignments across a subscription.

The three object types

A vault stores three kinds of object, and they differ in permission and in lifecycle, so the distinction is worth pinning down before anything else. A key is cryptographic key material that the vault uses on your behalf for operations such as wrap, unwrap, and sign, so the private material stays inside the service. Wrapping is worth naming here because a later section reasons about it: it means encrypting another key rather than data, and the key being wrapped is what that section calls a data encryption key. A secret is any value you hand the vault to store and read back later, typically a password, a connection string, or an API key. A certificate is a managed X.509 certificate that the vault builds from a certificate policy, and the vault also exposes that certificate's key material as a key and its exportable form as a secret of the same name (keys, secrets, and certificates^[2]).

Two things stay out of a vault. Customer content belongs in a data service such as Azure Storage or Azure Cosmos DB, and ordinary non-sensitive configuration belongs in a configuration store. A vault is a small, heavily governed store rather than a general-purpose one, and its transaction limits are sized accordingly (Key Vault service limits^[3]).

Five decisions, in the order this page takes them

Putting an object in a vault raises five decisions, and the figure below names each one with the question it answers: the vault boundary (which vault holds this material, and what survives a delete), authorization (which plane, which role, at which scope), network reach (from where a data-plane call may arrive), object lifecycle (what creates the next version), and detection (what signals that an attempt went wrong). Those five names are used unchanged for the rest of the page.

Read that order as a dependency rather than a list. The boundary decision constrains every decision after it, because role assignments, firewall rules, diagnostic settings, and alerts all attach to a vault and not to an individual secret. Draw the boundary carelessly and no later control undoes it.

One vault per application per environment, with roles assigned at the vault scope, is the shape Microsoft recommends (Azure RBAC for Key Vault^[4]). The reason is mechanical: several controls attach to the vault, so a firewall rule, a diagnostic setting, and a Defender alert are scoped to the vault, and two applications sharing one vault share those decisions. Development, test, and production get separate vaults for the same reason, as do separate regions when their security boundaries differ, and a multitenant service selects its vault model according to the level of isolation it needs.

Naming is not isolating. A shared vault whose secrets are told apart only by a name prefix, prod-sql-conn beside dev-sql-conn, still hands both values to every holder of a vault-scoped role, because the role is scoped to the vault and nothing in the name changes that.

Deleting, then destroying

Removing vault content permanently takes two operations rather than one (Key Vault soft delete^[5]). The first, delete, moves the vault or object into a deleted state where it is still recoverable. The second, purge, permanently removes it. Soft delete is on by default when you create a vault and cannot be turned off once enabled; the retention period is chosen at creation, anywhere from 7 to 90 days, defaults to 90, and cannot be changed afterwards. The same interval governs both soft delete and purge protection. While an object or vault sits in the deleted state its name cannot be reused in that location, which is why a redeploy under the old name fails until retention expires or the old object is purged.

Purging is deliberately privileged: in general only the subscription owner or a principal holding the Key Vault Purge Operator role can do it. Purge protection is the step beyond that. It is off by default, requires soft delete to be on, and blocks the purge outright until the retention period passes. It is also a one-way door: on the ARM resource, enablePurgeProtection "does not accept false as its value" once enabled (Microsoft.KeyVault/vaults reference^[6]). Most Azure services that encrypt data with a customer-managed key held in Key Vault require purge protection, because purging that key destroys the data it protects. The figure below traces one object from active through the deleted state to recovery, to a purge, or to a purge the protection blocks.

Two neighbouring controls get mistaken for this one. A resource lock stops a delete operation from succeeding; it restores nothing afterwards, so it is a prevention control and never a recovery mechanism. Key Vault backup is a genuinely separate control: it exports an individual key, secret, or certificate so it can be restored into a key vault in the same subscription and Azure geography (Key Vault backup^[7]). Use it for objects that cannot be recreated from another source, and restore a test copy occasionally, because an untested restore is a hope rather than a control.

One consequence catches teams out during a recovery exercise. When a key vault is soft-deleted, the services integrated with it are deleted as well, including its Azure RBAC role assignments and its Event Grid subscriptions, and recovering the vault does not restore them. They have to be recreated by hand after the recovery.

So the boundary decides who is affected by an incident, and the deletion settings decide whether the incident is survivable. Both are set at vault creation and are awkward or impossible to change later, which is what makes them design decisions rather than operational ones.

Key Vault Contributor lets a person create vaults, tag them, and configure their networking, and gives that person no way to read a single secret. That is not a quirk of one role definition. Key Vault exposes two interfaces whose access controls work independently (Key Vault access model^[4]). The control plane, reached at management.azure.com, creates, reads, updates, and deletes vaults and sets their properties. The data plane, reached at the vault's own <vault-name>.vault.azure.net endpoint, performs operations on keys, secrets, and certificates. Both planes authenticate the caller with Microsoft Entra ID, and Microsoft states directly that Key Vault Contributor "is for control plane operations only ... It does not allow access to keys, secrets and certificates". The request path through both planes is drawn in the network section below, where the third gate is this same data-plane authorization.

The gap runs the other way too, and that direction is the dangerous one. On a vault still using legacy access policies, a principal holding control-plane Contributor "can grant themselves access to the data plane by setting a Key Vault access policy". Control-plane rights on such a vault are therefore data-plane rights one short step removed, which is the reason to control those control-plane roles tightly and to prefer the RBAC model described next.

One authorization model at a time

A vault runs exactly one data-plane authorization model, selected by its enableRbacAuthorization property: Azure RBAC (role-based access control), or the legacy vault access policies. Whichever model is not selected is ignored, so adding an access policy to an RBAC vault changes nothing and repairs nothing, and this is the single most common wrong answer in Key Vault access questions. Starting with API version 2026-02-01, Azure RBAC is the default model for newly created vaults; existing vaults keep the model they already have (Key Vault access control default^[8]). Switching an existing vault to the RBAC model invalidates all of its access-policy permissions, so the equivalent role assignments must be in place before the switch or callers start failing.

Pick the role by object type

These are the built-in roles you meet most often, among others in the full list. Each one is a data-plane role except the last, and each works only on a vault using the Azure RBAC permission model.

Role	What it grants	Typical holder
Key Vault Secrets User	Read secret contents, including the secret portion of a certificate with its private key	An application's managed identity
Key Vault Secrets Officer	Any action on secrets except managing permissions	A rotation function that writes new versions
Key Vault Crypto User	Perform cryptographic operations using keys	A workload that wraps and unwraps data encryption keys
Key Vault Crypto Officer	Any action on keys except managing permissions	An operator who sets rotation policies
Key Vault Certificates Officer	Any action on certificates except managing permissions	A certificate administrator
Key Vault Administrator	All data-plane operations on the vault and every object in it, but no management of the vault resource or of role assignments	A break-glass operator
Key Vault Reader	Read metadata of the vault and its objects, never a secret value or key material	An auditor
Key Vault Purge Operator	Permanently delete soft-deleted vaults	A cleanup process, rarely a standing assignment
Key Vault Contributor	Control plane only: create and configure vaults, with no access to keys, secrets, or certificates	A platform team

Roles can be assigned at management group, subscription, resource group, vault, or individual object scope. Vault scope is the working default, and Microsoft answers the isolation question directly in the RBAC guide's FAQ: object-scope assignments are not a way to give application teams their own slice of a shared vault, because "any administrative operations like network access control, monitoring, and objects management require vault level permissions". Object scope exists for the narrow cases the same guide names, such as one user reading their own SSH private key, or one secret deliberately shared between two applications.

The workload's own identity

An Azure workload should reach a vault as a managed identity, an identity that Azure creates for the resource and whose credentials Azure manages, so nothing has to store a password or certificate (managed identities for Azure resources^[9]). Two conditions have to hold and they are independent: the identity must be enabled on the resource, and that identity must hold a data-plane role assignment on the vault. Being inside the right virtual network, or reaching the vault through a private endpoint, satisfies neither condition, because network position is not an identity.

Role changes are not instant from a running workload's point of view. Azure caches managed identity tokens, so a change to the identity's group or role membership can take several hours to be reflected in what a long-lived process can do (managed identities FAQ^[10]). Treat a role change like a deployment with a propagation window, not like a switch that flips.

The takeaway is a habit: for any Key Vault access question, name the plane first, then the model, then the role, then the scope. A wrong answer usually sits at exactly one of those four steps.

A vault created with the default network settings accepts requests from any network, and that is not the same as accepting operations from anyone. Microsoft puts it plainly: with the Key Vault firewall disabled, all applications and Azure services can send requests, and the vault "still restricts access to secrets, keys, and certificates stored in key vault by requiring Microsoft Entra authentication and access policy permissions" (configure network security for Key Vault^[11]). Read that last phrase through whichever model the vault runs, since it runs only one: on an RBAC vault the equivalent gate is the data-plane role assignment from the previous section, not an access policy. Network reach and authorization are gates in series, three of them once authentication and the role check are counted apart. The figure below walks one data-plane request through all three: the vault's network rules admit the source, Microsoft Entra ID authenticates the caller, and the data-plane role assignment permits the operation. Failing any single gate refuses the request.

One contrast is worth making before the mechanics, because the sibling page on Azure network services teaches a different evaluation model with the same vocabulary. A network security group evaluates rules in priority order and stops at the first match. The Key Vault firewall does not: when it is enabled with the default action set to Deny, it is an allowlist, so a source that matches no rule is denied without any ordering to reason about.

Three configurations, then two exceptions

The three configurations are alternatives on one axis, so pick one; the two exceptions layer on top of the choice.

All networks is the default. The firewall is disabled and any client that can reach the public endpoint may send a request, which is acceptable only while both other gates are tight.

Selected networks lists the sources allowed to reach the public endpoint and sets the default action to Deny. Two rule kinds exist. An IP rule takes an IPv4 address or CIDR range, which must be public: RFC 1918 private ranges are rejected and only IPv4 is supported at this time. A virtual network rule takes a subnet, and it works only when the Microsoft.KeyVault service endpoint is enabled on that subnet, so a network security group rule that permits outbound HTTPS does nothing to place the subnet on the vault's allowlist. Capacity is a maximum of 200 virtual network rules and 1,000 IPv4 rules per vault.

Public access disabled leaves private endpoints as the only way in. Create the private endpoint, integrate name resolution with the privatelink.vaultcore.azure.net private DNS zone, and then set public network access to Disabled (integrate Key Vault with Azure Private Link^[12]). Creating the private endpoint does not close the public endpoint by itself; disabling public access is the separate setting that does. The vault's public DNS name keeps resolving afterwards, by design, because that is how the Private Link DNS overlay works for every Azure PaaS service, and the public ingress it resolves to refuses every request.

The first exception is the trusted Microsoft services bypass. It admits only the services on the documented trusted-services list, and services absent from that table are blocked whether or not the bypass is enabled; Azure DevOps is the example Microsoft names, because customers can run their own code there (virtual network service endpoints for Key Vault^[13]). The bypass keeps applying when public network access is set to Disabled, so a trusted service does not need a private endpoint to reach the vault.

The second exception is a Network Security Perimeter, a logical isolation boundary around PaaS resources deployed outside your virtual networks (Network Security Perimeter^[14]). Private endpoint traffic is not subject to perimeter rules; all other traffic, trusted services included, is. Two settings are in play here and they are easy to confuse. The first is the perimeter's own access mode: in Transition mode the vault's publicNetworkAccess setting still controls public access and the perimeter only logs what it would have denied, while in Enforced mode the perimeter rules override that setting. The second is that same publicNetworkAccess setting on the vault, and Secure by perimeter is the value of it that turns the trusted-services bypass off, forbidding trusted services even when the bypass is configured.

Allowing one subnet through the firewall

The order matters more than the syntax here, because the service endpoint is a property of the subnet and the rule is a property of the vault.

# 1. Put the Key Vault service endpoint on the subnet. The vault firewall can
#    recognise a subnet only when this endpoint is present.
az network vnet subnet update --resource-group "myresourcegroup" \
  --vnet-name "myvnet" --name "mysubnet" --service-endpoints "Microsoft.KeyVault"

# 2. Add that subnet as a virtual network rule on the vault.
subnetid=$(az network vnet subnet show --resource-group "myresourcegroup" \
  --vnet-name "myvnet" --name "mysubnet" --query id --output tsv)
az keyvault network-rule add --resource-group "myresourcegroup" \
  --name "mykeyvault" --subnet $subnetid

# 3. Deny whatever the rules do not admit. Until this runs the firewall is
#    still open. (IP-range rules and the trusted-services bypass omitted: ...)
az keyvault update --resource-group "myresourcegroup" --name "mykeyvault" \
  --default-action Deny

Step 3 is the one that gets skipped. Adding rules while the default action stays at Allow documents an intention without enforcing anything, so --default-action Deny is what turns the list into a firewall.

Two boundaries on all of this. Key Vault firewall rules apply to data-plane operations only, so control-plane calls through Azure Resource Manager are not filtered by them, including secrets deployed through an ARM template, which reach management.azure.com rather than the vault's data-plane endpoint. And once rules are in effect they apply to humans as well: a user can still browse to the vault in the Azure portal, but listing keys, secrets, or certificates fails when their client machine is not on the allowlist, which is a support ticket waiting to happen unless the operations team's addresses are allowed too.

Key Vault never overwrites material. Every write creates a new version, and an object identifier either names a version or omits it; omitting the version segment gives the base identifier, and Microsoft describes retrieval that way as getting "the latest version of the object" (keys, secrets, and certificates^[2]). That is the mechanism under every rotation story here: rotation adds a version, and consumers either follow the versionless identifier or pin a version deliberately.

The three object types automate the next version differently, and the figure below sets the three paths side by side.

Keys

A rotation policy on a key generates a new version automatically at a configured interval, with a documented minimum of seven days, and can raise a near-expiry notification through Event Grid; rotation on demand is available alongside the schedule (configure key autorotation^[15]). Azure services that encrypt with a customer-managed key use the newest version for new operations while keeping access to earlier versions for data already protected (autorotation in Key Vault^[16]). Deleting old versions immediately after a rotation is therefore a data-loss event dressed up as tidiness.

Rotating a key re-encrypts nothing on its own. The new version is new wrapping material, so the service holding the protected data has to rewrap its data encryption keys with it, and until that finishes the previous version is still required to unwrap what it protected. Keep the old version enabled until the dependent service reports the rewrap complete, then retire it.

Certificates

A Key Vault certificate carries a certificate policy holding the issuer, the validity period, the key properties, and the lifetime actions that decide when renewal happens (about Key Vault certificates^[17]). Renewal is automatic for certificates issued by an integrated certificate authority and for self-signed certificates, and it fires at a configured percentage of the lifetime or a set number of days before expiry (certificate autorotation^[16]). A renewal produces a new version with a new identifier, exactly as a key rotation does.

This is also why a PFX file uploaded as a generic secret is unmanaged. The lifecycle belongs to the certificate object and its policy; a secret that happens to contain certificate bytes has no policy for Key Vault to act on, so nothing renews it.

Secrets

Secrets have no built-in generator, because Key Vault cannot know how to change a password in your database. The supported pattern is event-driven: a near-expiry Event Grid event triggers a function that mints the new credential at the source system and writes the new secret version (rotate a secret with a single credential set^[18]). Microsoft documents two shapes of this, one for resources with a single set of credentials and one for resources with two sets, where the second set lets the new credential be created and tested before the old one is retired.

Expiration metadata needs care, because it does not do what its name suggests. The exp (expires on) and nbf (not before) attributes on a secret are "for informational purposes only", and a get operation works for a not-yet-valid or expired secret (about Key Vault secrets^[19]). The attribute that actually stops retrieval is enabled, so revoking a leaked secret means disabling that version, not back-dating its expiry. The safe order is to write the new version, update or restart the consumers, and only then disable the old version, because reversing those steps is an outage.

Being told about it

Key Vault publishes lifecycle changes through Event Grid as ten event types, all prefixed Microsoft.KeyVault: new-version-created, near-expiry, and expired for each of secrets, keys, and certificates, plus VaultAccessPolicyChanged (Key Vault as an Event Grid source^[20]). Near-expiry fires 30 days before expiration by default, and for keys the notification time is configurable in the rotation policy. Two conditions gate everything here: notifications trigger only on new versions of an object, and you must first subscribe to the event on the vault. An event subscription that was never created is the reason a rotation function silently never runs.

The line to carry into the exam is that rotation is per object type. Keys rotate themselves on a policy, certificates renew themselves from a policy, and secrets rotate only because you wrote something that rotates them.

Two different exposures need two different products, and questions in this area usually turn on telling them apart. Microsoft Defender for Key Vault watches the calls arriving at a vault. Defender CSPM (cloud security posture management) looks for the credentials that never reached a vault at all, sitting in plaintext on a disk, in a deployment template, or in a repository. The figure below splits the two by where the credential sits, and names the scanning surface each one covers.

Defender for Key Vault sees the vault

Defender for Key Vault "detects unusual and potentially harmful attempts to access or exploit Key Vault accounts" and raises alerts, optionally emailing them (Microsoft Defender for Key Vault^[21]). The alerts appear on the key vault's own Security page, in Workload protections, and on the Defender for Cloud security alerts page. It is a detection control end to end: the alert describes activity that already happened and no request is blocked, so the firewall and the role assignments described earlier remain the only preventive controls.

An alert carries the object ID and the user principal name or IP address of the suspicious caller, and some of those fields are absent depending on how the vault was accessed. An application has no user principal name, and traffic originating outside Azure has no object ID. Microsoft's caution is worth repeating because it inverts the usual instinct: do not dismiss an alert merely because you recognise the user or the application, since the feature exists to catch credentials that were stolen from exactly those familiar identities.

Responding runs in a fixed order. Establish whether the traffic came from inside your tenant, and if the source cannot be identified, tighten reach by enabling the vault firewall and restricting or removing the principal. Then measure the impact from the alert's list of accessed objects and timestamps, corroborated with the vault's audit logs if diagnostic settings were on. Finally rotate every secret, key, and certificate the suspicious caller touched, and have the application owner audit for uses of the compromised credential.

Defender CSPM finds the copies outside the vault

Secrets scanning in Defender for Cloud comes in three types, all agentless (protecting secrets in Defender for Cloud^[22]). Machine scanning finds exposed credentials on multicloud virtual machine disks and is available with either the Defender CSPM plan or Defender for Servers Plan 2. Cloud deployment resource scanning covers multicloud infrastructure-as-code deployment resources, and code repository scanning covers connected Azure DevOps repositories; both of those require the Defender CSPM plan. Supported findings include insecure SSH private keys, plaintext SQL, PostgreSQL, and MySQL connection strings, storage account connection strings and SAS tokens, AWS access keys, and Microsoft Entra client secrets, among many more types listed on that page.

Findings arrive through four review surfaces rather than one: the asset inventory shows the secrets discovered on a specific machine, a recommendation is triggered under the Remediate vulnerabilities security control, cloud security explorer^[23] queries the cloud security graph for secrets insights, and attack path analysis^[24] shows which exploitable path an attacker could walk from that credential to a high-impact asset. The last one is what turns a list of findings into a priority order.

Remediation is not deletion. Deleting the file that held a plaintext credential removes the finding and leaves the credential valid wherever it is accepted, so the fix is to rotate it at its source and then move the value into a vault.

Three channels, three jobs

Detection is not one feed. Key Vault audit logging, enabled through diagnostic settings, records which caller performed which operation on the vault, and it is the only channel that answers that question after the fact (Key Vault logging^[25]). Log alerts built on that data catch security-relevant patterns such as repeated authorization failures or a secret deletion. Event Grid notifications carry lifecycle changes such as a new version or a near expiry. They do not substitute for one another: a lifecycle event is not an audit record, and a Defender alert is not a log.

Key Vault questions on this exam are rarely about what a feature does. They are about which of two plausible controls the scenario actually calls for, and the discriminator is usually one sentence in the stem. These are the recurring shapes.

The application is in the right network and still fails

The stem gives a private endpoint, an application in the connected virtual network, and a failing secret retrieval. The fix is a data-plane role assignment for the workload's managed identity, not another network change, because reachability and authorization are separate gates. Read the failure mode: something the network refused never authenticated, while an authorization failure names the caller in the audit log.

An access policy appears among the options

If the vault uses the Azure RBAC permission model, an access policy on it is ignored, so any option that adds, edits, or repairs one is wrong by construction. When the stem says the permission model was just switched to RBAC and callers broke, the fix is to create the equivalent role assignments, because switching invalidates all previous access-policy permissions.

"Even administrators must not be able to delete it"

That wording asks for purge protection on top of soft delete. Soft delete alone still allows an authorized principal to purge, and a resource lock blocks a delete without providing any recovery. If the requirement instead says a deleted secret must be recoverable for a set number of days, the answer is the retention period, chosen at vault creation between 7 and 90 days.

A subnet, a network security group, and a vault

A virtual network rule works only with the Microsoft.KeyVault service endpoint enabled on the subnet, so an option that adds only an outbound HTTPS rule to the network security group is a distractor. When the client is instead a fixed public address, the answer is an IPv4 address or CIDR rule under selected networks with the default action set to Deny. When a Microsoft service needs access, check the trusted-services list before choosing the bypass, since Azure DevOps and anything else off that list stays blocked.

Rotation stems name the object type

A database password rotates through an Event Grid near-expiry event and a function that writes the new secret version, never through a key rotation policy. A customer-managed key rotates through a rotation policy, and the follow-up requirement is usually that the dependent service rewraps its data encryption keys while the old version stays enabled. A certificate that must renew itself has to be stored as a certificate object with a policy using an integrated certificate authority or self-signed certificate regeneration; a PFX stored as a generic secret cannot renew.

Defender stems split by where the credential lives

An alert about unusual or suspicious vault access is Defender for Key Vault, and the correct response rotates what was accessed rather than expecting the product to have blocked anything. Plaintext credentials discovered on virtual machine disks across Azure, AWS, and GCP are agentless machine secrets scanning, which needs Defender CSPM or Defender for Servers Plan 2; credentials in deployment templates or in a connected repository need Defender CSPM specifically. If an option offers Defender for Key Vault as the way to find secrets committed to a repository, it is inspecting the wrong surface.

Two options both look correct

When one option changes reach and the other changes permission, the requirement decides. Wording about who may use the material points at a role assignment; wording about where a call may originate points at the firewall, a service endpoint, or a private endpoint; and wording about what must be noticed points at Defender or at diagnostic settings. Naming the layer first, then the control, is faster than comparing the four options against each other.