Microsoft will retire Azure Network Policy Manager (NPM) for Windows nodes in Azure Kubernetes Service on September 30, 2026, leaving customers without a direct, Microsoft-supported replacement for pod-level network segmentation. The end-of-support means any AKS cluster running Windows workloads with NPM must migrate to an alternative policy engine or risk unmanaged—and potentially insecure—network policies after the deadline.

What’s Ending and When

Azure NPM has been the network policy engine for many AKS clusters since the service’s early days. But Microsoft is now steering all users toward its next-generation, eBPF-based Azure CNI powered by Cilium. The catch: Cilium network policy is only supported on Linux nodes. For Windows node pools, there is no official successor—only alternatives with limited support from Microsoft.

The retirement applies to all existing AKS clusters that have Windows node pools and use Azure NPM for network policy enforcement. New subscriptions can no longer onboard the feature; current users must migrate before the cutoff. After September 30, 2026, Microsoft will no longer provide support or updates for NPM on Windows nodes, and clusters still relying on it will be running unsupported configurations.

Why Replacing NPM with NSGs Alone Breaks Your Security Model

When faced with a retiring policy engine, the first instinct is often to shift enforcement to Azure Network Security Groups (NSGs). That approach can handle coarse, infrastructure-level controls—limiting access to a node’s SSH port, for example—but it fails at the primary job of a Kubernetes network policy: segmenting traffic between workloads based on labels.

Consider a rule that permits only pods with the label role=frontend to reach pods labeled role=api. NPM enforces this at the pod level, dynamically following the workloads as they scale and relocate across nodes. An NSG, in contrast, applies rules to a subnet’s or a network interface’s IP addresses. It can’t track pod labels, and it won’t automatically adjust when a pod is rescheduled to a different node.

“Using NSGs as a substitute for pod-level policies is like locking the front door of an apartment building but leaving every apartment door wide open,” says a senior cloud architect familiar with AKS security. “You get a perimeter defense, but zero isolation between tenants.”

For organizations that rely on fine-grained segmentation—isolating databases from web servers, enforcing zero-trust between microservices, or meeting compliance requirements—simply ticking the NSG box is a recipe for a breach. The only safe path is to preserve pod-level policies with a Kubernetes-native engine.

The Cilium Migration Path That Leaves Windows Behind

Microsoft’s official migration guide for NPM focuses exclusively on Linux. It details how to move to Azure CNI powered by Cilium, which brings performance gains, richer policy types, and full Kubernetes NetworkPolicy support. But the documentation is blunt: “Cilium Network Policy isn't currently supported for Windows nodes in AKS.”

That split creates a dangerous assumption in mixed-cluster environments. Teams that plan a single, cluster-wide migration to Cilium may discover too late that their Windows workloads lose all network policy enforcement—or worse, that the upgrade process itself breaks Windows node communication. “The Linux-only Cilium path forces every mixed-cluster operator to treat Windows as its own migration project,” notes an analysis by WindowsForum. “You cannot simply follow the Cilium playbook and declare the migration done.”

A Practical Migration Playbook for Windows Workloads

With no one-size-fits-all solution, AKS customers must take a phased, test-driven approach. Here’s a step-by-step breakdown, drawn from Microsoft’s guidance and real-world expertise from the AKS community.

1. Inventory Every Windows-Affected Cluster

Start by identifying which clusters actually use NPM on Windows nodes. Run:

az aks show --resource-group <rg> --name <cluster> --query "networkProfile.networkPolicy" -o tsv

If the output is azure, then NPM is active. Next, list all nodes and their operating systems:

kubectl get nodes -L kubernetes.io/os,agentpool

Every row with windows in the OS column is in scope. Export all NetworkPolicy objects from the cluster:

kubectl get networkpolicy --all-namespaces -o yaml > networkpolicy-inventory.yaml

2. Classify Every Policy by Intent

Not all policies need a Kubernetes-native replacement. Sort each rule into one of three buckets:

  • Workload-level segmentation (pod-to-pod based on labels, namespace isolation, default-deny posture) → needs a policy engine like Calico.
  • Infrastructure controls (restrict admin access to a node, limit egress to a corporate IP range, subnet-level boundaries) → can be moved to NSGs.
  • Shared-service dependencies (DNS, image registries, logging, storage) → require traffic testing before you decide.

Microsoft’s own NPM-to-Cilium guide warns that behavior can differ for ipBlock rules, egress to node IPs, and LoadBalancer/NodePort ingress. That caution applies doubly when switching engines, not just for Cilium. Validate every rule with live traffic, not just YAML comparisons.

3. Evaluate Calico as Your Windows Policy Engine

Microsoft’s network policy engine comparison lists three options: Cilium (Linux only), Azure NPM (retiring for Windows), and Project Calico. For Windows node pools, Calico is listed as supported on Windows Server 2019 and 2022 when using Azure CNI. But the support comes with caveats: Microsoft warns that many Calico features are untested and unsupported in AKS.

Before committing, confirm with Microsoft support exactly which Calico capabilities are covered under your SLA. Stick to the documented, tested AKS scenarios—typically basic Kubernetes NetworkPolicy enforcement using iptables mode. Advanced features like eBPF dataplane or DNS policies may work but could leave you without support if something breaks.

4. Separate Linux and Windows Migration Tracks

Mixed-cluster operators should run two parallel workstreams:

  • Linux lane: Follow Microsoft’s Cilium migration guide. Validate ipBlock, named port, and egress policy changes before and after the upgrade.
  • Windows lane: Decide per workload: move to Calico, redesign to run on Linux (if possible), isolate into a separate cluster with strict NSG-only controls, or accept the risk of no pod-level policy for a short period after expressly documenting it.

Resist the temptation to apply a single “cluster-wide” settings change. AKS allows only one network policy engine per cluster; if you enable Cilium, NPM is removed everywhere, leaving Windows workloads unprotected unless you’ve already activated Calico or switched to NSGs.

5. Build a Cutover Runbook with Traffic Tests

Months before the deadline, lock down a validation environment:

  • Freeze non-essential NetworkPolicy changes and commit your inventory YAML to source control.
  • Create a representative Windows test workload for each protected application tier.
  • Run positive and negative traffic tests: authorized frontend-to-API calls, blocked unauthorized access, DNS and platform dependency checks, external egress, and ingress through the normal exposure path.
  • Apply your proposed replacement (Calico policies, NSG rules, etc.) in a nonproduction cluster first, re-run all tests, and capture results.

Never delete the original NPM policies until the new enforcement proves both required access and expected denial behavior. And never use a temporary “allow any” rule as a cutover shortcut—it masks broken segmentation and can become a permanent hole.

Don’t Forget About Windows Server 2019

There’s a second, unrelated deadline that could compound your migration pain. AKS support for Windows Server 2019 node pools has already ended, and scaling consequences are set for April 1, 2027. If you’re still running 2019 nodes, now is the time to upgrade to Windows Server 2022 alongside your NPM migration. Tying the two projects together avoids a situation where you stabilize network policies only to hit a node support wall months later.

The Road Ahead for AKS Windows Networking

Microsoft has not announced any plans to bring Cilium networking to Windows, nor has it hinted at a new, first-party policy engine. The most likely path is deeper investment in Calico or a future Windows support update for Cilium, but neither is promised. For now, the AKS engineering team is clear: “Cilium Network Policy isn't currently supported for Windows nodes.”

The strongest outcome from this forced migration isn’t simply ticking a box before September 2026. It’s making sure that every traffic control—whether enforced by a Kubernetes policy or an NSG—still serves the security intent it was designed to protect. By starting now, with a clear inventory and a layered test plan, Windows workloads can survive the NPM sunset with their segmentation intact.