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.
New to cloud? CAMPUX is a free, build-first course. Start here →
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.
@Microsoft.KeyVault(SecretUri=…). At startup the app uses its managed identity to fetch the real secret from Key Vault (RBAC must allow it) and injects the value into the setting your code reads. Your code sees a normal environment variable; the secret itself never sits in config, source control, or the deployment.The identity is what makes it safe
What turns this from "moved the secret" into "removed the credential problem" is the identity. 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. Set it up once and a whole class of accident simply stops happening: there is no secret in the config to leak, nothing sensitive in the repo to grep for, and no 3am scramble the day a connection string surfaces in someone's git history.
Questions people also ask
What is a Key Vault reference in Azure App Service?
It is an app setting whose value points at a secret in Azure Key Vault instead of containing the secret itself, written as @Microsoft.KeyVault(SecretUri=...). App Service resolves it at runtime and hands your code the real value, so your code reads the setting exactly as it always has.
How does App Service authenticate to Key Vault for a reference?
Through the app's managed identity, not a stored credential. You grant that identity the Key Vault Secrets User role (or a Get access policy) on the vault, and the platform fetches the secret by proving the app's own identity rather than presenting another password.
Do Key Vault references require code changes?
No. Your application still reads an app setting or connection string the normal way. The @Microsoft.KeyVault(...) syntax lives only in the setting's value in the portal or ARM template, so nothing in your source changes.
How often does a Key Vault reference pick up a rotated secret?
If the reference does not pin a version, App Service refetches it and starts using the new value within about 24 hours. Any config change or app restart forces an immediate refetch, so you are not stuck waiting on the automatic cycle.
Why should Key Vault references be slot settings?
Because each deployment slot should point at its own vault. Marking references as sticky slot settings stops a reference to the staging vault from swapping into production during a slot swap, which would point live traffic at the wrong secrets.