Microsoft announced general availability for Certificate Management on Azure Arc-enabled Kubernetes on September 1, 2026.

The release packages the CNCF-graduated cert-manager and trust-manager projects as a single Microsoft-managed Azure Arc extension. Instead of treating certificate issuance, renewal, trust-bundle distribution, patching, and support as a locally assembled set of Kubernetes components, teams can deploy one supported extension per connected cluster.

For distributed edge estates, that is more than a convenience. Certificate expiration and inconsistent trust stores are common sources of hard-to-diagnose application outages. A centrally operated platform needs a repeatable way to issue and rotate workload certificates while keeping the correct certificate-authority trust roots available wherever applications need them.

What the Extension Brings Together

The Certificate Management extension installs Microsoft-supported cert-manager and trust-manager components on an Arc-enabled Kubernetes cluster.

The two parts solve connected but different problems:

• cert-manager requests, issues, renews, and rotates certificates for Kubernetes workloads and cluster components.

• trust-manager distributes CA certificates as trust bundles to the namespaces that need them.

That distinction matters. A workload can possess a valid certificate and still fail TLS connections if its clients do not trust the issuer. A working certificate lifecycle needs both a private-key and certificate path, plus a reliable trust-distribution path.

The extension gives administrators a supported package for those capabilities rather than requiring every site to standardize, patch, and troubleshoot separate open-source installations alone.

A Kubernetes-Native Workflow Still Applies

Managed does not mean invisible. The workload model remains Kubernetes-native.

After the extension is installed, a team configures an `Issuer` or `ClusterIssuer` to define the certificate authority that should sign requests. A `Certificate` resource then asks for a certificate, and cert-manager stores the signed certificate and private key in a Kubernetes secret for the workload to use.

For shared trust roots, a `Bundle` resource lets trust-manager distribute CA data into ConfigMaps in the relevant target namespaces.

That means platform teams should define clear ownership:

• The platform team owns the extension, upgrades, guardrails, and observability.

• The security or PKI team owns acceptable issuers, key policy, and trust-root governance.

• Application teams own their `Certificate`, `Issuer` references, ingress or gateway integration, and workload consumption of secrets.

Without those ownership boundaries, certificate management can simply move from shell scripts into unmanaged custom resources.

Why GA Matters at the Edge

The GA announcement is aimed at production edge fleets, including distributed environments in manufacturing and retail. These sites may have uneven connectivity, different Kubernetes distributions, constrained local support, and a mixture of hardware architectures.

Microsoft highlights several GA characteristics:

• Production support under standard Microsoft support agreements.

• Automatic certificate issuance, renewal, and rotation.

• Trust-bundle distribution without manually copying ConfigMaps.

• Operation through temporary disconnection, so existing certificates and bundles continue to function when an edge cluster temporarily loses connectivity to Azure.

• Validation across a broad set of Arc-enabled Kubernetes distributions.

• ARM64 support for ARM-based edge hardware.

An important operational nuance: “continues to function while disconnected” does not mean a site can ignore expiration. Certificate lifetime, renewal window, issuer reachability, and the period of disconnection still have to be designed together. A cluster that misses a required renewal interval because its issuer is unreachable can still create an outage.

Choose the Issuer for Production, Not the Demo

The Azure Arc documentation shows a self-signed issuer as a useful learning and testing path. It also explicitly warns that self-signed certificates are not recommended for production ingress and egress scenarios.

For production, use an issuer aligned to the organization's PKI strategy, such as an approved enterprise CA or a suitable ACME or Vault-based design. Decide these questions before rolling out the extension:

• Which teams may create an `Issuer` or `ClusterIssuer`?

• Which domains and namespaces may request certificates?

• What key algorithms, sizes, lifetimes, and rotation policies are allowed?

• Which CA roots are eligible for trust-bundle distribution?

• How are private keys protected, backed up where appropriate, and rotated after a suspected compromise?

• What alert fires when an upcoming renewal, issuer, or bundle propagation operation fails?

The extension automates lifecycle tasks. It cannot decide which issuer is trustworthy or which application should receive a certificate.

Migration Is a Change Window, Not a Side-by-Side Experiment

Many clusters already run upstream cert-manager or trust-manager. Microsoft documentation describes the Arc extension as a replacement for both.

Before deployment, inventory the existing controllers, Helm releases, CRDs, issuers, certificates, secrets, and bundle resources. Plan the change carefully, because running competing controllers against the same custom resources can produce ambiguous ownership and hard-to-predict behavior.

Microsoft's documented migration flow warns that there is a period between removing the open-source components and installing the Arc extension in which certificate rotation does not occur and new trust bundles are not distributed. Existing certificates and resources remain, but the transition should be as short as possible.

Treat migration as a maintenance activity:

1. Export the certificate and trust configuration inventory. 2. Confirm certificate expiration headroom before the change window. 3. Validate the extension on a representative nonproduction cluster. 4. Remove the old controller resources according to the documented migration sequence. 5. Install and verify the Arc extension. 6. Confirm the controller pods, a known certificate renewal path, and target-namespace ConfigMaps. 7. Keep a rollback and incident path that is tested, not theoretical.

Observability Must Cover Both Sides of TLS

Start with the extension installation status and controller health in the `cert-manager` namespace. The Azure Arc troubleshooting guidance recommends checking the cert-manager controller, webhook, CA injector, and trust-manager pods.

Then observe the Kubernetes resources that an application actually depends on:

• `Certificate` readiness and renewal events.

• `Issuer` and `ClusterIssuer` health.

• Secret creation and update time.

• `Bundle` status and propagation into target ConfigMaps.

• Ingress or Gateway events that reference the issued certificate.

• Application-side TLS errors, especially unknown-authority failures.

Alerting only on certificate expiration is too late. A useful early signal is a failed issuance or a bundle that did not reach its target namespace while there is still time to repair it.

Validate the Distribution and Region Matrix

The GA post reports broad regional and distribution coverage, including AKS Edge Essentials, AKS on Azure Local, Red Hat OpenShift, SUSE Rancher RKE2, VMware Tanzu, and K3s. The supported versions and regional availability can change as releases advance.

Before standardizing the extension, check the current validation list for each Kubernetes distribution, control-plane version, region, and architecture in the fleet. A policy that works on a central, always-connected cluster should not be assumed to work identically on every low-bandwidth ARM64 site.

Who Should Care?

• Platform engineers responsible for Arc-enabled Kubernetes at many sites.

• Security and PKI teams trying to remove manual trust-store drift.

• Edge operators who need certificates to keep working through temporary Azure disconnection.

• Application teams exposing services through Kubernetes ingress or Gateway APIs.

Practical Cloud Engineer Takeaway

GA turns Azure Arc Certificate Management into a production-supported choice for standardizing certificate and trust-bundle operations across connected Kubernetes fleets.

Start with an issuer and migration design, not the extension command. Then test renewal, trust propagation, and an offline edge scenario as part of the acceptance criteria. The goal is predictable TLS operations, not simply fewer Helm charts.

Bottom Line

Azure Arc's Certificate Management extension brings cert-manager and trust-manager together in one supported service for hybrid and edge Kubernetes.

It can sharply reduce certificate-lifecycle and trust-distribution toil, provided organizations retain discipline around PKI policy, controller migration, observability, and the operational realities of intermittently connected sites.

Sources

Microsoft Azure Arc Blog, published September 1, 2026: https://techcommunity.microsoft.com/blog/azurearcblog/generally-available-certificate-management-for-azure-arc-enabled-kubernetes/4542769

Microsoft Learn, cert-manager for Arc-enabled Kubernetes overview: https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/cert-manager-overview

Microsoft Learn, deployment and migration guidance: https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/cert-manager-deploy

---

Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.

Chriz Beyond Cloud with Chriz