In this blog post Azure Arc Key Vault Extension Migration Before 2027 Retirement we will explain what is changing, why it matters and how to move without putting critical applications at risk.
If your business runs applications on Kubernetes outside Azure, there is a good chance passwords, certificates and connection details are being supplied through the Azure Key Vault Secrets Provider extension. It may be working reliably today, but Microsoft will retire that extension on 9 October 2027.
After that date, it will no longer receive security updates, bug fixes, new features or technical support. This is not a reason to panic, but it is a reason to start planning now. The migration affects identity, application configuration and the way sensitive information is stored inside each cluster.
What does this technology actually do?
Azure Arc connects Kubernetes clusters running in data centres, branch offices or other cloud platforms to Azure management services. It gives your team a central way to govern environments that are not physically hosted in Azure.
Kubernetes runs applications in containers. Those applications still need sensitive information such as database passwords, API keys and digital certificates. These items are collectively known as secrets.
Azure Key Vault provides a protected central location for those secrets. The retiring Azure Key Vault Secrets Provider extension retrieves them and makes them available to applications through a Container Storage Interface, or CSI, volume. In plain English, the secret appears as a protected file inside the application without being built into its software image.
Microsoft’s replacement is the Azure Key Vault Secret Store extension. It synchronises selected information from Key Vault into the Kubernetes secret store, where applications can consume it as a file or environment variable.
The replacement also uses workload identity federation. This lets an application prove its identity with short-lived tokens instead of keeping a long-lived client password inside the cluster.
Why this is more than an extension upgrade
The old and new extensions deliver secrets differently. Applications that currently expect a CSI-mounted file may need to be changed to read a Kubernetes Secret instead.
The identity model also changes. Your team must configure service accounts, managed identities and federated credentials so that each authorised application namespace can retrieve only the secrets it needs.
There is an availability benefit. The new extension keeps a local copy of synchronised secrets, so a temporary loss of access to Azure Key Vault does not necessarily stop an application from starting.
However, that local copy changes the security model. Kubernetes role-based access controls, cluster backups and encryption of the Kubernetes secret store must all be reviewed. Better offline resilience should not come at the cost of making passwords easier to retrieve from the cluster.
A practical six-stage migration plan
1. Build an inventory before changing anything
Start by identifying every Arc-enabled Kubernetes cluster using the retiring extension. Record the Key Vaults, namespaces, service accounts, applications and individual secrets involved.
Do not rely only on Azure Portal. Application deployment files, automation pipelines and configuration repositories may contain references that are not obvious from the cluster overview.
az k8s-extension list \
--cluster-type connectedClusters \
--cluster-name <cluster-name> \
--resource-group <resource-group> \
--output table
kubectl get secretproviderclass --all-namespaces
kubectl get serviceaccounts --all-namespaces
kubectl get secrets --all-namespacesThese commands are starting points, not a complete audit. Record secret names and ownership, but never export secret values into a spreadsheet, ticket or migration document.
2. Check whether each cluster is ready
The Secret Store extension requires Kubernetes 1.27 or later. Third-party clusters must also support workload identity federation and allow the Kubernetes service account issuer to be configured.
The Certificate Management for Azure Arc extension is required for protected communication between components inside the cluster. Existing open-source certificate managers may conflict with this requirement, so they need to be assessed before installation rather than removed without understanding what else depends on them.
Microsoft’s model is namespace-based. Plan for one service account and one federated credential for each namespace consuming secrets. A managed identity supports up to 20 federated credentials, so organisations with larger environments may require several managed identities.
3. Design access around business applications
Avoid recreating today’s permissions without questioning them. If a finance application only needs one database password, it should not receive access to an entire Key Vault containing credentials for other systems.
Group secrets by application, owner and risk level. Then assign the smallest practical permissions. This reduces the impact if an application or account is compromised.
The migration is also an opportunity to remove unused secrets and rotate credentials that have existed for years. While secret management alone does not deliver Essential 8 compliance, it supports the broader goal of limiting credential theft and privileged access. Essential 8 is the Australian government’s cybersecurity framework that many organisations use to reduce common attack risks.
4. Test on a separate non-production cluster
Microsoft advises against running the old and new extensions together on the same cluster. That makes a separate non-production test especially important.
Your pilot should represent a real workload, not a demonstration application that has no business impact. Test application startup, secret rotation, pod restarts, cluster upgrades and temporary loss of connectivity to Azure Key Vault.
Also test the failure cases. What happens when an identity loses access, a secret is renamed or the synchronisation process stops? Your monitoring should detect these problems before an employee or customer reports an outage.
5. Plan the production cutover application by application
The production change may require removing the old extension before enabling the replacement. Treat this as a controlled cutover with an approved maintenance window, clear responsibilities and a tested recovery plan.
Update application deployment files so they use the new Kubernetes Secrets. Store those changes in version control, have them independently reviewed and confirm that no secret values have been accidentally committed.
Prioritise applications based on business impact. Start with a low-risk internal workload, learn from it and then migrate customer-facing or revenue-critical systems. Do not leave every production cluster for the final quarter before retirement.
6. Verify, clean up and document the result
A successful deployment is not the same as a successful migration. Confirm that each application can retrieve its secrets, permissions remain appropriately restricted and rotation works within the expected period.
Remove obsolete service-principal passwords, old Kubernetes Secrets and unused permissions after the rollback window closes. Leaving the old credentials behind preserves the very risk the new identity model is intended to reduce.
Update operating procedures as well. Your support team needs to know how to diagnose failed synchronisation, expired certificates, identity problems and Key Vault access errors.
What this could look like in a typical business
Consider a 200-person logistics company running three Arc-enabled Kubernetes clusters across a Melbourne data centre and two operational sites. Twelve applications share secrets from several Key Vaults, but nobody has a complete record of which application uses which credential.
A rushed migration could cause warehouse, billing or tracking applications to start without their required database credentials. A structured inventory might also reveal that several applications share an overly powerful service principal with a password created years ago.
By moving one application group at a time, the company can replace that shared password with short-lived identities, restrict access by namespace and test offline behaviour at each site. The outcome is not merely a supported extension. It is lower credential risk and a clearer understanding of application dependencies.
Set an internal deadline well before October 2027
A sensible target is to complete discovery by December 2026, finish a non-production pilot by March 2027 and migrate most production workloads by June 2027. July to September can then be reserved for complex applications, recovery testing and issues that were not visible during discovery.
This approach leaves breathing room before 9 October 2027. It follows the same principle we recommend for other fixed Azure deadlines, including avoiding Azure App Service certificate renewal surprises and planning SAP security changes before connector retirement.
If Azure Arc is becoming part of a wider hybrid infrastructure strategy, it is also worth reviewing how it can support recovery and management without re-platforming existing servers. Secret management should be designed as part of that wider operating model, not as an isolated technical task.
Start with discovery, not deletion
The immediate action is not to uninstall the existing extension. It is to find where it is used, confirm which clusters meet the new requirements and establish who owns each affected application.
CloudPro Inc is a Melbourne-based Microsoft Partner and Wiz Security Integrator with more than 20 years of enterprise IT experience. Our team works hands-on across Azure, Microsoft Defender, Wiz and hybrid infrastructure rather than handing clients to a large, faceless support queue.
If you are not sure which Arc clusters or applications are affected, we are happy to help you assess the current setup and build a practical migration plan before the deadline becomes an emergency.