Security teams should treat the runtime shift as a control transition, not just an infrastructure upgrade. They need automated workload protection on every new node, image assurance checks, runtime threat prevention, and network segmentation that follows the workload. The goal is to preserve policy enforcement while Windows containers move into containerd node pools and remain protected from unauthorized execution and lateral movement.
Windows containers on AKS: what changes when Dockershim is replaced by containerd
The important shift is not only the runtime name. On AKS, the move from Dockershim to containerd changes where teams should anchor control enforcement for Windows container workloads, especially around image trust, runtime inspection, and node-level hardening. Security teams need to assume the workload will continue to move, while the control plane for prevention and detection must stay consistent across node pools.
That matters because Windows container security is often only as strong as the controls attached to the node pool. If policy was implicitly riding on Docker-specific assumptions, the migration can create blind spots during rollout, patching, and scale events. The practical goal is to keep the same protection outcomes while the execution layer changes underneath them.
How to preserve protection across the migration
Start by treating each Windows node pool as a distinct enforcement boundary. The runtime transition should not be allowed to weaken image approval, admission decisions, or runtime telemetry just because the platform team is changing the container engine. Security controls need to be validated against the new node image, the new scheduling pattern, and the Windows host configuration that containerd depends on.
Image assurance is especially important during the cutover. Teams should verify provenance, scan for vulnerabilities, and block known-bad or unsigned artifacts before they land on the new pools. The same discipline should extend to registry access, because a migration often increases image pulls, rebuilds, and redeployments, which expands the blast radius of a weak image source or stale tag policy.
Runtime protection also needs to remain active on every migrated node. If the security stack previously relied on Docker-specific hooks or assumptions, confirm that process monitoring, file integrity signals, suspicious child process detection, and prevention rules still work when containerd is the runtime. This is where many migrations fail quietly: workloads still run, but detection depth drops.
Network controls should follow the workload rather than the old runtime model. Windows containers that move into new node pools should keep the same segmentation assumptions, with east-west traffic restricted to what the application actually needs. That reduces the chance that a migration becomes an opportunity for lateral movement between workloads or across namespaces.
What Windows container teams need to verify before and after cutover
The most useful verification is operational, not theoretical. Confirm that the migrated workload can still be deployed, observed, and constrained with the same policy outcomes on containerd that it had on the previous runtime. Then test the failure paths: blocked images, denied execution, and attempted network access outside the approved path.
Containerd migrations can also expose drift in Windows node configuration. Security teams should check host patch level, kernel compatibility, container feature support, and the exact placement of host agents that provide runtime visibility. A security tool that is present but not correctly attached to the new node pool is effectively absent.
Where possible, align the migration with a clean inventory of which workloads still depend on legacy runtime behavior. That lets teams separate genuine application exceptions from control gaps. If a workload only works because a legacy Docker behavior is still being tolerated, it should be treated as a remediation item, not as a successful migration outcome.
How to reduce risk without slowing the migration
The right balance is to standardise on controls that are runtime-agnostic where possible, then validate the few places where Windows and AKS make the migration sensitive. In practice that means policy at deployment time, detection at runtime, and segmentation at the network layer, with each control confirmed on the new node pools before the old runtime is retired.
Security teams should also plan for operational overlap. During the transition, there may be mixed node pools, parallel images, and temporary exceptions. Those conditions are acceptable only if they are time-bounded and visible. A migration window without explicit expiry and ownership often becomes the place where weak controls persist long after the cutover.
Risk and Threat Considerations
The main risk is that a runtime migration creates a false sense of security: the workload still launches, but enforcement depth, telemetry quality, or segmentation assumptions no longer match the old environment. That can leave Windows containers exposed to unauthorized execution, secret abuse, or lateral movement during and after cutover.
Failure mechanism: Control logic tied to the old runtime, incomplete agent coverage on new nodes, or missing network restrictions can let a workload run outside the intended security envelope while appearing healthy to operators.
Impact: Attackers or misconfigured workloads can gain broader execution paths, weaker containment, and easier movement across container boundaries or node pools, especially during mixed-runtime migration periods.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Windows containers authenticate as workload-like nonhuman execution contexts. |
| SI-3 — Malicious Code Protection | Image assurance and runtime prevention both depend on code and artifact inspection. | |
| Recommendation — Enforce workload authentication controls for container-to-service access on migrated nodes. Apply malicious code protections to container images and runtime execution paths. | ||
| NIST Zero Trust (SP 800-207) | PR.AC-4 — Access decisions are dynamic and resource-specific | Segmentation and runtime enforcement must follow the workload as node pools change. |
| Recommendation — Make access and network decisions per workload and per node pool during migration. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Containerd cutover requires consistent hardened configuration on every Windows node. |
| CIS-10 — Data Recovery | Migration windows benefit from rollback and recovery planning when runtime changes affect workloads. | |
| Recommendation — Harden and verify each Windows node pool before shifting workloads to containerd. Validate rollback and recovery procedures before decommissioning legacy runtime dependencies. | ||
Practitioner Guidance
What to verify: Treat the migration as successful only when the new containerd-based Windows pools still enforce the same image, runtime, and network controls that were required before the move. If the control is only “present” but not tested on the new node pool, do not assume it is effective.
What to prioritise: Validate runtime protection and segmentation first, then review image assurance and host agent placement. Those are the controls most likely to fail silently during a runtime transition, and they are the ones that most directly affect blast radius if a workload is abused.
Practitioner takeaway: The safest migration pattern is to preserve the security boundary at the workload level and treat containerd as a control revalidation event, not a simple platform swap.
Related resources from NHI Mgmt Group
- How should teams secure non-human identities across cloud and SaaS?
- How should security teams decide whether JIT access is safe for non-human identities?
- How should teams combine SAST and DAST in a secure development programme?
- What do security teams get wrong about secure collaboration during incidents?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
