Securing Secrets in .NET with Azure Key Vault

Decide whether the value is actually a secret

Teams sometimes put feature flags, host names and ordinary tuning values into Key Vault because “secure configuration” sounds uniformly safer. That creates unnecessary access calls and makes harmless operational changes depend on secret-management privileges. A secret is a value whose disclosure enables unauthorised action or reveals protected information.

Keep non-sensitive configuration in an appropriate configuration service or deployment artefact, with integrity and change control. Put certificates in the certificate capability when lifecycle and private-key handling require it, and cryptographic keys in the key capability rather than exporting them as secret text. Classification determines the controls.

The first objective is to need fewer secrets

Moving a password from appsettings.json into Azure Key Vault is an improvement, but it leaves the application dependent on a recoverable credential. The stronger design removes credentials where Azure identity and role-based access can represent the trust directly.

Use managed identity for Azure-hosted workloads where the target service supports Microsoft Entra authentication. The platform supplies and rotates the workload credential; the application requests a token for the target resource. This eliminates a bootstrap secret for Key Vault itself and often removes database, storage and messaging keys too.

Key Vault remains appropriate for third-party API keys, certificates and credentials to systems that cannot accept federated identity. Treat it as a controlled boundary for unavoidable secrets, not a destination for every configuration value.

A vault does not erase secret sprawl

A secret can leak before or after retrieval: developer machines, pipeline variables, logs, exception pages, crash dumps, copied support messages and client-side configuration. Inventory where secrets originate, how they enter the vault, which process reads them and every place plaintext may persist.

Do not put secrets in source control and then “fix” the incident by deleting the commit. Git history, forks and build artefacts may retain it. Revoke or rotate the exposed credential first, then remove copies and investigate use.

Configuration naming can leak purpose without leaking value. That is usually acceptable, but avoid secret values in health endpoints, telemetry tags and configuration dumps. Redaction should be allowlist-driven; trying to recognise every sensitive key after logging is unreliable.

Production identity should be boring and narrow

A system-assigned managed identity follows one Azure resource and is removed with it. A user-assigned identity can be shared or moved independently, which is useful for deployment slots or several instances but increases the blast radius when reused too broadly.

Grant data-plane access only to the secrets or vault scope the workload requires. Separate read, write, rotation and administrative duties. An application that only retrieves secrets should not create, delete or purge them. Deployment automation does not automatically need runtime read access.

Use a dedicated production credential such as ManagedIdentityCredential when deterministic identity selection matters. DefaultAzureCredential is convenient for local development because it chains developer credentials, but an unexpected available credential in a hosted environment can make identity behaviour harder to reason about.

Local development needs identity, not copied production secrets

Developers can authenticate with their own Entra identity through supported tooling and receive narrowly scoped access to a development vault. That preserves attribution and allows prompt revocation. Shared credentials in team password managers are sometimes necessary for external systems, but should not become the default application identity.

Keep development, test and production vaults separate. Environment prefixes inside one vault reduce naming collisions but do not create strong administrative or blast-radius separation. Production access should be exceptional and audited.

For automated tests, inject an abstraction or configuration values designed for the test environment. Unit tests should not require live Key Vault access, while a small integration suite should verify identity, permissions and secret naming against non-production infrastructure.

Loading secrets at startup trades availability for freshness

The ASP.NET Core Key Vault configuration provider can load secrets into IConfiguration. That is convenient for application-wide values but means startup depends on vault access. Once loaded, values live in process memory like other configuration; Key Vault does not protect them during use.

The provider does not reload by default. A configured reload interval polls for changes, but consumers must also read configuration in a way that observes updates. Objects constructed once from old values will not rotate merely because the provider refreshed.

Expired secrets require deliberate handling. Current Microsoft documentation notes that expired secrets may be included by the provider unless custom loading logic excludes them; disabled secrets are not loaded. Do not assume expiry metadata automatically enforces the application's lifecycle.

Request-time lookup is rarely the resilience answer

Fetching a secret from Key Vault for every user request increases latency, cost and dependence on a control-plane service. It can turn a vault incident or throttling event into a complete application outage. Cache values for a bounded period appropriate to rotation and risk.

Caching has consequences: revoked values may remain usable until expiry, and every instance may refresh simultaneously. Add jitter, retain the last known usable value only when policy permits and avoid unbounded fallback that defeats revocation.

Different secrets need different strategies. A signing key selected by version may need both current and previous keys during rollover. A compromised API key may require immediate rejection. “Cache for an hour” is not a lifecycle design.

Rotation is a protocol between systems

Creating a new secret version is only the first step. The producer must issue the credential, Key Vault must store it, workloads must discover it, the target system must accept it and the old credential must be revoked after overlap. Each step can fail independently.

Prefer versionless secret references for ordinary rotation when the application should follow the current version. Pin a version when reproducibility or controlled rollout matters, but then ownership must update the reference. Test whether connection pools and SDK clients recreate themselves after credentials change.

Safe rotation commonly uses overlap: add the new credential, update consumers, verify use, then remove the old credential. Systems allowing only one active credential create a coordinated outage risk and deserve extra recovery planning.

Deletion protection is not backup

Soft delete and purge protection reduce the risk of accidental or malicious permanent deletion. They do not protect against replacing a value with the wrong secret, excessive access or an application copying plaintext elsewhere.

Recovery exercises should prove that operators can identify the correct version, restore access and restart or refresh dependent workloads within the required time. Protect the permissions needed for recovery so an attacker cannot both delete a secret and purge its history.

Infrastructure definitions should create vault configuration and access policy, but never contain secret values. Restoring an environment still requires a controlled source or reissue process for each external credential.

Network isolation and identity solve different problems

Private endpoints and firewall rules reduce which networks can reach a vault. Entra identity and RBAC decide which principal may perform an operation. Use both where the threat model warrants them; neither replaces the other.

Private networking adds DNS, routing and recovery complexity. Build agents, deployment slots and incident tooling must still reach the vault through intended paths. Test from the actual runtime environment rather than assuming a successful developer request proves production connectivity.

Do not expose a server-side secret through an API merely because the client cannot reach Key Vault. Browser and mobile applications cannot keep a shared secret. Move privileged calls behind a trusted backend or use delegated protocols intended for public clients.

Observe access without exposing values

Monitor authentication failures, forbidden operations, unusual principals, deletion, purge and secret-version changes. Correlate application retrieval failures with vault diagnostics while keeping secret values and access tokens out of telemetry.

Alerting on every normal read creates noise. Baseline expected workload identities and operations, then focus on privilege changes, unexpected locations, bursts and recovery controls. Audit who changed RBAC as carefully as who changed a secret.

Application health should distinguish “cannot fetch the latest secret” from “cannot serve”. If a safe cached value exists, readiness may remain healthy while an operational alert fires. If startup requires a missing credential, fail clearly rather than running partially configured.

A practical secret lifecycle checklist

• Replace secrets with managed identity where supported.
• Separate environment vaults and identities.
• Grant runtime read access without write or purge.
• Keep production credentials out of local development.
• Choose startup, polling or on-demand retrieval deliberately.
• Bound caches according to revocation needs.
• Test overlapping rotation through every consumer.
• Enable and rehearse deletion recovery controls.
• Protect values from logs, dumps and client configuration.
• Monitor identity, access and lifecycle events.

Key Vault is valuable because it centralises policy and evidence around unavoidable credentials. The secure outcome still depends on reducing those credentials, controlling plaintext use and operating rotation and recovery as real production workflows.