Key Vault and Managed Identities in Production

The safest secret is often the secret an application never has to store. Azure managed identities make that possible for many service-to-service connections by allowing an Azure workload to obtain Microsoft Entra tokens without embedding a password, client secret, or certificate in application configuration. Azure Key Vault remains essential for credentials, keys, and certificates that genuinely must exist, but its strongest production role is part of a broader identity-first design rather than a universal place to put every connection string.

This topic crosses Azure administration, architecture, and identity. Candidates preparing for AZ-104, AZ-305, or SC-300 all encounter parts of the same production question: how should a workload authenticate, what should it be authorized to access, and what should happen when a secret cannot be eliminated?

Start by deciding whether the application needs a secret at all

Legacy application design often begins with a connection string containing a username, password, shared key, or client secret. That credential has to be stored somewhere, deployed safely, rotated, audited, and revoked when compromised. Every copy creates another exposure path.

If the downstream Azure service supports Microsoft Entra authentication, use identity instead of a shared credential where practical. A managed identity can request a token for the target service, and Azure manages the identity’s underlying credentials. The application code does not need to know or rotate a secret.

This is the central idea behind workload identity: a machine should have an identity with explicit permissions, not merely possession of a reusable secret.

System-assigned and user-assigned identities solve different lifecycle problems

A system-assigned managed identity is tied to one Azure resource. When that resource is deleted, the identity is deleted with it. This can be a clean fit for workloads where the resource and identity should share the same lifecycle.

A user-assigned managed identity is a separate Azure resource. It can be associated with multiple supported workloads and can exist independently of them. That makes it useful when several resources need the same identity, when deployment order requires the identity to exist first, or when identity ownership is managed separately from compute.

User-assigned identities are not automatically safer simply because they are reusable. Sharing one identity across unrelated services can enlarge the blast radius. The design should balance lifecycle convenience with permission isolation and operational ownership.

Managed identity removes credential management, not authorization

After a workload obtains an identity, it still needs permission on the target service. Azure RBAC should grant only the actions needed at the appropriate scope. If a function only reads blobs from one storage account, assigning subscription Contributor is unnecessary and dangerous.

This distinction matters in incidents. An attacker who compromises application code can use the managed identity’s permissions even though the attacker never sees the underlying credential. Least privilege therefore remains essential.

The same thinking applies to Key Vault. A workload that only retrieves secrets should not receive permissions to create, delete, or purge them. Management-plane rights over the vault are also different from data-plane access to the keys, secrets, and certificates stored inside it.

Key Vault has a control plane and a data plane

The control plane manages the Key Vault resource itself: creating or deleting the vault, configuring networking, changing properties, and managing resource-level settings. The data plane handles the sensitive objects inside the vault, such as reading a secret, using a key, or retrieving a certificate.

Microsoft Entra authenticates callers, but authorization must be appropriate to the plane and operation. Azure RBAC is now the preferred authorization approach for Key Vault data-plane access in current platform guidance, while older vault access policies are a legacy model that many existing environments still use.

Production reviews should verify that an operator who can manage vault settings does not automatically have access to secret values unless that access is genuinely required. Separating administrative responsibility from secret consumption reduces unnecessary exposure.

Use Key Vault for secrets that cannot be replaced by identity

Some dependencies do not support Entra authentication. A third-party API may require a static API key. A legacy database may still require a password. A certificate may be needed for a protocol or trust relationship. Those are valid Key Vault use cases.

The application should authenticate to Key Vault with its managed identity, retrieve the required credential at runtime, and use the credential only for the dependency that needs it. This reduces the number of systems that store the secret and centralizes access logging and rotation.

The broader secrets management principles still apply: minimize copies, define ownership, rotate when possible, support revocation, audit access, and avoid putting secrets in source code, container images, deployment templates, or pipeline logs.

Secretless code should work across development and production environments

Developers need a practical way to authenticate locally without hardcoding production credentials. Azure Identity libraries and the DefaultAzureCredential pattern allow the same application code to use a developer identity locally and a managed identity in Azure.

This reduces environment-specific authentication logic. The code asks for a token through a standard credential chain rather than switching between bespoke password configurations. Production can then use managed identity while development uses an approved interactive or developer credential.

The architecture still needs guardrails. Developer identities should not have broad production access simply because the code supports the same authentication flow. Environment separation belongs in RBAC and resource design, not in a hardcoded conditional branch inside the application.

Network restrictions should protect Key Vault without making recovery impossible

Key Vault can restrict public network access and use private endpoints so workloads reach the vault over private network paths. Firewall settings and Private Link reduce exposure, especially for sensitive production environments.

Private access creates dependencies on routing and DNS. If a private endpoint exists but the vault name resolves to a public address from the application network, the intended path is not being used. If the DNS resolver or private zone is unavailable, the application may fail even though Key Vault itself is healthy.

Design and test the full path. Confirm name resolution from every environment that needs the vault, document emergency administrative access, and monitor denied requests so networking problems are distinguishable from authorization failures.

Rotation is still necessary for secrets that remain

A secret stored in Key Vault is safer than one hardcoded in source, but it can still be stolen or overused. Rotation limits the useful lifetime of a compromised credential. The challenge is coordinating rotation with the systems that consume the secret.

Where the downstream service supports two active credentials, rotate by creating the new credential, updating the vault, verifying consumers, and then revoking the old value. Certificates need similar lifecycle planning around issuance, renewal, distribution, and trust.

The general key management and certificate concepts matter because not every Key Vault object has the same lifecycle. Keys may protect encryption operations, certificates may establish trust, and secrets may authenticate to external services.

Soft delete and purge protection protect against destructive mistakes

Deletion is an operational risk as well as a security risk. Key Vault soft delete keeps deleted vaults and objects recoverable for a retention period. Purge protection prevents permanent removal until that period expires.

These features are especially important for encryption keys. If data is encrypted with a key and the key is permanently destroyed, the data may become unrecoverable even though backups still exist. That is why production designs should treat key deletion as a high-impact operation.

Recovery settings should be part of the deployment baseline, not something enabled after the first accidental deletion. The team should also know who has purge rights and how recovery is tested.

Workload identity federation extends secretless design beyond Azure

Managed identities work naturally for Azure-hosted resources, but applications also run in GitHub Actions, Kubernetes clusters, other clouds, and on-premises systems. Workload identity federation allows trusted external identities to exchange their own tokens for Microsoft Entra access tokens without storing a long-lived client secret.

This is useful for CI/CD pipelines and multicloud workloads because it removes another class of static credential. The trust relationship should be constrained to the expected issuer, subject, audience, and permissions so that federation does not become a broad backdoor.

Secretless architecture is therefore broader than “turn on managed identity.” The principle is to use short-lived identity tokens and explicit trust relationships wherever the platform allows it.

Logging should make identity and secret use explainable. Teams need to know which identity accessed which vault, what operation was attempted, whether it succeeded, and whether permissions or network controls changed. Administrative activity and data-plane access should be monitored according to the sensitivity of the environment.

Unusual patterns deserve attention: a workload retrieving a secret it never used before, a new role assignment at vault scope, repeated denied access, a sudden change in source network, or a privileged operator reading secret values directly.

Good telemetry also speeds troubleshooting. A 403 can come from missing RBAC, an expired token, wrong tenant, or network restriction. Evidence prevents teams from solving an identity problem by weakening the firewall or solving a DNS problem by granting broader permissions.

The production pattern is identity first, vault second. When designing a new Azure workload, first ask whether Microsoft Entra authentication can replace the credential. If yes, use a managed identity or another appropriate workload identity and grant the minimum permissions required. If a non-Entra dependency still needs a secret, store that secret in Key Vault and let the workload retrieve it through its identity.

Then protect the vault with RBAC, network controls, deletion safeguards, monitoring, and a tested rotation process. This creates a smaller and more understandable credential surface than a design where every application stores multiple secrets.

Key Vault remains a critical security service, but production maturity is not measured by how many secrets are moved into it. The stronger outcome is fewer secrets, better identities, narrower permissions, and a vault reserved for the sensitive material that truly cannot be eliminated.

Separate vaults and identities by environment and application risk. A single organization-wide vault can look simple but creates broad administrative and failure domains. Microsoft’s current RBAC guidance recommends thinking in terms of a vault per application per environment for many scenarios, with roles assigned at the vault scope. This makes production access easier to distinguish from development access and reduces the number of unrelated applications sharing one secret boundary.

Do not create separate vaults mechanically for every microservice if the operational burden outweighs the isolation benefit. Group objects that share owners, lifecycle, access patterns, and recovery requirements. High-value encryption keys, shared platform certificates, and ordinary application secrets may deserve different boundaries because compromise or deletion would have different consequences.

Managed identities should follow similar logic. One user-assigned identity reused by many unrelated workloads simplifies administration but couples their permissions. Separate identities improve blast-radius control and audit clarity. Choose the boundary deliberately and document which team owns each identity, vault, role assignment, and rotation process.