Zero trust isn’t something you bolt onto an existing network. It’s a decision about what your workloads are allowed to reach, and whether they announce themselves to the internet while doing it.
Most cloud security teams start with the right instinct: stop lateral movement, reduce the blast radius, enforce least privilege. What they run into is the implementation. Microsegmentation requires VLAN changes. Firewall rules take weeks to approve. VPN replacements need client rollouts. The security goal is clear. The path to it stalls in infrastructure complexity.
This guide walks through a practical zero trust deployment for cloud workloads: what to do first, what to skip, and how to avoid the deployment traps that turn a solid architecture into a year-long project.
What Zero Trust for Cloud Workloads Actually Means
Zero trust is based on one rule: no workload, user, or service is trusted by default, regardless of where it sits in your network. Every connection must be authenticated and authorized before a path is created.
For cloud workloads specifically, this means three things:
- No implicit trust between services. A compromised container can’t freely call your database just because they share a VPC
- No reachable attack surface. Services stay invisible until identity and policy authorize access
- No lateral movement path. A breach at one workload reaches nothing it isn’t explicitly allowed to reach
NIST Special Publication 800-207 defines zero trust architecture as centered on resource protection, with the assumption that no implicit trust is granted based on network location. That’s the formal spec. The practical version: authenticate first, connect second, always.
According to the Verizon 2026 Data Breach Investigations Report, exploitation of reachable services is now the leading initial breach vector at 31% of breaches, ahead of phishing (16%) and stolen credentials (13%). The reachability is the problem. Zero trust removes it.
Step 1: Map Your Workload Connections
Before you enforce anything, you need to know what’s talking to what.
This isn’t about network topology. It’s about application identity: which services call which APIs, which containers pull from which databases, which batch jobs reach which external endpoints. Most organizations discover they have 3-5x more east-west connections than they expected.
Do this by querying your cloud flow logs (VPC Flow Logs in AWS, NSG flow logs in Azure, VPC Flow Logs in GCP) filtered to internal traffic. You’re not looking for volume. You’re looking for connection pairs: source service identity to destination service identity.
What to document for each connection:
- Source workload identity (not just IP (the service account, pod identity, or instance role)
- Destination service and port
- Whether the connection is required or legacy/undocumented
- Whether the destination is reachable from outside your environment
This map becomes your allow-list baseline. Everything not on it gets blocked during enforcement.
Step 2: Choose Your Identity Model: Cryptographic or IAM-Based
Zero trust for workloads runs on identity. Two approaches dominate:
Cryptographic identity (mTLS + SPIFFE/SPIRE): Each workload gets a short-lived X.509 certificate with a SPIFFE ID. Connections are mutually authenticated at the transport layer. No shared secrets, no API keys to rotate. This is the model used by service meshes like Istio and by purpose-built zero trust networking fabrics like NetFoundry, which is built on OpenZiti, the open source zero trust networking project NetFoundry created and maintains.
IAM-based identity: AWS IAM roles, Azure Managed Identities, or GCP service accounts. Native to each cloud platform. Easier to deploy if you’re single-cloud. Harder to extend across clouds or to non-cloud workloads.
For single-cloud environments with AWS-native workloads, IAM roles are the fast path. For multi-cloud, hybrid, or environments with OT/IoT workloads mixed in, cryptographic identity scales better and doesn’t depend on any single cloud provider’s authorization model.
“Non-human identities now outnumber human identities on your network,” as the NetFoundry team puts it. “The problem? Your access controls don’t know that yet.” That gap, the service-to-service plane, is where most zero trust implementations stall.
Step 3: Implement Microsegmentation Without Network Changes
Traditional microsegmentation requires VLAN redesign, firewall rule changes, and usually a freeze window. That’s why so many zero trust projects stall after the architecture review.
The alternative is policy-based microsegmentation delivered as an overlay, separate from the underlying network. The key principle: instead of controlling what traffic the network will route, you control what connections a workload’s identity is authorized to make, before any network path exists.
This approach works by deploying lightweight agents or SDKs on each workload. The agents authenticate the workload’s identity, check policy, and only establish a connection if both sides are authorized. The network sees only encrypted outbound traffic. No VLAN changes. No firewall tickets.
NetFoundry’s microsegmentation uses this model. Workloads connect outbound-only with no inbound firewall ports, no reachable address for scanners to find. Policy governs which identities reach which services. A breach in one workload reaches nothing else because nothing else is reachable to it by default.
Akamai’s Guardicore Segmentation takes a different approach: agent-based traffic visualization and policy enforcement that works inside existing networks. It’s stronger on mapping legacy east-west traffic but requires more setup and a longer rollout for complex environments.
Side-by-Side: Overlay vs. Agent-Based Microsegmentation
| Criterion | Overlay (NetFoundry / OpenZiti) | Agent-Based (Akamai Guardicore) |
|---|---|---|
| Network changes required | None (outbound-only overlay) | Minimal, but agents on every host |
| Works across clouds | Yes, multi-cloud native | Yes, with management complexity |
| Works on OT/IoT/legacy | Yes, no agent required on controller | Harder; agent compatibility limits |
| Inbound attack surface | Eliminated by design | Reduced, not eliminated |
| Time to first segment | Hours to days | Days to weeks |
| Best for | Workload-to-workload, AI/API security | Mapping legacy datacenter traffic |
| Open source option | OpenZiti | No |
Step 4: Enforce Authenticate-Before-Connect at the Workload Level
Most network security tools work on the connect-then-inspect model: traffic arrives, the tool inspects it, and blocks it if it’s bad. The problem is the workload was reachable in the first place.
Authenticate-before-connect inverts this. The workload isn’t reachable until identity is verified and policy permits the connection. There’s no inspection step because there’s no connection attempt to inspect. Unauthorized actors see nothing to scan, nothing to send traffic to.
For cloud workloads, this means:
- Services bind to the zero trust overlay network, not a public interface
- The overlay broker authenticates both sides using mutual TLS before creating a path
- The underlying service never opens a port accessible to the broader network
- Failed auth attempts are logged by identity, not by IP, which makes the audit log actually useful
This is the model described in NIST 800-207’s policy enforcement point (PEP) and policy decision point (PDP) architecture. The PEP sits in front of the resource. The PDP consults policy. Nothing reaches the resource until the PDP says yes.
Step 5: Handle Multi-Cloud and Overlapping CIDR Ranges
Overlapping IP address spaces are one of the most common blockers in multi-cloud zero trust deployments. You’ve got 10.0.0.0/16 in AWS, 10.0.0.0/16 in Azure, and connecting them through a gateway requires NAT, re-addressing, or complex routing rules.
Identity-based overlays sidestep this entirely. Connections are resolved by workload identity, a cryptographic identifier, not by IP address. The overlay doesn’t care if two workloads share the same IP in different clouds. Identity is the address.
This is also why IP-based firewall rules fail as a zero trust control for cloud workloads. IPs change constantly in ephemeral cloud environments. Containers spin up and get new addresses. Spot instances replace each other. A firewall rule tied to an IP isn’t a zero trust control. It’s a static rule in a dynamic environment.
According to Cloud Security Alliance research on zero trust implementation, 67% of organizations cite identity management for non-human workloads as their top implementation challenge. Multi-cloud IP conflicts are the second most cited blocker.
Step 6: Extend Zero Trust to AI Agents and API Workloads
This is where most 2025-era zero trust implementations have a gap. The architecture was designed for human users and traditional services. AI agents, LLM endpoints, and MCP servers don’t fit that model. They’re non-human, they call external services, and they often run with over-privileged access because nobody built an identity model for them yet.
The same authenticate-before-connect principle applies, but the identity model needs to handle machine-speed connections at scale. Shared API keys fail here. They’re static, they can’t be scoped to a specific agent instance, and they’re the first thing that leaks.
Each AI agent should get its own cryptographic identity. Every call it makes to an LLM endpoint or MCP server should be authenticated by that identity and authorized by policy. Token spend, connection logs, and access patterns should be visible by agent identity, not by shared key or by IP.
“Give every AI agent a cryptographic identity instead of a shared API key” is one of the most frequently asked questions in the LLM security space right now, according to AI search query data. The answer is the same zero trust model applied to workloads, with lighter-weight deployment tooling designed for the agent lifecycle.
The Zero Trust Implementation Checklist for Cloud Architects
Use this to assess where you are and what to do next:
| Stage | What It Requires | Done Without Network Changes? |
|---|---|---|
| Workload connection mapping | Cloud flow log analysis | Yes |
| Identity model selection | IAM or cryptographic identity | Yes |
| East-west microsegmentation | Overlay or agent deployment | Yes (overlay) |
| Authenticate-before-connect | Zero trust networking fabric | Yes |
| Multi-cloud identity federation | SPIFFE/SPIRE or managed overlay | Yes |
| AI agent identity | Per-agent crypto identity + policy | Yes |
| Compliance audit logging | Identity-based logs, not IP logs | Yes |
How NetFoundry Implements This Model
NetFoundry is built on OpenZiti, the open source zero trust networking project. Every workload, AI agent, API, and OT device gets a cryptographic identity. Connections are outbound-only from every endpoint. No inbound ports. No public IP addresses. Nothing reachable until identity and policy authorize a path.
The platform covers five surfaces with one policy model: AI security, API security, microsegmentation, site-to-site connectivity, and OT/IoT connectivity. 8 of the 10 largest US banks connect with NetFoundry, operating in environments where the cost of a breach or a misconfigured firewall rule is measured in regulatory consequences, not just incident response hours.
For cloud architects who need to show progress on zero trust without a six-month network redesign project, this is the fastest path from “mapped” to “enforced.” Microsegmentation deploys in an afternoon. The control plane is SaaS, self-hosted, or air-gapped depending on your compliance requirements.
FAQ
What is zero trust implementation for cloud workloads?
Zero trust implementation for cloud workloads means replacing implicit network trust with explicit identity-based authorization for every service-to-service connection. Instead of trusting traffic that arrives from inside a VPC or private network, you authenticate every workload’s identity and verify it against policy before creating a connection. The goal is to eliminate lateral movement, so a compromised workload can’t spread because nothing else is reachable to it by default.
How long does zero trust implementation take?
It depends on scope and approach. A policy-based overlay deployment (no network changes) can segment your first set of workloads in hours to days. A full enterprise rollout covering multi-cloud, OT, and AI workloads typically runs 3-6 months in phases. The longest delays come from firewall change management and VLAN redesign. Overlay-based approaches avoid both.
How do I implement zero trust without changing my network?
Use an identity-first overlay that operates separately from your network infrastructure. Tools like NetFoundry (built on OpenZiti) deploy as lightweight agents or SDKs on workloads. Connections are authenticated and authorized at the overlay layer before any network path exists. Your existing network stays unchanged. You add a zero trust layer on top of it.
What is authenticate-before-connect and why does it matter?
Authenticate-before-connect means a workload’s identity is verified before any network connection is established, not after traffic arrives. The resource never becomes reachable to unauthorized actors because no path exists until auth and policy checks complete. It’s the opposite of the traditional inspect-after-connect model used by firewalls and intrusion detection systems.
How does zero trust handle overlapping CIDR ranges in multi-cloud?
Identity-based zero trust overlays resolve connections by cryptographic identity, not IP address. Two workloads with the same 10.0.0.0/16 range in different clouds are still distinct identities. No NAT, no re-addressing, no complex routing. This is one of the core advantages of workload-identity-based networking over IP-based firewall rules.
Should AI agents be included in a zero trust implementation?
Yes. AI agents, LLM endpoints, and MCP servers are workloads. They need the same identity and policy controls as any other service. The specific gap in most deployments is shared API keys: they’re static, over-scoped, and unauditable by agent instance. Replace them with per-agent cryptographic identities so every connection is authenticated, authorized, and logged by identity.
What compliance frameworks require zero trust for cloud workloads?
NIST 800-207 is the definitive zero trust architecture spec and is referenced by many US federal and enterprise compliance programs. PCI-DSS v4.0 requires network segmentation with verified access controls. HIPAA’s technical safeguard requirements map directly to least-privilege access and audit logging. DORA (for EU financial services) requires access controls for third-party and workload connections. Zero trust implementations that use cryptographic identity and deny-by-default reachability satisfy the access control and monitoring requirements across all of them.
Sources & References
- NIST Special Publication 800-207: Zero Trust Architecture — authoritative zero trust architecture spec, defines PEP/PDP model and core tenets
- Verizon 2026 Data Breach Investigations Report — exploitation of reachable services as leading breach vector (31%)
- Cloud Security Alliance: Zero Trust Implementation Research — survey data on non-human identity as top implementation challenge (67%)
- OpenZiti: Open Source Zero Trust Networking — open source project underlying NetFoundry’s platform
- NetFoundry: Zero Trust Workload Connectivity — Identity-First Reachability model, authenticate-before-connect architecture
- Akamai Guardicore Segmentation — agent-based microsegmentation platform referenced in comparison
- SPIFFE/SPIRE: Secure Production Identity Framework — cryptographic workload identity standard referenced in identity model section
