why azure services are using to call key vaults with old api version

Hello Reegan,

Greetings! Thanks for raising this question in the Q&A forum.

The key thing to separate out first is that this Key Vault API version retirement only applies to the control plane, meaning the API that creates or manages the vault resource itself, such as network rules, access policies, and vault properties through Azure Resource Manager. It does not apply to the data plane, meaning get secret, get key, or get certificate calls made directly against your vault URI. If the calls you are seeing in your logs are data plane calls, they are unrelated to this particular retirement and use a completely separate versioning scheme, so the first step is confirming which type of call you are actually looking at. When calls are still showing an old control plane API version and the caller is an Azure service rather than your own application, it almost always means a first party Microsoft service integration is calling your vault on your behalf as part of a feature you have enabled, and the API version those integrations use is controlled by the owning Microsoft service team, not by your own templates or code.

Confirm whether the old calls are control plane or data plane. Control plane calls target management.azure.com and affect vault configuration. Data plane calls target your vault URI directly, for example https://yourvault.vault.azure.net, and are used for secret, key, and certificate retrieval. Only control plane calls are affected by the 27 February 2027 retirement.

Identify the exact caller for each old-version call using Key Vault diagnostic logs. If diagnostic settings are sending logs to a Log Analytics workspace, run a query like this against the AzureDiagnostics or AZKeyVaultManagementLogs table to see the caller identity and API version together:

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where isnotempty(requestUri_s)
| extend apiVersion = tostring(split(requestUri_s, "api-version=")[1])
| project TimeGenerated, identity_claim_appid_g, callerIpAddress_s, OperationName, apiVersion
| order by TimeGenerated desc

1. Match the caller appId to a known first party service principal. Many built-in integrations, such as disk encryption sets, App Service managed certificates, Azure Backup, Azure Site Recovery, API Management, and Data Factory linked services, call your vault using their own service identity rather than yours. You can resolve an unfamiliar appId with:

az ad sp show --id <appId>

1. Check the Activity Log for control plane operations on the vault resource, since vault configuration changes are recorded there separately from the vault's own audit logs:

Azure Portal > your Key Vault resource > Activity log > filter Operation to "Update Key Vault" or "Create or Update Key Vault"

Review the Caller field on each entry to see whether it is your own account or service principal, or a Microsoft first party resource provider such as Microsoft.RecoveryServices, Microsoft.PolicyInsights, or Microsoft.Web.

Update anything the caller identity confirms belongs to you. If the caller is your own automation, such as an Azure DevOps pipeline, Terraform provider, Azure Automation runbook, Logic App connector, or an SDK used in custom code, update that component to a Key Vault SDK or provider version that targets API version 2026-02-01 or later.

Do not attempt to change API versions used by confirmed Microsoft first party integrations, since these are not exposed as a setting on your side and are updated by the owning service team on their own release schedule ahead of the retirement date. If audit or compliance requirements mean you need documented confirmation that a specific first party integration will be updated in time, open an Azure Support request referencing the specific resource provider or service you identified in step 3, and ask for confirmation of its Key Vault control plane API version compliance timeline.

Azure Portal > Help + support > Create a support request
Issue type: Technical
Service: Key Vault
Problem type: API version retirement / first party service compliance

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.