Azure Kubernetes Service will stop supporting Azure Network Policy Manager on Windows nodes on September 30, 2026, but Windows administrators cannot simply follow Microsoft’s standard NPM-to-Cilium migration playbook. Azure CNI Powered by Cilium and Cilium Network Policy remain Linux-only in AKS, making Cilium not a Windows migration path; affected teams must instead adopt node-level Network Security Groups, operate Project Calico independently, or redesign workloads to eliminate their Windows node dependency.
Microsoft’s AKS documentation says the retirement applies to customers already onboarded to Azure NPM, while new onboarding is no longer available. Existing deployments can continue using NPM until September 30, 2026, but organizations that wait until the deadline risk turning a network-policy retirement into an emergency platform migration.
For Linux-based AKS clusters, Microsoft has a relatively direct strategic answer: migrate from Azure NPM to Cilium Network Policy on Azure CNI Powered by Cilium. Microsoft’s migration guide describes how to plan, execute, and validate that transition, including moving the cluster to the Cilium data plane.
That guidance explicitly applies only to Linux-node clusters. Microsoft states that Cilium Network Policy is not currently supported for Windows nodes in AKS, and AKS cannot update a cluster containing Windows node pools to the Cilium data plane.
This distinction matters in mixed-OS clusters. A team may view its Linux system pool as the cluster’s networking foundation and assume that Cilium can coexist with Windows user pools, but the Windows pools prevent the documented cluster update. The blocker therefore applies at the cluster architecture level, not merely to policies selecting Windows pods.
Microsoft’s positioning can create a misleadingly simple migration narrative: Azure NPM is retiring, Cilium is the strategic successor, and administrators should migrate. That sequence is valid for eligible Linux clusters, but it breaks precisely where Windows-heavy organizations need it most.
The technical divide reflects how policy is enforced on each operating system. Azure NPM uses iptables on Linux, while Windows enforcement relies on Host Network Service ACL policies. Cilium’s AKS data plane is built around Linux capabilities and is not an interchangeable implementation of the HNS path used by Windows nodes.
Administrators should consequently treat this as an architecture decision, not a network-agent upgrade.
Teams should make the decision in this order:
The tradeoff is granularity. An NSG protects at the subnet or network-interface level rather than acting as a direct replacement for pod-selecting Kubernetes NetworkPolicy rules. It may be sufficient when Windows nodes are already separated by trust level, application function, environment, or subnet, but it should not be described internally as a transparent NPM migration.
NSGs are strongest when the node pool itself is an acceptable security boundary. A dedicated Windows pool hosting one application tier may be protectable through tightly scoped network rules, particularly if its required traffic paths are stable and well documented.
They are less convincing when multiple tenants, application tiers, or differently trusted workloads share the same Windows nodes. In that design, replacing pod-level policy with node-level filtering can broaden the effective trust zone even if the resulting NSG configuration appears restrictive.
Teams choosing NSGs should therefore redesign placement alongside filtering. Separating workloads into dedicated node pools or network segments may be necessary to recover boundaries that Azure NPM previously enforced closer to individual pods.
The operational catch is contained in the phrase open source. This is not the same as AKS automatically replacing Azure NPM with a fully managed Microsoft successor for Windows. The organization must evaluate how Calico will be deployed, upgraded, monitored, tested, and supported throughout the cluster lifecycle.
That changes the ownership model. Platform teams need a clear answer for who responds when policy enforcement behaves differently after a Kubernetes or Windows node update, who validates compatibility before cluster upgrades, and who tracks security maintenance for the independently operated component.
Policy compatibility also needs testing rather than assumption. Even when two engines consume Kubernetes NetworkPolicy resources, implementation behavior and platform integration should be validated against the organization’s actual allow and deny cases.
Calico is consequently the stronger candidate where pod-level segmentation remains non-negotiable and the organization already has the Kubernetes networking expertise to operate it. It may be a poor fit for teams that adopted AKS specifically to minimize responsibility for cluster networking internals.
Some applications may remain tied to Windows libraries, runtime assumptions, or operational processes. Others may have been placed on Windows because that was the shortest initial migration path rather than a permanent technical requirement.
Moving eligible workloads to Linux would make Microsoft’s documented NPM-to-Cilium route available, but this should not be reduced to changing a node selector. Container images, application dependencies, deployment manifests, storage behavior, authentication, observability, and operational procedures may all need review.
Another option is platform separation. A mixed cluster can appear efficient, but Cilium’s cluster-level incompatibility with Windows pools means one Windows dependency can constrain networking choices for every Linux workload in that cluster. Placing Windows and Linux workloads in separate clusters may allow Linux services to adopt Cilium while the Windows environment uses NSGs, Calico, or a different hosting model.
This is similar to other fixed Microsoft retirement deadlines facing administrators, including the September 30, 2026 Azure Service Bus SBMP cutoff. The dangerous assumption is that a supported successor will preserve the old architecture; in practice, retirement work often exposes dependencies that require application changes rather than a component swap.
That distinction should not be used as permission to delay. An unsupported network-policy engine is particularly difficult to justify because its purpose is security enforcement. Continued apparent operation does not answer whether future AKS changes, Windows node servicing, or deployment operations will remain compatible.
New onboarding has already closed, which also limits recovery options. Teams cannot safely plan to reproduce an old NPM configuration in a replacement subscription or newly created environment later. The remaining window is for exiting the dependency, not expanding it.
The most important milestone is therefore not September 30 itself. It is the date by which the organization can test its chosen replacement under production-like traffic, failure, scaling, and maintenance conditions.
Windows-heavy AKS environments now face a choice Microsoft’s Linux migration guide cannot make for them: accept broader node-level boundaries with NSGs, take direct responsibility for Calico, or reshape the platform around workloads that can move off Windows. By September 30, 2026, that choice needs to be implemented and proven—not merely recorded in a retirement backlog.
Microsoft’s AKS documentation says the retirement applies to customers already onboarded to Azure NPM, while new onboarding is no longer available. Existing deployments can continue using NPM until September 30, 2026, but organizations that wait until the deadline risk turning a network-policy retirement into an emergency platform migration.
The Recommended Replacement Stops at the Windows Boundary
For Linux-based AKS clusters, Microsoft has a relatively direct strategic answer: migrate from Azure NPM to Cilium Network Policy on Azure CNI Powered by Cilium. Microsoft’s migration guide describes how to plan, execute, and validate that transition, including moving the cluster to the Cilium data plane.That guidance explicitly applies only to Linux-node clusters. Microsoft states that Cilium Network Policy is not currently supported for Windows nodes in AKS, and AKS cannot update a cluster containing Windows node pools to the Cilium data plane.
This distinction matters in mixed-OS clusters. A team may view its Linux system pool as the cluster’s networking foundation and assume that Cilium can coexist with Windows user pools, but the Windows pools prevent the documented cluster update. The blocker therefore applies at the cluster architecture level, not merely to policies selecting Windows pods.
Microsoft’s positioning can create a misleadingly simple migration narrative: Azure NPM is retiring, Cilium is the strategic successor, and administrators should migrate. That sequence is valid for eligible Linux clusters, but it breaks precisely where Windows-heavy organizations need it most.
The technical divide reflects how policy is enforced on each operating system. Azure NPM uses iptables on Linux, while Windows enforcement relies on Host Network Service ACL policies. Cilium’s AKS data plane is built around Linux capabilities and is not an interchangeable implementation of the HNS path used by Windows nodes.
Administrators should consequently treat this as an architecture decision, not a network-agent upgrade.
Windows Teams Have Three Real Choices
The correct response depends on whether an organization needs pod-level segmentation, can accept node-level controls, and expects Windows containers to remain strategic. Microsoft directs Windows-node customers toward node-level Network Security Groups or open-source Project Calico, but those alternatives represent materially different operating models.Teams should make the decision in this order:
- Inventory every AKS cluster containing Windows node pools and determine whether Azure NPM is enabled.
- Identify which existing Kubernetes NetworkPolicy objects select workloads scheduled on those Windows pools.
- Document the security boundary each policy currently provides, including which controls are mandatory rather than merely inherited from a standard template.
- Decide whether node-level NSGs can reproduce the required boundary without pod-level enforcement.
- If pod-level policy remains necessary, evaluate an independently operated Calico deployment and assign ownership for its lifecycle.
- If neither model meets operational or security requirements, begin moving the workload to Linux, another platform, or a separate architecture before the retirement date.
- Validate the selected design in a nonproduction environment and test both permitted traffic and traffic that must be denied.
Node-Level NSGs Trade Precision for Simplicity
Network Security Groups are the most Azure-native alternative identified by Microsoft for affected Windows deployments. They can control network traffic around the nodes and their Azure network boundaries without introducing another Kubernetes network-policy engine.The tradeoff is granularity. An NSG protects at the subnet or network-interface level rather than acting as a direct replacement for pod-selecting Kubernetes NetworkPolicy rules. It may be sufficient when Windows nodes are already separated by trust level, application function, environment, or subnet, but it should not be described internally as a transparent NPM migration.
NSGs are strongest when the node pool itself is an acceptable security boundary. A dedicated Windows pool hosting one application tier may be protectable through tightly scoped network rules, particularly if its required traffic paths are stable and well documented.
They are less convincing when multiple tenants, application tiers, or differently trusted workloads share the same Windows nodes. In that design, replacing pod-level policy with node-level filtering can broaden the effective trust zone even if the resulting NSG configuration appears restrictive.
Teams choosing NSGs should therefore redesign placement alongside filtering. Separating workloads into dedicated node pools or network segments may be necessary to recover boundaries that Azure NPM previously enforced closer to individual pods.
Calico Preserves the Policy Model but Transfers Ownership
Project Calico is Microsoft’s other named direction for retaining a supported or security-maintained setup around Windows workloads. It is closer conceptually to the Kubernetes policy model that NPM users already understand because it can preserve pod-oriented network-policy enforcement rather than moving the boundary entirely to Azure infrastructure.The operational catch is contained in the phrase open source. This is not the same as AKS automatically replacing Azure NPM with a fully managed Microsoft successor for Windows. The organization must evaluate how Calico will be deployed, upgraded, monitored, tested, and supported throughout the cluster lifecycle.
That changes the ownership model. Platform teams need a clear answer for who responds when policy enforcement behaves differently after a Kubernetes or Windows node update, who validates compatibility before cluster upgrades, and who tracks security maintenance for the independently operated component.
Policy compatibility also needs testing rather than assumption. Even when two engines consume Kubernetes NetworkPolicy resources, implementation behavior and platform integration should be validated against the organization’s actual allow and deny cases.
Calico is consequently the stronger candidate where pod-level segmentation remains non-negotiable and the organization already has the Kubernetes networking expertise to operate it. It may be a poor fit for teams that adopted AKS specifically to minimize responsibility for cluster networking internals.
Workload Redesign May Be the Lower-Risk Migration
The third choice is to remove the requirement that created the dead end: Windows node pools. That does not mean every Windows container can be quickly rebuilt for Linux, but the NPM retirement gives teams a concrete reason to revisit whether the operating-system dependency is still necessary.Some applications may remain tied to Windows libraries, runtime assumptions, or operational processes. Others may have been placed on Windows because that was the shortest initial migration path rather than a permanent technical requirement.
Moving eligible workloads to Linux would make Microsoft’s documented NPM-to-Cilium route available, but this should not be reduced to changing a node selector. Container images, application dependencies, deployment manifests, storage behavior, authentication, observability, and operational procedures may all need review.
Another option is platform separation. A mixed cluster can appear efficient, but Cilium’s cluster-level incompatibility with Windows pools means one Windows dependency can constrain networking choices for every Linux workload in that cluster. Placing Windows and Linux workloads in separate clusters may allow Linux services to adopt Cilium while the Windows environment uses NSGs, Calico, or a different hosting model.
This is similar to other fixed Microsoft retirement deadlines facing administrators, including the September 30, 2026 Azure Service Bus SBMP cutoff. The dangerous assumption is that a supported successor will preserve the old architecture; in practice, retirement work often exposes dependencies that require application changes rather than a component swap.
The Deadline Is About Support, Not Instant Disappearance
Microsoft says AKS will no longer support Azure NPM on Windows nodes beginning September 30, 2026. The stated consequence is the loss of a supported, security-maintained, and deployment-compatible setup—not a documented promise that every existing policy will suddenly vanish at midnight.That distinction should not be used as permission to delay. An unsupported network-policy engine is particularly difficult to justify because its purpose is security enforcement. Continued apparent operation does not answer whether future AKS changes, Windows node servicing, or deployment operations will remain compatible.
New onboarding has already closed, which also limits recovery options. Teams cannot safely plan to reproduce an old NPM configuration in a replacement subscription or newly created environment later. The remaining window is for exiting the dependency, not expanding it.
The most important milestone is therefore not September 30 itself. It is the date by which the organization can test its chosen replacement under production-like traffic, failure, scaling, and maintenance conditions.
Windows-heavy AKS environments now face a choice Microsoft’s Linux migration guide cannot make for them: accept broader node-level boundaries with NSGs, take direct responsibility for Calico, or reshape the platform around workloads that can move off Windows. By September 30, 2026, that choice needs to be implemented and proven—not merely recorded in a retirement backlog.
References
- Primary source: learn.microsoft.com
Use Service Upgrade and Retirement recommendations - Azure Advisor | Microsoft Learn
Use recommendations for retirement and upgrade of a servicelearn.microsoft.com - Independent coverage: kubernetes.io
Networking on Windows | Kubernetes
Kubernetes supports running nodes on either Linux or Windows. You can mix both kinds of node within a single cluster. This page provides an overview to networking specific to the Windows operating system. Container networking on WindowsNetworking for Windows containers is exposed through CNI...
kubernetes.io
- Independent coverage: azure.microsoft.com
- Primary source: WindowsForum
Azure Service Bus: Stop SBMP Outages Before September 30, 2026 | Windows Forum
Microsoft’s September 30, 2026 Azure Service Bus deadline creates two different risks: Windows workloads still using SBMP will stop communicating, while...windowsforum.com