AKS Windows NPM Ends Sept. 30, 2026: Keep Pod Policies, Not NSGs

AKS clusters with Windows workloads should not treat Azure Network Policy Manager’s September 30, 2026 retirement as an NSG replacement exercise. The safe pre-cutover task is to classify every traffic control by where it is enforced and what it protects: retain NetworkPolicies that provide pod-label-based segmentation, and move only genuine node, subnet, or infrastructure controls to Network Security Groups (NSGs). This guidance applies to AKS clusters that already use Azure NPM with Windows nodes.

Why an NSG-only plan can break Windows workload isolation​

Kubernetes NetworkPolicy selects pods by labels and controls the traffic they may send or receive. Without policies, pods in an AKS cluster can communicate freely by default. That is fundamentally different from an NSG rule, which is an Azure infrastructure control rather than a Kubernetes workload-identity control.
For example, a policy that permits only pods labeled role=frontend to reach pods labeled role=api expresses an application-segmentation requirement. Replacing it with an NSG rule may protect a subnet or node boundary, but it does not preserve a rule that follows dynamically scheduled pods and their Kubernetes labels.
This distinction matters because AKS will no longer support Azure NPM on Windows nodes beginning September 30, 2026. The retirement applies to customers already onboarded to NPM; subscriptions not registered for the feature can no longer onboard. Microsoft points customers toward node-level NSGs or open-source tools such as Project Calico, but those are alternatives with different enforcement models—not interchangeable policy engines.
For broader timing and support implications, see WindowsForum’s AKS Windows NPM retirement coverage.

Start with an exposure inventory, not a replacement product​

Before changing networking, build a register that answers four questions for each AKS cluster:

1. Does the cluster use Azure NPM?
2. Does it have Windows node pools?
3. Which namespaces contain NetworkPolicy objects?
4. Which policies control Windows-hosted workloads, cross-platform traffic, or only Linux workloads?

Run these checks from an administrator workstation with Azure CLI access to the subscription and kubectl access to the cluster.

1. Identify the configured AKS network-policy engine:

az aks show --resource-group <resource-group> --name <cluster-name> --query "networkProfile.networkPolicy" --output tsv
Record clusters reporting azure, which denotes Azure NPM.

1. List node operating systems and pools:

kubectl get nodes -L kubernetes.io/os,agentpool
Record every node identified as windows, along with its pool name.

1. Export all NetworkPolicy objects:

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

1. Produce a readable policy list for review:

kubectl get networkpolicy --all-namespaces

1. For every deployment, daemon set, stateful set, job, and cron job that is expected to run on Windows, record:

• Namespace and workload name.
• Pod labels.
• Node selector, affinity, tolerations, or other scheduling constraints.
• Ingress dependencies: callers, ports, and protocols.
• Egress dependencies: DNS, databases, APIs, fileshares, identity services, update endpoints, and external services.
• The NetworkPolicies that select its labels, directly or indirectly.

Do not assume that a NetworkPolicy in a namespace affects Windows pods. A policy only matters if its podSelector matches the labels on a Windows-scheduled workload. Conversely, do not assume a policy is Linux-only because its YAML has no operating-system reference; scheduling can change over time.

Classify each rule by enforcement point and intent​

Use a worksheet with one row per meaningful traffic requirement, rather than one row per YAML object. A single policy can contain several requirements that need different replacements.

Workload-level segmentation: preserve it with a policy engine​

Keep a requirement in the Kubernetes policy category when it depends on any of the following:

• Source or destination pod labels.
• Namespace labels or namespace identity.
• A default-deny posture for a namespace or application tier.
• Isolation between front end, API, worker, queue, and database workloads.
• Allowing only selected in-cluster callers to use a service.
• Rules expected to continue working as pods are replaced, scaled, or scheduled onto different nodes.

These are not good NSG candidates. They need a Windows-capable Kubernetes NetworkPolicy approach.
Microsoft lists Cilium, Azure NPM, and Calico as AKS policy engines, but Cilium support in that comparison is Linux-only. Calico is listed for Linux, Windows Server 2019, and Windows Server 2022 with Azure CNI; Microsoft also cautions that many Calico capabilities are not tested or supported by AKS.
The practical conclusion is clear: a mixed Linux/Windows cluster cannot use the standard Linux NPM-to-Cilium migration as a complete Windows NPM retirement plan. Treat Windows policy continuity as its own workstream.

Infrastructure controls: consider NSGs​

An NSG may be appropriate when the purpose is deliberately coarse and tied to Azure infrastructure, such as:

• Limiting which administrative or corporate networks may reach node-level services.
• Limiting ingress or egress at a subnet or node interface boundary.
• Applying a shared network perimeter rule that does not depend on Kubernetes labels.
• Restricting access between network segments where per-pod identity is not required.

Document the replacement as an infrastructure control, not as a migrated NetworkPolicy. Its scope, exceptions, and ownership may belong to the Azure networking team rather than the platform team.

Shared-service and external dependencies: test rather than translate​

Policies that allow DNS, identity, logging, monitoring, image pulls, storage, or external APIs often look simple in YAML but can be difficult to classify. They may involve pod-to-service, pod-to-node, node-to-pod, or pod-to-external traffic.
Mark these as traffic-test required. Do not declare them safely replaced by reviewing selectors and CIDRs alone.
Microsoft’s Linux NPM-to-Cilium guidance warns that behavior can differ for ipBlock, node-IP egress, and LoadBalancer or NodePort ingress enforcement. Although that migration guidance is not a Windows cutover procedure, it demonstrates why an engine substitution must be validated with live traffic tests rather than YAML comparison alone.

Choose a mixed-cluster cutover architecture deliberately​

For a mixed Linux/Windows AKS cluster, separate the target state into two lanes:

1. Linux lane: evaluate Microsoft’s documented Cilium migration path if it fits the cluster’s Linux workloads and support plan.
2. Windows lane: decide whether each Windows workload-level policy requires a Windows-capable policy engine, a workload redesign, or a consciously accepted reduction to infrastructure-level controls.

Do not let a Linux migration decision implicitly choose the Windows design. Cilium’s Linux-only support means it cannot supply the same Windows-node policy enforcement in the AKS engine comparison.
Calico is the obvious policy-engine option to assess for Windows continuity because AKS lists Windows support with Azure CNI. However, “supported platform” is not permission to assume every open-source Calico feature is supported by AKS. Limit the design to the documented, tested AKS scenario and get support-boundary confirmation before standardizing on advanced capabilities.
Also separate the NPM retirement from Windows operating-system planning. Windows Server 2019 node pools are already outside AKS support, with further scaling consequences scheduled for April 1, 2027. Review the Windows Server 2019 node-pool timeline alongside this project so that a policy cutover does not preserve an unsupported node strategy.

Run a September 30 contingency and validation plan​

Create a cutover runbook now, even if the final policy-engine choice is not approved.

1. Freeze nonessential NetworkPolicy changes and store the exported YAML in version control.
2. Label each policy requirement as:

• Preserve with Kubernetes policy.
• Replace with NSG or another infrastructure control.
• Retire because it is obsolete.
• Requires traffic test and owner decision.

1. Build a representative Windows test workload for each protected application tier.
2. Test approved traffic and denied traffic separately:

• Front end to API.
• Unauthorized pod to API.
• API to database or queue.
• DNS and required platform dependencies.
• External egress.
• Ingress through the application’s normal exposure path.

1. Capture expected results before the change: successful requests, rejected requests, application logs, and monitoring signals.
2. Apply the proposed replacement only in a nonproduction environment first.
3. Re-run the same tests after every engine, NSG, node-pool, or routing change.
4. Do not remove the original NetworkPolicy definitions from source control until the replacement proves both required access and expected denial behavior.

Warning: Avoid broad “allow any” rules as a temporary cutover shortcut. They can hide a failed segmentation design, and later teams may mistake emergency access for an intended security baseline.
If a policy cannot be reproduced on Windows with an approved support model, the contingency decision must be explicit: postpone the workload move, redesign the workload boundary, isolate it in a separate cluster or network segment, or accept the narrower NSG-only control with documented risk ownership.

Frequently Asked Questions​

Can NSGs replace all AKS NetworkPolicies?​

No. NSGs can be useful for node or subnet-level controls, but they do not preserve policies based on Kubernetes pod labels or namespace selection. Use NSGs for infrastructure intent, not as an assumed one-for-one replacement for workload segmentation.

Can we migrate Windows NPM policies to Cilium?​

Not as a complete Windows-node solution under Microsoft’s AKS engine support comparison, which lists Cilium for Linux. Plan Linux and Windows policy transitions separately.

Are existing Windows NPM policies fully portable to another engine?​

Do not assume so. Azure NPM for Windows lacks support for named ports, SCTP, negative-match label or namespace selectors, and CIDR except blocks; engine behavior and enforcement details still require traffic validation.

What is the immediate deadline?​

AKS support for Azure NPM on Windows nodes ends on September 30, 2026. The immediate deliverable is an inventory that distinguishes pod-level policy requirements from infrastructure-level rules, followed by tested replacement decisions for every Windows workload.
The strongest outcome is not simply removing NPM before the deadline; it is retaining the security intent that mattered. By making enforcement point and policy intent the first classification step, AKS teams can use NSGs where they fit, preserve pod segmentation where it is required, and avoid discovering after cutover that a node rule never replaced a workload policy.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Migrate from Network Policy Manager (NPM) to Cilium Network Policy - Azure Kubernetes Service | Microsoft Learn

   This article is a comprehensive guide to plan, execute, and validate the migration from Network Policy Manager (NPM) to Cilium Network Policy

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   AKS Ends Azure NPM Support on Windows Nodes September 30, 2026 | Windows Forum

   Azure Kubernetes Service will stop supporting Azure Network Policy Manager on Windows nodes on September 30, 2026, but Windows administrators cannot simply...

   windowsforum.com