If you run secrets into Arc-enabled Kubernetes clusters — including AKS on Azure Local — from Azure Key Vault, you've probably used the Azure Key Vault Secrets Provider extension (AKV SPE). On October 9, 2026, Microsoft's retirement notice gave it a firm end date: October 9, 2027. The guidance is to migrate to the newer Secret Store extension (SSE). That's a reasonable-sounding instruction right up until you read what SSE is actually scoped to support.
What SSE is built for — and it's a good fit for Azure Local, on paper
SSE's own overview page is explicit about who it's for:
The Azure Key Vault Secret Store extension for Kubernetes (SSE) automatically synchronizes secrets from an Azure Key Vault to an Azure Arc-enabled Kubernetes cluster for offline access. [...] We recommend the Secret Store extension for clusters outside of Azure cloud where connectivity to Azure Key Vault may not be perfect.
Supported distributions list AKS on Azure Local and AKS Edge Essentials by name, alongside OpenShift Kubernetes Distribution and VMware Tanzu Kubernetes Grid. SSE also authenticates with workload identity federation instead of long-lived service principal credentials, and it keeps a local copy of each secret in the cluster's own secret store — which is precisely the resilience property a disconnected site needs when its link to Azure Key Vault is intermittent or absent. On the technical merits, this is a real improvement over AKV SPE for the exact scenario Azure Local disconnected operations describes.
The line that undoes it for sovereign clouds
The migration guide's considerations section includes this, with no elaboration beyond the sentence itself:
Sovereign clouds aren't supported. SSE doesn't accept acloudNameparameter. Use the Azure Key Vault Secrets Provider extension'scloudNamefor vaults inAzureUSGovernmentCloudorAzureChinaCloud.
Read that literally: it names exactly two non-public clouds as the extension's escape hatch — US Government and China — and offers no parameter for anything else. There's no EU sovereign cloud variant listed, no National Partner Cloud variant, nothing. SSE's authentication story depends on Microsoft Entra ID issuing and validating short-lived tokens through workload identity federation against the public commercial cloud's identity plane; without a cloudName switch, there's no documented way to point that federation at a different cloud instance at all. The feature Microsoft recommends specifically for disconnected, edge, and sovereign-leaning deployments is, by its own documentation, unusable the moment that deployment also needs to target anything other than public Azure or the two named US/China government clouds.
Why the retirement clock makes this worse than a documentation gap
A missing parameter in a preview feature is a roadmap conversation. A missing parameter in the mandatory migration target for a feature with a published retirement date is an operational problem with a deadline attached. AKV SPE — the extension that does carry a working cloudName — is the one being retired. Its replacement is the one with the gap. If your Arc-enabled Kubernetes clusters sit in a sovereign or national cloud context today and lean on AKV SPE's cloudName to reach that cloud's Key Vault, the October 2027 deadline currently has no supported destination to migrate to within SSE's documented scope.
To be precise about what isn't claimed here: Microsoft hasn't said SSE will never support a cloudName parameter, and a year is enough time for that gap to close. What the current documentation does establish, as of this writing, is that the gap exists today, on the only migration path Microsoft has published for a retiring extension.
What's not answered yet
- No stated plan for sovereign-cloud support in SSE. The migration guide names the limitation but doesn't reference a roadmap item, preview flag, or target release for closing it.
- No guidance for Arc clusters already using AKV SPE's
cloudNametoday. The retirement notice and the migration guide both assume a same-cloud migration; neither addresses what a cluster pointed at a non-Gov, non-China sovereign Key Vault should do before October 2027. - Migration itself is disruptive, independent of the cloud question. The guide is explicit that AKV SPE and SSE "aren't supported side by side in the same cluster," so even a same-cloud migration requires a planned switchover window, not a rolling update.
- AKVSync, the simplified single-resource configuration style, is still preview — only the more verbose
SecretProviderClass+SecretSyncpairing is generally available today.
Who should care
Anyone running Arc-enabled Kubernetes — AKS on Azure Local especially — against a sovereign or national cloud's Key Vault should check, this quarter, whether that path depends on AKV SPE's cloudName parameter. If it does, the October 2027 deadline is not a comfortable distance away once you account for a disruptive switchover window and, on current documentation, no supported destination. This is also a clean example of why "disconnected" and "sovereign" get treated as the same requirement when they aren't: SSE solves disconnected beautifully and sovereign not at all, in the same release.
I'm tracking whether a cloudName equivalent lands in SSE before the AKV SPE deadline, and I'll publish the moment the documentation changes either way. If you're planning an Arc secrets migration against a sovereign cloud boundary right now, subscribe to Sovereign Cloud Watch or find me on LinkedIn.