How does zero trust work in the cloud?

In the cloud, zero trust means every request, from a person or a workload, is authenticated, authorized and logged against policy, with no trust granted for being on the same network. NIST SP 800-207A describes how to do this for cloud-native, multi-cloud applications using identity and per-service policy.

Why is the cloud a different problem?

On a classic corporate network, the perimeter did a lot of work. Servers sat behind a firewall and anything inside was assumed friendlier. In cloud environments, services run across accounts, regions and providers, scale up and down, and call each other through APIs. Addresses change constantly, so rules keyed to IP ranges go stale.

NIST SP 800-207 sets the base principles: no implicit trust from network location, access granted per session, and decisions based on identity, device and context. NIST SP 800-207A applies these to service meshes, API gateways and similar parts of cloud-native design, and discusses policy that follows identity rather than addresses.

What are the building blocks?

1. Strong identity for people. Use a central identity provider with multifactor authentication and conditional rules.
2. Identity for workloads. Each service gets its own verifiable identity, rather than a shared key in a config file.
3. Policy at every hop. A gateway or sidecar checks who is calling and whether that call is allowed.
4. Encryption in transit between services, ideally mutual so both sides prove who they are.
5. Least privilege roles, scoped to a job and reviewed.
6. Central logging of decisions, so you can answer who accessed what and when.

What does it look like in a real flow?

A constructed example. An order service needs to read a customer record from a profile service in another account. In a trusting model, both sit in a private network, and the profile service accepts any call from that range. A compromised batch job in the same network can read every profile.

In a zero trust design, the order service presents a short-lived identity token. The profile service accepts calls only from that identity, only for the read operation, only on the fields needed. The batch job has a different identity, gets denied, and the denial shows up in logs. The network location of the batch job never entered the decision.

What are the common pitfalls?

Teams often buy a product and call it done. NIST is clear that zero trust is an architecture approach, not a single tool. Another pitfall is enforcing at the front door only. If users are checked but services trust each other freely, an attacker who lands on one workload moves laterally.

Over-broad cloud roles are the third. A role that allows all storage actions defeats the point of per-request checks. Finally, long-lived access keys in code and pipelines remain a leading cause of cloud account compromise, and no policy engine fixes a key that never expires.

How to check or apply this

1. List every human and machine path into your most sensitive data store.
2. For each, ask: what identity is used, how long does the credential last, and what is it allowed to do?
3. Replace static access keys with short-lived credentials issued from workload identity wherever the platform supports it.
4. Restrict network paths to the minimum, and treat that as a second layer, not the first.
5. Enable audit logging for identity and data access on every account and test that you can query it.
6. Use the CISA Zero Trust Maturity Model to record where you stand on identity, devices, networks, applications and workloads, and data, then pick one pillar to raise by a level this quarter.

Quick check

Sources

1. NIST SP 800-207, Zero Trust Architecture
2. NIST SP 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments
3. CISA Zero Trust Maturity Model

Last reviewed: 18 October 2026.