The short version
Microsoft will retire Azure Linux with OS Guard on Azure Kubernetes Service on December 10, 2026. On that date you will not be able to create new OS Guard node pools, and existing ones stop receiving support. The stated replacement is Azure Container Linux, which went generally available on AKS starting with AKS v1.34. The announcement landed quietly in the Azure Updates feed on September 11, but the migration work it implies is not trivial for anyone running OS Guard in production.
If you have never heard of OS Guard, you are probably in the clear. It shipped as a preview-only OS SKU on AKS, so its installed base is small. But preview or not, a hard retirement date is a hard retirement date, and the teams running it picked it for a reason.
Why OS Guard existed
Azure Linux with OS Guard was the security-hardened variant of Microsoft’s homegrown Linux distribution. Its main draw was kernel-level code integrity through Integrity Policy Enforcement, an IPE Linux security module. In plain terms: only binaries from trusted, signed volumes were allowed to execute, verified at boot and at runtime against the OS image. If your threat model included tampering with node binaries, that guarantee was the point.
The second selling point was a small attack surface. The image shipped only what a container host needs, which meant fewer packages, fewer services, and fewer entry points for attackers.
The replacement, and the gap in it
Azure Container Linux is Microsoft’s new unified immutable host offering. It is built downstream of the Flatcar Container Linux project, which Microsoft picked up in preview in November 2025, combined with Azure Linux packages and platform integration. Like OS Guard, it enforces immutability of the /usr directory and verifies image integrity at boot. It also requires Trusted Launch with Secure Boot and vTPM, so check your VM SKU support before planning the migration. On Arm64 it only works with Cobalt-based v6 SKUs.
Here is the catch worth knowing before you migrate. The Microsoft Learn documentation states plainly that OS Guard preview features, specifically code integrity with IPE, are not currently supported in Azure Container Linux. They will be incorporated in a future release, and only after that will OS Guard fully retire. If IPE code integrity is why you chose OS Guard, migrating today means giving up that control until the features land in ACL. Microsoft’s own guidance is to keep using OS Guard until then if you need those features, which sits awkwardly next to the December 10 retirement date. Plan around the tension rather than pretending it does not exist.
Azure Container Linux generally resolves the gap in most other ways. Weekly node image releases follow the date-based versioning scheme, in-place OS SKU migration is supported for moving existing node pools, and rollback paths are documented. Flatcar itself is not being retired, only the AKS preview SKU.
How the migration paths compare
Microsoft documents two routes to Azure Container Linux: in-place OS SKU migration on existing node pools, or creating new ACL node pools and draining the old ones. The in-place path is the lower-effort option and the one most teams will try first. It reimages nodes onto the new OS, which means every pod on the node gets rescheduled, so the same disruption rules apply as any node image upgrade: pod disruption budgets, surge settings, and stateful workload placement all matter. The documentation includes rollback instructions, which is worth reading before you start rather than after something breaks.
The new-node-pool route costs more cluster capacity during the transition but gives you a clean comparison point. You can run a small ACL pool alongside the OS Guard pool, shift workloads gradually, and compare behavior before committing. For production clusters, this is the safer shape even if it is slower.
One more constraint to check: ACL node pools require Trusted Launch, so any VM size in use that lacks Secure Boot and vTPM support needs to change as part of the migration. On Arm64, only Cobalt-based v6 SKUs are supported. Teams running on older Dv4 or Dsv4-series capacity in particular regions should verify availability before committing to a cutover date.
What to actually do
Start with an inventory. Run a node pool listing across your subscriptions and look for the OS Guard SKU. Microsoft’s AKS release notes show the pattern from earlier OS retirements: first new pool creation stops, then at a later date existing node images get removed and scaling or reimage operations start failing. The same sequence applied to Azure Linux 2.0 and to Flatcar Container Linux for AKS, whose images were removed on September 8, 2026.
If you run OS Guard outside production, test Azure Container Linux now. In-place SKU migration exists, but it still deserves a staging pass: verify your DaemonSets, security agents, and node-level tooling all behave on an immutable /usr layout with Trusted Launch enforced. Some endpoint protection agents have opinions about read-only system directories.
If you run it in production and rely on IPE code integrity, you have a genuine decision to make. Either wait for the features to arrive in Azure Container Linux and watch the calendar, or move early and replace that control with a compensating one, for example stricter container image signing policies. Either way, December 10 is the deadline, and the audit trail for choosing an option is worth writing down now.
Why this matters beyond one SKU
This is the third Linux host consolidation on AKS in about a year: Azure Linux 2.0 retired, Flatcar preview absorbed into ACL, and now OS Guard folded in. Microsoft is clearly converging on a single immutable container host, which is easier to secure and patch at scale. The cost lands on anyone who picked a specialized SKU for its specific guarantees. If you are on AKS and have not inventoried your OS SKUs lately, this is your prompt.