Azure Functions: managed identity or connection string?

Prefer a managed identity where the target service supports it, use Key Vault references where it does not, and keep plain connection strings in application settings as the last option. Identity based connections remove the secret entirely, which means nothing to leak and nothing to rotate.

Three ways to give a function access

Application settings. The default. Connection strings and keys sit in app settings, which Azure encrypts. Microsoft's documentation says they are decrypted only before being injected into the app's process memory at startup, and the encryption keys are rotated regularly. The code and bindings read the value by setting name. This is enough for many functions, but the secret still exists and still needs managing.

Key Vault references. An app setting can point to a Key Vault secret instead of holding the value. This gives central secret storage, access policies and an audit history. It also avoids duplicating the same secret across several apps, since redundant copies mean more places to leak.

Identity based connections. With a managed identity from Microsoft Entra ID, the platform manages the identity, so you do not provision or rotate any secrets. Some trigger and binding extensions can use identity based connections. Documentation says this approach also gives finer grained access control and auditing.

System assigned versus user assigned

A system assigned identity is tied to the app and deleted with it. An app has at most one. A user assigned identity is a standalone resource that can be attached to several apps, and an app can have several.

Use system assigned when one function app needs its own access and nothing else. Use user assigned when several resources must share the same permissions, or when you need the identity to survive redeployment of the app.

The privilege boundary is the function app

Microsoft points out that connection strings and credentials in application settings give all functions in the app the same permissions on the linked resource. If one function needs a credential and the others do not, consider moving the others into a separate function app. You can still pass data between apps by chaining.

A decision sequence

1. Does the target support Entra authentication? Use a managed identity and grant the narrowest role.
2. If not, can the secret live in Key Vault? Use a reference.
3. If neither, use an app setting, and plan a rotation date.
4. Split apps if functions need different privileges.
5. Never put secrets in function code.

Pitfalls

• A managed identity with an owner level role is no better than a leaked key. Grant specific roles on specific resources.
• Deployment credentials are a separate matter. The documentation says Key Vault is not supported for deployment credentials, so protect and reset them separately.
• The storage account linked to the app holds important data, sometimes including code. Limit access to it.

Quick check

Safeguard's free scan checks the dependencies in the code those identities run.

Sources

• Securing Azure Functions, Microsoft Learn

Last reviewed: 19 October 2026.