Microsoft has confirmed that Azure Network Policy Manager (NPM) on Windows nodes in Azure Kubernetes Service will lose support on September 30, 2026. For many Windows container teams, the retirement announcement arrives with a surprise: the recommended replacement, Cilium, is not available on Windows nodes. Instead of a single upgrade path, administrators face a choice among node-level network security groups, an independently managed Calico deployment, or a broader workload redesign.

The Retirement Window: What’s Changing and When

Azure NPM on Windows nodes enters its end-of-support phase on the last day of September 2026, according to Microsoft’s Azure Advisor retirement recommendations. New onboarding—activating NPM on fresh Windows node pools—is already disabled. Existing deployments can continue using NPM until the deadline, but Microsoft will no longer provide security maintenance, compatibility testing, or support for the feature after that date.

This is not a simple deprecation of an optional add-on. NPM has been the primary method for enforcing Kubernetes NetworkPolicy objects on Windows pods in AKS. Its removal takes away a fully managed component that many organizations have embedded in their cluster security posture. Microsoft’s advisory emphasizes that clusters can keep running NPM past the cutoff, but doing so means operating without the manufacturer’s backing—a particularly risky proposition for a policy engine that forms the backbone of pod-level network segmentation.

The September 2026 date gives teams roughly three years from the time the retirement appeared in public Azure documentation, though many will only learn of it through Advisor notifications. The real pressure point is not the final day, but the point at which a thoroughly tested replacement must be in place. And for Windows workloads, that test cycle will be longer than many expect.

Why Cilium Leaves Windows Nodes Behind

For Linux-based AKS clusters, the path from NPM to Cilium is well-documented. Microsoft’s own migration guide walks administrators through adopting Azure CNI Powered by Cilium and the Cilium Network Policy engine. The guide covers planning, execution, and validation—but it explicitly applies only to clusters without Windows node pools. As Microsoft states in its AKS documentation, Cilium Network Policy is not currently supported for Windows nodes, and a cluster that includes any Windows node pool cannot be updated to the Cilium data plane.

This limitation exists at the architectural level, not merely at the policy selection layer. NPM enforces rules by leveraging the Host Network Service (HNS) ACL policies on Windows, while on Linux it uses iptables under the hood. Cilium, built on eBPF and designed for Linux kernel capabilities, does not translate into the HNS-based world. A mixed-OS cluster therefore faces a hard block: the Windows pools prevent the entire cluster from moving to the Cilium data plane, even if the Linux system pool is fully compatible.

That reality frustrates a common assumption—that Cilium will eventually come to Windows. Microsoft has made no such commitment, and the retirement announcement for Windows NPM arrived without a parallel preview of a Windows-compatible Cilium offering. The strategic successor for Linux customers simply stops at the Windows boundary, leaving admins to find their own way forward.

The Three Migration Paths for Windows Node Pools

Windows teams must choose among three practical options, each with its own security, operational, and cost implications. Microsoft’s guidance points toward node-level Network Security Groups (NSGs) or the open-source Project Calico, but these represent fundamentally different operating models.

1. Node-Level NSGs: Simplicity with a Broader Brush

NSGs are Azure’s native network filtering mechanism, applied at the subnet or network interface. They can enforce allow/deny rules based on source and destination IP addresses, ports, and protocols—but they lack awareness of Kubernetes pod identities. This means NSGs cannot replicate pod-to-pod NetworkPolicy semantics directly. Instead, they protect at the node level: all pods on a node share the same network boundary.

For teams that have already separated Windows workloads into dedicated node pools by trust level or application function, NSGs can be a viable alternative. A dedicated pool hosting a single application tier might be sufficiently isolated through tightly scoped NSG rules that mirror the previous pod-level controls. The approach benefits from being fully managed within Azure and requiring no additional Kubernetes network-policy engine to operate and maintain.

The tradeoff is a loss of granularity. If multiple tenants or different application tiers colocate on the same Windows nodes, node-level NSGs create a broader trust zone. To compensate, operators often need to rearchitect placement: splitting workloads into separate node pools and possibly separate subnets. NSGs become a facility for redesigned segmentation rather than a direct, transparent replacement for NPM.

2. Calico: Keep Pod-Level Policy, Own the Engine

Project Calico supports Windows nodes with its own implementation of Kubernetes NetworkPolicy, plus additional Calico-specific policies. By deploying Calico independently on top of AKS, teams can retain pod-oriented network controls and a policy model that closely resembles what NPM offered.

The difference is that Microsoft does not manage Calico. Organizations take on full ownership of installation, upgrades, monitoring, troubleshooting, and compatibility testing. When a Kubernetes version bump or a Windows node update breaks policy enforcement, the response comes from in-house expertise—not from Azure support. Calico also requires attention during cluster lifecycle events such as scaling and node replacement, and it may behave differently from NPM even when interpreting the same Kubernetes NetworkPolicy resources. Thorough testing is not optional.

Calico is the strongest candidate where pod-level segmentation is non-negotiable and where the team already has deep Kubernetes networking skills. For groups that moved to AKS precisely to offload this kind of infrastructure responsibility, Calico introduces a new long-term maintenance burden that must be weighed against the benefits of continued pod-level policy.

3. Rethinking Windows: Workload Redesign or Separate Clusters

The retirement creates a concrete trigger to revisit why Windows node pools are in the picture at all. Some applications genuinely require Windows libraries or runtime behaviors. Others landed on Windows because it was the quickest migration path at the time, and the technical debt of that decision now surfaces as a platform constraint.

Moving eligible workloads to Linux opens the door to Cilium and Microsoft’s fully managed migration. This is not a simple node-selector change; it involves re-containerizing, retesting dependencies, and possibly reworking deployment manifests, storage, authentication, and observability. But for teams that have evaluated the effort, it can be a lower-risk path than committing to long-term ownership of Calico or accepting the coarser security boundaries of NSGs.

A lighter alternative is to separate Windows and Linux workloads into distinct AKS clusters. This removes the Cilium incompatibility block from the Linux side, allowing those clusters to adopt the recommended NPM-to-Cilium journey while the Windows cluster pursues NSGs or Calico independently. The overhead of managing an additional cluster is real, but it may be preferable to locking the entire estate into a workaround.

How We Got Here: A Brief History of Network Policy in AKS

When AKS launched, Azure NPM was introduced as a managed solution for Kubernetes network policies, using iptables on Linux and HNS on Windows. It provided a consistent, platform-supported way to enforce pod-level rules without deploying third-party agents. Over time, Microsoft invested in Cilium as its strategic data plane for Linux, first with Azure CNI powered by Cilium and later with Cilium Network Policy as a replacement for NPM.

Windows, however, followed a different trajectory. The HNS-based policy enforcement mechanism has no direct counterpart in the eBPF-centric Cilium architecture. Microsoft’s development efforts focused on bringing Cilium to Linux—and on expanding other networking options like overlay CNI—while Windows NPM remained in a maintenance mode. The retirement announcement, when it came in the Azure Advisor portal, formalized that divergence.

The September 2026 cutoff aligns with a broader wave of Microsoft services reaching end-of-support, including Azure Service Bus SBMP and legacy virtual machine families. For Windows container admins, this retirement is not an isolated event; it is part of a platform-wide shift that assumes Linux as the default for new cloud-native features. That assumption does not match every organization’s reality, but it sets the timeline for those who need to adapt.

What to Do Now: An Action Plan for the Transition

The deadline is support-based, not an automatic shutdown. But treating September 2026 as the day to start planning is dangerous. The work begins with a clear inventory and ends with a proven replacement running in production.

  1. Catalog affected clusters. Identify every AKS cluster that has Windows node pools and check whether NPM is enabled. Use Azure CLI or portal queries to build a complete list; do not assume some clusters are safe because they were set up years ago.
  2. Map existing policies to security requirements. Document which Kubernetes NetworkPolicy objects select Windows pods and, more importantly, what security boundary each policy enforces. Distinguish between mandatory isolation rules and auto-generated or template-driven policies that may not be critical.
  3. Evaluate the three options against each workload. For each Windows workload, assess whether node-level NSGs can meet the mandatory security boundaries, whether Calico is operationally feasible, or whether the workload can be moved to Linux or a separate cluster. The answer may differ across applications.
  4. Design the target architecture. If NSGs are chosen, plan for dedicated node pools and subnets to restore granularity. If Calico, assign ownership for installation, testing, and ongoing maintenance; budget time for a compatibility lab that simulates AKS upgrades, node patching, and failure scenarios.
  5. Run a genuinely representative test cycle. Validate allowed traffic and, critically, confirm that prohibited traffic is indeed blocked. Test under load, during node drains, and with policy updates in flight. Production-like tests will uncover behavioral differences between engines.
  6. Set internal milestones before September 2026. Aim to have the replacement running in a nonproduction environment by early 2026, with production cutover completed at least three months before the deadline. This leaves buffer for unforeseen issues.

What to Watch For

Microsoft’s retirement notices sometimes evolve. Keep an eye on the Azure Updates page and Advisor for any change in Windows Cilium support—though no hint of such a change exists today. Also watch for Calico compatibility advisories with future Windows Server releases and AKS Kubernetes versions. The September 2026 date coincides with other retirements, like Azure Service Bus SBMP, which may strain platform teams; coordinating responses across services will avoid deadline collisions. Finally, use the time to question the Windows container dependency itself: the 2026 milestone might be the forcing function that moves an organization toward a more consistent, manageable networking model across its entire AKS estate.