Azure Key Vault API 2026-03-01-preview retirement – How to identify affected service?

Treat 2026-03-01-preview as a Key Vault control-plane dependency and replace every customer-controlled use with stable API version 2026-02-01; use the Service Health advisory’s impacted-resource details or Azure Support to attribute usage that cannot be found in your code or telemetry.

1. Check the personalized advisory first

In Azure portal:

1. Open Service Health.
2. Select Health advisories, then open tracking ID SH8B-Q4G.
3. Review Impacted resources, Impacted subscriptions, Updates, and any recommended-action attachment.
4. Export or record the listed resource IDs.

Service Health advisories are personalized communications about changes that might affect resources in your subscriptions. Events remain in Health history for up to 90 days after becoming inactive.^1^

The public Key Vault documentation confirms that 2026-03-01-preview is a control-plane preview version and that preview users should move to stable 2026-02-01. It describes preview deprecation with 90 days’ notice, although it does not publish the specific January 31, 2027 date from SH8B-Q4G.^2^

This is distinct from the broader retirement of control-plane versions earlier than 2026-02-01 on February 27, 2027.^3^

2. Inventory customer-controlled callers

Search deployment repositories, pipelines, runbooks, Functions, Logic Apps, and custom tooling:

rg -n "2026-03-01-preview|Microsoft\.KeyVault/vaults" .
rg -n "management\.azure\.com.*Microsoft\.KeyVault" .
rg -n "Azure\.ResourceManager\.KeyVault|azure-mgmt-keyvault" .
rg -n "@azure/arm-keyvault|azure-resourcemanager-keyvault" .
rg -n "armkeyvault|Microsoft\.KeyVault" .

Check each client type:

• ARM/Bicep: Change Microsoft.KeyVault/vaults@2026-03-01-preview or its apiVersion to 2026-02-01.
• REST/AzAPI/custom Terraform: Replace ?api-version=2026-03-01-preview.
• Standard Terraform AzureRM resources: Inspect the AzureRM provider version and lock file, then review its release notes or generated behavior. Standard Terraform configuration might not contain an explicit apiVersion.
• Management SDKs: Upgrade to:
  • .NET Azure.ResourceManager.KeyVault 1.4.0 or later
  • Go armkeyvault v2
  • JavaScript @azure/arm-keyvault, Python azure-mgmt-keyvault, and Java azure-resourcemanager-keyvault: latest supported release.^2^
• CLI and PowerShell: Inventory installed versions, then update them to current supported releases:

az version
Get-InstalledModule -Name Az
Get-InstalledModule -Name Az.KeyVault

An SDK can choose the API version internally, so absence of the literal string does not rule it out.^3^

3. What existing logs can establish

Since Activity Log and Resource Graph have already been checked, inspect the JSON for relevant Microsoft.KeyVault/vaults events for:

• caller identity or service principal
• correlation ID
• operation name
• timestamp
• resource ID

Activity Log records subscription-level control-plane operations, but it might not expose the API version selected by the client. It therefore cannot reliably prove that a caller used 2026-03-01-preview.

Key Vault AuditEvent logs are not a reliable mechanism for attributing Azure Resource Manager control-plane calls to management.azure.com. They are useful for future Key Vault request auditing and can contain operationVersion, identity, request URI, caller IP, and client information, but resource logs do not exist retrospectively unless a diagnostic setting was already configured.^4^^5^

Consequently, there is no supported way to reconstruct the missing historical requests from Key Vault diagnostics now. Enabling AuditEvent is still useful for future data-plane auditing, but it should not be expected to identify this ARM control-plane caller.

4. Could Dev Box be the caller?

It is possible for an Azure managed service to make control-plane calls, but the available Dev Box documentation does not establish that Dev Box uses this Key Vault preview API.

Dev boxes themselves run in a Microsoft-managed subscription under the hosted-on-behalf architecture, while customer-managed Dev Center resources and network components can exist in your subscription.^6^

Therefore:

• If the matching deployment, SDK, script, or identity is yours, update it.
• If no customer-controlled caller is found, open an Azure Support request referencing SH8B-Q4G, the affected subscription/resource IDs, UTC timestamps, and correlation IDs.
• Ask Support to confirm whether the detection originated from Microsoft Dev Box or another Microsoft-managed resource provider and whether Microsoft owns the API migration.

Do not assume Microsoft will update it automatically until Support confirms ownership for this specific advisory.

5. Required actions

1. Migrate customer-controlled callers to stable 2026-02-01.
2. Test vault create/update, network rules, RBAC configuration, and Dev Box provisioning in nonproduction.
3. Keep the Service Health advisory and a support case as the authoritative path for unattributed managed-service usage.
4. Separately plan for Microsoft Dev Box retirement on September 18, 2028; existing deployments are temporary while workflows transition to Windows 365 or another solution.^7^

References

1. Azure Service Health portal
2. What's new for Azure Key Vault | Microsoft Learn
3. Update the Azure Key Vault API version you use
4. Monitor Azure Key Vault
5. Azure Key Vault logging
6. Microsoft Dev Box architecture and key concepts
7. Microsoft Dev Box retirement guide