Azure Key Vault is often introduced as a convenient replacement for secrets in source code. That is a useful start, but the SC-500 security problem is deeper: who can configure a vault, who can actually read a secret or use a key, what happens if its access model changes, and can an attacker destroy evidence or critical keys? A vault with encryption enabled but broadly assigned data permissions is not an adequate security boundary.
Consider a fictional payroll API that calls Azure SQL using a managed identity and needs an external vendor certificate for one legacy integration. Its security team wants secrets rotated without breaking the service, permission changes controlled by approved administrators, and accidental deletion recoverable. The solution must coordinate identity, Key Vault’s control and data planes, network reachability, event logs and application behavior rather than merely creating an empty vault resource.
Separate Key Vault control-plane roles from data-plane access
The Key Vault control plane uses Azure Resource Manager to deploy a vault, configure networking, update settings and manage resource metadata. The data plane performs operations on the items stored inside: get or set a secret, use a key to encrypt or sign, or retrieve a certificate. These are different resource and authorization contexts. Giving an engineer permission to read a vault’s configuration does not mean the engineer should automatically read production payroll credentials.
Microsoft’s current Key Vault RBAC guidance explains Azure role-based access control for the vault data plane. Starting with API version 2026-02-01, new Key Vaults default to the Azure RBAC authorization model. Older vaults may still use legacy access policies. Identify the actual model of every vault before applying an example: a role assignment designed for an RBAC vault does not fix access policies that are still in use.
Build a permission table by principal, operation and scope. The payroll API might require only permission to retrieve a particular secret; the certificate renewal service needs certificate operations; an administrator may need to configure the vault without reading production values. Prefer appropriate Key Vault data roles to a subscription-wide Owner assignment. Review role-assignment authority carefully because someone able to grant powerful roles can give new principals access indirectly.
Understand the risk in legacy access policies
The legacy access policy model places data permissions in vault configuration. In that model, someone with broad vault configuration rights can potentially change an access policy to give themselves secret or key access. Microsoft explicitly recommends RBAC over legacy access policies to better separate administrative management from permission granting. That distinction is an SC-500 implementation issue, not only a documentation footnote.
A migration needs a plan rather than a blind switch. Inventory identities and existing policies, resolve which principals actually use keys, secrets and certificates, create the corresponding least-privilege RBAC assignments, and test them with real workload identities before the model changes. Record a rollback procedure and consider assignment propagation. An immediate switch without compensating roles can produce an outage when production apps try to read secrets and receive authorization errors.
The site already contains an Azure Key Vault architecture discussion about boundaries and resource selection. The SC-500 focus here is proving the permission model’s behavior and an operator’s ability to change it safely. A diagram of the intended trust boundary is not enough if the actual service continues to run as an overprivileged principal.
Prefer workload identity to embedded credentials
Managed identity lets eligible Azure-hosted services request tokens through Microsoft Entra without managing a long-lived application client secret in configuration. It still needs the correct resource-specific Key Vault permission and a supported network path. A managed identity with no Key Vault Secrets User or equivalent necessary permission cannot read a secret simply because it is attached to a VM or App Service.
For the payroll API, obtain a secret or certificate through its approved managed identity and SDK, without copying tokens or retrieved values into URLs, client-facing logs or diagnostics. A cached secret needs a controlled refresh rule when a new version is created: a new Key Vault version does not by itself prove that the external database, payment service or every application instance accepts it. In a rotation test, validate the consumer’s actual authentication before retiring the previous credential, and record any temporary disagreement between the stored secret and the backing service. If a required secret cannot be obtained, report a bounded application failure rather than silently falling back to an old hard-coded password.
Avoid using a globally shared user-assigned identity for unrelated environments merely because it is easy to deploy. Separate development and production principals. If a test service is compromised, it should not be able to read production signing keys. The credential’s identity and the vault item’s scope need to match the deployment that will actually use them.
Protect the network path to vault data
Authentication is not network isolation. A Key Vault can have appropriately scoped RBAC but still be unnecessarily reachable through a public endpoint. Use the supported firewall and private-endpoint controls required for the data sensitivity and operating model, and test client reachability through the intended route. If a private endpoint is used, DNS must resolve to the private address within the relevant networks and clients must have a valid route.
A subtle failure occurs when a developer workstation reaches a public endpoint while the hosted application expects a private path. The application can work locally and fail after deployment. Diagnose with the actual runtime identity, DNS resolution, network configuration and Key Vault authorization response. Do not “fix” the issue by broadly re-enabling public access for every client or by granting an administrator role to the workload.
Private networks also have operational cost. A certificate renewal process, disaster recovery application and monitoring system need their own approved paths. Document which managed or platform components access Key Vault through trusted-service mechanisms, where those paths are supported, and whether the current deployment has been tested under network restrictions.
Rotate and version secrets, keys and certificates deliberately
A secret is usually a credential or other value the application retrieves; a cryptographic key may perform cryptographic operations; a certificate combines a public-key identity and related lifecycle information. Their rotation behaviors differ. A system may consume a newly versioned secret, while a signing key change may require distributing new verification material to consumers. Versioning is useful only if the application knows which version to resolve and how to recover when rotation fails.
Build a rotation rehearsal with a nonproduction credential. Create the next version, validate the application against it, update the allowed consumer if necessary, confirm healthy operation, and then revoke the old dependency according to policy. Test an old instance that still holds a cached secret and a consumer that cannot accept the new certificate. A rotation event cannot be declared successful solely because Key Vault displays a new version.
Keep secret expiry and certificate expiry visible to operators. Configure monitoring that identifies near-expiry objects and failed renewal jobs, but avoid copying secret payloads to a generic alert. Ensure any automated rotation identity has only the minimum operations it needs; a renewal worker should not be able to delete every key in the vault.
Design deletion protection and recovery before an incident
Soft delete and purge protection address distinct loss risks. Soft delete supports recovery of deleted vaults or objects during the configured retention period; purge protection can prevent permanent purge while retention conditions apply. The precise behavior depends on the vault and object’s current configuration. Test recoverability in a controlled environment and document who can perform recovery. A backup stored with unrestricted administrator access may not protect against compromise of that same administrator.
An incident response runbook should answer what happens if a critical certificate is mistakenly deleted, a vault is temporarily unreachable, or a key is suspected compromised. Recovery from deletion and response to compromised secrets are different: recovering a secret that an attacker already read does not make the leaked value safe. Compromise calls for credential rotation, review of activity logs and containment of the affected principal.
Enable relevant Defender for Key Vault threat protection and diagnostic destinations when licensed and supported. Alert on anomalous access or suspicious deletion attempts, then corroborate alerts against authenticated logs. Avoid claiming the tool can automatically prove exfiltration or identify a person’s intent from a single event. Establish a minimum evidence set: principal, action, item identifier, timestamp, source path and resulting application state.
Verify with negative permissions and recovery tests
Test as an application reader, a configuration administrator, a security role administrator and an unrelated user. The reader should retrieve only the intended secret. The configuration administrator should not automatically read sensitive data. An unauthorized identity must be denied even when it reaches the private endpoint, while an authorized identity may still fail if DNS or firewall policy is wrong. Capture both permission and connectivity failures, because they require different corrections.
Next rotate a synthetic secret, confirm application rollout and observe the old version’s retirement. Delete a test certificate under a supported retention policy, verify the actual recovery procedure, and check that the restored object is usable by the intended service. Record which role performed each step and whether the outcome persisted after the test session ended.
For a secured Azure Key Vault, test three actors: an application identity allowed to retrieve one named secret, an operator allowed to change selected vault configuration but not read secret values, and an unauthorized principal attempting the same retrieval. After rotating a synthetic secret, verify that the application refreshed its cached value and can still authenticate to the real dependent service without a broad temporary role grant. This scenario also separates Key Vault data-plane denial from private-endpoint DNS or firewall failures. When evaluating independent SC-500 Key Vault practice scenarios, a defensible answer names the principal, data-plane operation, scope and negative test that proves an unauthorized identity cannot obtain a secret. A fluent response or successful control-plane change is not evidence of legitimate secret access.