Microsoft SC-500: Key Vault Access Design

Azure Key Vault access design has three separate questions: who can manage the vault resource, who can read or use the secrets, keys, and certificates inside it, and which networks are allowed to reach the data-plane endpoint. Mixing those concerns creates broad permissions and troubleshooting confusion.

Current Microsoft guidance treats Azure RBAC as the preferred permission model for Key Vault data-plane authorization. Starting with Key Vault API version 2026-02-01, Azure RBAC is the default access-control model for newly created vaults. Key Vault access policies remain a legacy data-plane option, but modern designs should normally use RBAC unless a specific compatibility requirement says otherwise.

Key Vault design belongs inside Microsoft Identity & Security.

Separate control plane and data plane

The control plane manages the Key Vault resource itself: create, delete, configure networking, and change properties.

The data plane handles secrets, keys, and certificates.

Azure RBAC should assign management and data roles independently so an operator who can view resource properties does not automatically read secret values.

Prefer Azure RBAC for new vaults

Azure RBAC centralizes access control with the rest of Azure and supports built-in data roles such as Key Vault Secrets User, Key Vault Reader, Key Vault Crypto Officer, and Key Vault Administrator.

Assign the smallest role at the smallest practical scope.

A workload that only reads one secret should not receive vault-wide administrator permissions.

Tightly control vault administration

Users with broad control-plane permissions can affect networking, permissions, and resource lifecycle.

Keep vault contributors and role-assignment administrators tightly scoped.

Privileged access can make high-impact administrative roles eligible and time-bounded instead of standing.

Use managed identities for applications

Applications running on Azure should use managed identities where supported rather than store a client secret merely to read another secret.

Managed identities reduce credential lifecycle and allow Key Vault access to be expressed through an Azure role assignment.

The Key Vault role should still reflect the exact operations the workload needs.

Restrict network exposure

Key Vault supports public network rules, service-endpoint restrictions, private endpoints, and Network Security Perimeter scenarios.

Private Link is the strongest network-isolation pattern when the application can resolve and reach the private endpoint correctly.

Network restrictions do not replace Microsoft Entra authentication and Key Vault authorization.

Plan DNS for private endpoints

Private endpoints change how the Key Vault hostname resolves from approved networks.

Private DNS zones, VNet links, Azure DNS Private Resolver, or on-premises conditional forwarding may be required.

A network design that omits DNS will produce authentication-looking failures even when permissions are correct.

Enable recovery protections

Soft delete is enabled by default for new vaults and, once enabled, cannot be disabled.

Purge protection is optional but strongly recommended for production and prevents permanent deletion until the retention period elapses.

Recovery design should identify who can recover, who can purge, and which dependent services must be recreated if a soft-deleted vault is restored.

Rotate secrets and keys operationally

Key Vault can support rotation patterns for keys, certificates, and application secrets.

Managed identity should remove secrets that do not need to exist, while remaining credentials need owners, expiration, rotation automation, and dependent-workload testing.

Rotation is complete only when the application picks up the new credential successfully.

Use Policy to enforce the baseline

Azure Policy includes Key Vault-related controls for RBAC permission model, public-network access, Private Link, firewall configuration, and other security expectations.

Azure Policy can turn the vault standard into an enforceable platform baseline.

For engineers working around SC-500, the durable design is to separate control and data planes, prefer RBAC, use managed identities, restrict network access, protect recovery, automate rotation, and keep privileged vault administration time-bounded.

Vault boundaries should follow ownership and blast radius. One enterprise-wide vault may appear simple, but it can create broad administrative and network consequences. Separate vaults by application, environment, or trust boundary where independent lifecycle and permission management create meaningful isolation.

RBAC roles should be selected according to operation. A workload that retrieves secrets needs a different role from a security engineer who rotates keys or an administrator who manages certificates. Avoid Key Vault Administrator unless the principal truly needs all data-plane operations.

Role-assignment scope can be set at subscription, resource group, vault, or supported individual object scope. Broader scope simplifies administration but expands privilege. Use vault-level or object-level assignments where the operating model can manage them reliably.

Access-policy migration should be planned. Organizations with legacy vaults may still use access policies, and moving to RBAC changes how permissions are represented and governed. Inventory existing callers, map operations to RBAC roles, test access, and preserve rollback before changing production authorization.

Network Security Perimeter is now generally available for supported Key Vault scenarios and provides another PaaS isolation model alongside firewall and Private Link. The right choice depends on whether the organization needs VNet-local private endpoints, logical perimeter controls for public PaaS, or a combination.

Trusted Microsoft services bypass should be used carefully. Only documented services can use it, and the caller still needs Entra authentication plus Key Vault authorization. Treat it as a network exception with known consumers rather than a general “allow Azure” switch.

Soft-delete recovery needs runbooks because restoring the vault does not automatically restore every integration around it. Microsoft notes that role assignments and Event Grid subscriptions associated with a deleted vault might need to be recreated. Recovery testing should include those dependencies.

Purge permissions should be separate from ordinary secret administration. Purge protection prevents bypass while active, and dedicated purge roles help ensure that permanent deletion is not available to every vault operator. High-value encryption keys deserve especially strict recovery and purge governance.

Key Vault access design is strongest when it removes as many long-lived secrets as possible, narrows the roles for the secrets that remain, restricts network paths, protects deletion, and makes every administrative path auditable. The vault is not secure because it stores secrets; it is secure when the surrounding identity and network model keeps those secrets available only to the workloads that need them.

Vault naming and ownership should make environment and application purpose obvious. Production and nonproduction secrets should not share one vault merely to reduce the number of resources if that creates cross-environment administrator or workload access.

Secret consumers should handle throttling and temporary Key Vault unavailability gracefully. Reuse secrets in memory for an appropriate short period where safe instead of calling Key Vault for every tiny operation, but avoid writing secret values to disk or logs as part of that cache.

Key rotation should consider multi-version overlap. Some applications can accept old and new credentials simultaneously, which enables safer rollout; others require a coordinated cutover. The rotation design belongs to the application and vault together.

For high-value vaults, test recovery, network access, RBAC, and application startup as one scenario. A recovered vault that cannot be reached privately or whose role assignments were not rebuilt is not actually recovered from the workload’s point of view.

Access reviews should include both human administrators and application principals. A workload identity can accumulate secret or key permissions over time just as easily as a user can. Periodically confirm that every principal with Key Vault access still has an active business dependency and the smallest suitable role.

Key Vault should also be included in dependency documentation for disaster recovery. Applications that cannot start without one vault need a tested strategy for regional design, DNS, role restoration, secret recovery, and emergency access before the primary path fails.

Use separate vaults when compliance, blast radius, or ownership requires it, but avoid creating hundreds of tiny vaults with no management model. The correct boundary is one that keeps permissions, recovery, networking, and operational responsibility understandable.

Access design should also account for Azure services that integrate with Key Vault using managed identities or service-specific features. Verify exactly which principal the service uses and which data-plane role it requires instead of granting a broad role to the deployment identity that configured the integration.

Finally, monitor failed authorization and network attempts. Repeated 403s, DNS failures, or denied network paths often reveal stale applications, broken rotations, or unauthorized access attempts that should be investigated before users work around the controls.

Keep network, RBAC, recovery, and rotation decisions documented together so responders can distinguish access-policy failure from DNS, private-endpoint, credential, or application issues quickly.

Review vault dependencies after application migrations so retired workloads do not keep network rules, role assignments, or recovery assumptions that expand the operational surface.

Keep access reviews tied to real application dependencies.

Test recovery.