Key Vault references: the secret that never lives in your config
The oldest security sin in web apps is a password sitting in a config file. Key Vault references delete that sin without a single code change: your app setting stops holding the secret and starts holding a pointer to it, and the platform fetches the real value at runtime using an identity, not a credential.
On Azure App Service and Functions, an app setting or connection string normally holds a literal value — including, too often, a database password or an API key in plain sight. A Key Vault reference changes what that setting is. Instead of the secret, you store a reference to a secret in Azure Key Vault, and Microsoft's promise is the key line: "When an app setting or connection string is a Key Vault reference, your application code can use it like any other app setting or connection string." Your code reads the setting exactly as before — but the actual secret never touches your app's configuration.
What it looks like
A reference is just a specially formatted string in the value of an app setting:
@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret)
At runtime, App Service sees that @Microsoft.KeyVault(...) marker, goes to the vault, fetches the real secret, and hands your code the resolved value. From the application's point of view, DatabasePassword just contains the password — as it always did. From a security point of view, the password lives only in Key Vault, with its access policies, versioning, and audit log, and never in your site config, your ARM template, or your source control.
The identity is what makes it safe
Here is the part that turns this from "moved the secret" into "removed the credential problem." The app authenticates to Key Vault using a managed identity — an Azure-managed identity for your app, with no password of its own. You grant that identity read access to the vault's secrets (the Key Vault Secrets User role under RBAC, or a Get access policy), and from then on the app fetches secrets by being itself, not by presenting yet another secret. This is the whole point of managed identity: it dissolves the bootstrap problem of "how does my app authenticate to the place that stores its passwords?" The answer is that it does not need a password to get its passwords.
The setting stops holding the secret and starts holding a pointer to it. The app fetches the real value by being itself — no credential in config, none in code.
Rotation, handled
A quiet benefit: because the app resolves the reference from the vault, rotating a secret does not mean redeploying the app. If you do not pin a version in the reference, the app picks up the newest version of the secret automatically — Microsoft notes the app refetches referenced secrets and begins using a rotated value within about 24 hours (and any config change or restart forces an immediate refetch). Rotate the database password in Key Vault, and your app follows along on its own. Secrets stop being a thing you copy around and start being a thing you manage in one place.
If you use deployment slots, remember that each environment should point at its own vault — staging's secrets are not production's. So Microsoft recommends marking most Key Vault references as slot settings (sticky), so a reference to the staging vault does not swap into production. Two other things worth knowing: if a reference fails to resolve (a typo, a missing access policy, a deleted secret), the app gets the literal @Microsoft.KeyVault(...) string instead of the value — which usually surfaces as a confusing runtime error, so check the reference status in the portal first. And for a network-restricted vault, the app needs virtual-network access to reach it.
The takeaway
Key Vault references let an App Service or Functions app setting point at a secret in Key Vault instead of containing it. The platform resolves the reference at runtime using the app's managed identity, so no secret ever sits in your config, template, or repo, and rotation is picked up automatically — all with zero code changes, since your app reads the setting exactly as before. Mark the references as sticky slot settings so environments keep their own vaults. "Every secret in Key Vault, referenced from app settings, resolved by a managed identity, nothing sensitive in config or source" is the answer of someone who never wants to explain a leaked connection string in a git history again.