I've already covered Arc Site Manager and portal-driven fleet ops and rack-aware clustering from the 2608 release. There are two more items in the same release family worth pulling apart, because both touch Key Vault and KMS, both sound like the same story at a glance, and confusing them will get you the wrong answer when a compliance team asks "so who can read our secrets?"
Story one: multi-rack gets a real bring-your-own-key lever
The multi-rack what's-new page for Azure Local 1.5 (shipping alongside 2608) lists this, verbatim:
Customer-managed public key encryption for Azure Key Vault (API 2026-08-01-preview): You can now provide a public key that the cluster uses to encrypt secrets before they're stored in Azure Key Vault. You're responsible for managing the corresponding private key required to decrypt the secrets.
Read that carefully, because it's a different control than the "customer-managed key" phrase usually means in Azure. This isn't Key Vault encrypting its own contents with a key you host in another vault — it's the Azure Local cluster encrypting the secret before it ever leaves the cluster, using a public key you supplied. Key Vault ends up storing ciphertext it cannot decrypt on its own. Only whoever holds the matching private key — which Microsoft explicitly says is your responsibility, not theirs — can read the plaintext back.
That's a meaningfully stronger sovereignty claim than "your data is encrypted at rest." It's closer to: even someone with full administrative access to the Key Vault instance gets nothing useful without a key that never touched Microsoft's infrastructure. For multi-rack deployments — which already require an ExpressRoute-connected Key Vault, Log Analytics workspace, and storage account as documented prerequisites — this closes a gap that's come up constantly in sovereignty conversations: "we accept that management plane calls Azure, but we do not accept that Azure can read our secrets."
Story two: AKS Arc's KMS v1 warning, and how long it's actually been sitting there
Separately, under "AKS enabled by Azure Arc changes" in the same Azure Local 2608 what's-new page, this line appears:
KMS v1 is deprecated soon. KMS v2 is included in this Azure Local release. Plan on redeploying your clusters by using KMS v2.
This is a completely different layer from story one. It's about how AKS enabled by Azure Arc encrypts Kubernetes secrets at rest inside etcd — the standard Kubernetes KMS provider mechanism, not Key Vault's own secret storage. KMS v2 replaces serial per-secret decryption at cluster startup with envelope encryption and automatic key rotation, which is a real operational improvement. None of that is in question.
What's worth flagging is how long the warning itself has been sitting there unchanged. Checking the same what's-new page's historical release entries:
- As of the 2509 release, the language was forward-looking: "KMS v1 is deprecated. We're adding support for KMS v2 in an upcoming Azure Local release."
- From release 2510 onward — 2510, 2602, and now 2608, spanning roughly a year of monthly releases — the wording has been identical every single time: "KMS v1 is deprecated soon. KMS v2 is included in this Azure Local release. Plan on redeploying your clusters by using KMS v2."
No hard cutover date has appeared in any of those entries. KMS v1 clusters, as far as the published changelog shows, still work in 2608. And the phrasing — "plan on redeploying your clusters" — is doing real work: standard cloud AKS offers an in-place az aks update path to move between KMS versions without rebuilding the cluster. Azure Local's own AKS Arc documentation doesn't describe an equivalent in-place migration; the changelog's own wording points at redeployment instead.
Why keeping these two straight matters
If you're building the sovereignty argument for a client or a compliance review, story one is a genuine, citable control: customer-held key, cluster-side encryption, Microsoft locked out by design. Story two is the opposite kind of fact to have on hand — it's evidence that if you're running AKS Arc workloads on Azure Local, you may still be on a Kubernetes secrets encryption scheme that Microsoft has been calling "deprecated soon" for the better part of a year, with no forced migration and no in-place tooling documented to get off it. That's not a reason to panic; KMS v1 hasn't been pulled. It is a reason to check which one your clusters are actually running, rather than assuming a monthly platform update handled it for you.
What's not answered yet
- No key-custody guidance for the multi-rack BYOK feature. The what's-new entry points to the multi-rack security concepts article for more detail, but as of this writing that article doesn't yet describe the feature at all — no guidance on key rotation, backup, or what happens operationally if the private key is lost. "You're responsible for managing" the private key currently means exactly that and nothing more.
- Scope is multi-rack only. This BYOK capability is specific to the SAN-backed, ExpressRoute-connected multi-rack architecture. It isn't available on standard single-site or rack-aware Azure Local deployments, which remain on platform-managed keys for local disk encryption.
- No published cutover date for KMS v1. Nothing in the 2608 release notes commits to a date after which KMS v1 stops being supported, despite "deprecated soon" appearing in release after release since 2510.
- No documented in-place migration path for Azure Local's AKS Arc. Unlike cloud AKS, the guidance is to redeploy — which is a materially bigger ask for a cluster running production workloads at a disconnected or regulated site.
Who should care
Architects specifying multi-rack Azure Local for regulated workloads now have a real answer to "can Microsoft read our secrets" — evaluate it, but budget time for the key-custody process yourself, since Microsoft hasn't published one. Anyone running AKS enabled by Azure Arc on Azure Local should check today which KMS version their clusters are actually on, and treat "redeploying" as the real, non-trivial cost of moving to KMS v2 rather than something a platform update will quietly do for you.
I'm tracking both of these for the lab list: whether the multi-rack BYOK feature gets real documentation before it hits GA, and whether KMS v1 gets an actual retirement date in a future release. If you want that follow-up, or you're weighing the multi-rack architecture against a simpler rack-aware deployment right now, subscribe to Sovereign Cloud Watch or find me on LinkedIn.