How should teams implement zero trust on virtual machines without moving everything into Kubernetes first?

Why zero trust on VMs is usually a network and policy problem first

On virtual machines, zero trust does not require a platform migration before it becomes useful. The practical objective is to stop assuming that traffic is safe because it sits inside the same network or cloud account. Instead, each connection should be authenticated, encrypted, and allowed only when policy says that specific service-to-service path is legitimate.

That makes the VM estate a good fit for a service mesh or mesh proxy pattern that runs alongside existing applications. The control point moves closer to the workload, while policy remains centralized. That lets teams tighten east-west access without rewriting every application or waiting for a Kubernetes control plane to become the default operating model.

A useful way to think about the architecture is that zero trust is not tied to orchestration, it is tied to policy enforcement, identity-aware access decisions, and continuous verification. On VMs, the enforcement layer may be sidecars, node agents, host agents, or network proxies, but the underlying requirement is the same: remove ambient trust and make each hop prove itself.

That also means the migration question is often a sequencing question, not a prerequisite question. If the current application topology is still VM-based, teams can introduce zero trust at the transport and policy layers now, then decide later whether Kubernetes, containers, or other packaging choices make operations easier. The security outcome should not depend on a platform rewrite to begin reducing lateral movement risk.

What the VM implementation usually needs to get right

The first requirement is encryption in transit between services. If traffic is still traversing flat internal networks in the clear, policy enforcement alone does not give the full zero trust benefit. The second requirement is connection governance, meaning each service should have an explicit allowlist of peers, ports, methods, or identities, rather than inheriting broad internal reachability.

For teams already running heterogeneous workloads, a workload identity and service mesh model is often the cleanest way to keep the policy language consistent across VMs and later platform changes. The goal is to bind trust to the workload, not to the subnet or host name, so policy can travel with the service even when the infrastructure underneath changes.

Operationally, the hard part is not turning on a mesh feature. It is preventing policy sprawl. If each application team invents its own access rules, the estate quickly becomes harder to reason about than the flat network it replaced. Central policy, consistent identity issuance, and clear service ownership matter more than the specific proxy brand or deployment pattern.

Teams should also expect an observability gain if the rollout is done properly. Once connections are brokered through a mesh or proxy layer, denied calls, unusual peers, and unexpected service paths become visible instead of hidden in ordinary east-west traffic. That visibility is essential because zero trust on VMs is as much about limiting unknown dependencies as it is about blocking known bad ones.

Practitioner Guidance

What to prioritise: Start with the services that already exchange sensitive data or reach privileged backends, because those paths create the greatest blast-radius reduction when they are restricted first. A broad “all traffic” rollout is usually less valuable than securing a small number of high-risk flows well.

What to verify: Confirm that policy is enforced at the actual traffic path, not only documented in a central console. Also verify that denied connections are logged in a way that operators can trace back to the originating workload and business service.

Common mistake: Treating the mesh as a visibility project rather than an access-control project. If the rollout adds telemetry but leaves internal allow-all connectivity intact, the environment becomes easier to monitor without becoming materially harder to exploit.

Practitioner takeaway: The fastest credible zero trust win on VMs is usually to enforce encrypted, identity-aware, least-privilege service paths where the applications already run, then expand coverage as the policy model proves stable.

Note: NHI Mgmt Group’s Ultimate Guide to NHIs is directly useful here because zero trust on VMs usually depends on service identities, credential hygiene, and least-privilege access. Its standards section also provides a broader reference point for NHI and zero trust alignment via the standards overview.

Related resources from NHI Mgmt Group

• How should security teams implement Zero Trust access for Kubernetes clusters without creating operational friction?
• How should security teams implement zero trust authentication without adding too much user friction?
• How should security teams implement Zero Trust without creating too many exceptions?
• How should financial services teams implement zero trust access without slowing operations?