AKS retires Azure NPM on Windows nodes on September 30, and the Cilium path stops at the Linux boundary
On September 30, 2026, Azure Kubernetes Service stops supporting Azure Network Policy Manager on Windows nodes. But the recommended Cilium Network Policy migration remains Linux-only: inventory your Windows pools and choose between node NSGs, self-managed Calico, or a Linux migration before the deadline.
September 30, 2026. Azure Kubernetes Service stops supporting Azure Network Policy Manager (NPM) on Windows nodes. July 18, 2026. Microsoft published the retirement notice and already closed new onboarding. September 2026. The official NPM → Cilium migration guide states it applies only to Linux clusters. Why it matters: the recommended migration path dead-ends exactly where Windows-heavy organizations need it most, one week from the deadline.
A retirement whose exit door is locked for Windows
The mechanics of the retirement are simple: Azure NPM disappears from Windows nodes in AKS on September 30, 2026. Deployments already onboarded can keep using it until that date, but new onboarding is closed. The logical next step, on Microsoft’s side, is to migrate to Cilium Network Policy, carried by Azure CNI Powered by Cilium.
Except that path hits a technical boundary. Azure CNI Powered by Cilium and Cilium Network Policy remain Linux-only in AKS. Microsoft states it plainly: Cilium Network Policy is not currently supported for Windows nodes, and AKS cannot update a cluster containing Windows node pools to the Cilium data plane.
The consequence is architectural, not cosmetic. A mixed cluster whose system pool is Linux cannot be migrated to Cilium while a Windows pool exists. The team that thought “migrate the cluster” discovers the blocker applies to the whole cluster, not merely to policies selecting Windows pods.
Why Cilium cannot replace NPM on Windows
The reason lies in how each operating system enforces network policy. On Linux, Azure NPM relies on iptables; Cilium replaces that layer with an eBPF data plane specific to Linux. On Windows, policy enforcement goes through Host Network Service (HNS) ACLs — a completely different path.
Cilium is not an interchangeable implementation of that HNS path. Its AKS data plane is built around Linux capabilities; it cannot “translate” rules into the HNS ACLs of Windows nodes. The retirement of NPM therefore leaves no equivalent managed successor for Windows — it is a retirement, not a simple agent swap.
The eBPF strategy behind the retirement
The retirement of Azure NPM is not a scheduling accident: it is part of AKS’s deliberate shift to an eBPF data plane. Cilium, built on eBPF, is becoming the platform’s strategic networking path, with its observability and performance benefits. NPM, built on iptables, is the legacy layer Microsoft is gradually unwinding.
The problem is not the direction — it is the asymmetry of the transition. Linux workloads get a managed, documented, tested successor. Windows workloads are sent toward node NSGs or self-managed Calico — two options that hand the team a share of the responsibility that NPM used to absorb. And September 30 is not an isolated date: the same day carries other Azure retirements (notably BlobFuse v1, Azure Functions v3 on Linux Consumption, and Azure Virtual Desktop Classic). A team running a heterogeneous estate may face several simultaneous deadlines on the same day — the inventory must cover the whole estate, not just AKS.
Three exits, none transparent
For Windows clusters, three options remain, and none is a drop-in migration.
Node-level Network Security Groups. This is the most Azure-native alternative Microsoft points to. An NSG filters at the subnet or network-interface level, not the pod level. It can suffice when Windows nodes are already separated by trust level or application. But if multiple tenants or sensitivity tiers share the same nodes, replacing pod-level policy with node-level filtering broadens the trust zone — the NSG looks restrictive while protecting less finely. Choosing NSGs also means redrawing workload placement into dedicated pools to recover the lost boundaries.
Self-managed Project Calico. This is Microsoft’s other named direction. Calico preserves the pod-level policy model — closer to what NPM users already know — but the keyword is “open source”: the organization inherits the component’s deployment, upgrades, monitoring, and support. There must be a clear answer to “who responds when policy behaves differently after a Kubernetes or Windows node update.” Calico is the right call when pod-to-pod segmentation is non-negotiable and the team has the networking expertise to operate it; it is a poor fit for teams that adopted AKS precisely to minimize that responsibility.
Redesign the workload. The last exit, often the cheapest long-term: eliminate the Windows node dependency — move to Linux, another platform, or a separate architecture — before the deadline. For a legacy workload kept alive by inertia, the cost of a rewrite can be lower than the recurring cost of self-managed Calico.
None of the three is a mechanical switch. NSGs give you the boundary only if you also fix placement; Calico gives you pod-level policy only if you accept its lifecycle; redesign gives you the cleanest end-state only if you can absorb the rewrite. The trap is treating the retirement as a deadline to pick a tool, when it is really a deadline to make an architectural commitment.
What to do before September 30
The deadline is a week away: diagnosis comes before tool selection.
Inventory. List every AKS cluster containing Windows pools and check whether Azure NPM is enabled. Without an inventory, you will discover the retirement the day a policy stops being enforced.
Map the real boundaries. Identify which NetworkPolicy resources select workloads scheduled on those pools, and document the security boundary each one guarantees — the ones that are mandatory, not those inherited from a standard template. A cluster with dozens of generated policies may depend on only a few meaningful isolation rules.
Decide in order. If the node boundary is sufficient, go with NSGs and dedicated pools. If pod-to-pod segmentation remains mandatory, evaluate Calico and assign its lifecycle. If neither holds, start the Linux migration before the date. Then validate the choice in non-production, testing both permitted traffic and traffic that must be denied.
A Windows cluster that passes the deadline without action does not fall over all at once: NPM may keep applying rules for a while, but with no fixes and no support. The real risk is the same as any retired component — a node or Kubernetes version upgrade that breaks the policy-enforcement path, and a team that discovers the gap in production. September 30 is not the day everything stops; it is the day responsibility shifts entirely onto your side.
Verdict
Microsoft retired Azure NPM on Windows nodes while naming a successor — Cilium — that does not work on Windows. This is not an oversight; it is a strategy: the platform is pushing toward the eBPF data plane and leaving Windows workloads to bear the cost of the transition. The honest framing for an operator is that there is no managed drop-in replacement for what is being taken away. If you run Windows pools under AKS, do not treat this retirement as a routine agent upgrade: it is an architecture decision. Inventory your clusters, measure the real security boundaries, then choose between node NSGs, self-managed Calico, or a Linux migration — before September 30, not after.