Zero trust architecture in the cloud: a practical guide for AWS, Azure, and GCP
The perimeter model, trust anything inside the firewall, assumed a network you controlled end to end. In the cloud there is no such edge: services span accounts and regions, employees connect from anywhere, and workloads talk to SaaS and to each other constantly. Zero trust replaces “trusted because it is inside the network” with “trusted because it just proved who it is and what it is allowed to do.” This is the architectural companion to the practices in our cloud native security guide; here we focus specifically on the zero trust model.
The core principles
Three ideas carry the whole model:
- Verify explicitly. Authenticate and authorise every request on all available signals: identity, device health, location, workload, data sensitivity. Not once at the perimeter, every time.
- Use least-privilege access. Grant the minimum permission needed, just-in-time and just-enough, so a compromised identity has the smallest possible blast radius.
- Assume breach. Design as if an attacker is already inside. Segment to limit lateral movement, encrypt end to end, and log everything for detection and forensics.
If a decision does not serve one of those three, it is not zero trust, it is just more tooling.
The NIST pillars
The NIST SP 800-207 model (and the CISA maturity model built on it) breaks zero trust into pillars. This is the useful structure, because it turns an abstract principle into a checklist you can actually implement.
| Pillar | The zero trust question it answers | Primary controls |
|---|---|---|
| Identity | Is this user/service who they claim to be? | Strong MFA, federation, short-lived credentials, no standing admin |
| Devices | Is this device known and healthy? | Device inventory, posture checks, managed-device enforcement |
| Networks | Is this traffic allowed, and is it isolated? | Micro-segmentation, mTLS, no implicit east-west trust |
| Applications / workloads | Is this workload allowed to run and to call that? | Workload identity, service-to-service authz, signed artefacts |
| Data | Should this identity access this data, here, now? | Classification, encryption, access policies tied to sensitivity |
| Visibility / analytics | What is actually happening, and is it normal? | Centralised logging, anomaly detection, continuous evaluation |
The point of the pillars is sequencing. You do not implement all six at once; you raise maturity across them over time, starting where your risk is highest (almost always identity).
Identity is where zero trust starts
In the cloud, identity is the control plane. Get it right and the other pillars have something to build on; get it wrong and no amount of network segmentation saves you. The non-negotiables:
- Strong, phishing-resistant MFA for human identities, enforced, not optional.
- Federation over local accounts - one identity provider, SSO, so access is granted and revoked in one place.
- Short-lived, workload-bound credentials instead of long-lived keys. OIDC federation for pipelines; IRSA (EKS), Workload Identity (GKE), or managed identities (Azure) for workloads.
- Just-in-time privilege - no standing admin rights; elevate on request, with approval and expiry.
Want to know where your zero trust gaps actually are?
Book a free 30-min call
How it maps across AWS, Azure, and GCP
Zero trust is provider-agnostic as a principle, but you implement it with each cloud’s native building blocks. This is the mapping we use.
| Pillar | AWS | Azure | GCP |
|---|---|---|---|
| Identity | IAM Identity Center, IAM roles, OIDC federation | Entra ID, Conditional Access, PIM | Cloud IAM, Workload Identity Federation |
| Device trust | Verified Access, device signals | Intune + Conditional Access device compliance | BeyondCorp Enterprise, Endpoint Verification |
| Network | VPC + security groups, PrivateLink, Verified Access | VNet, NSGs, Private Link, Azure Firewall | VPC Service Controls, private service connect |
| Workload identity | IAM Roles for Service Accounts (IRSA) | Managed identities | Workload Identity (GKE) |
| Data | KMS, Macie, S3 access points | Key Vault, Purview, Information Protection | Cloud KMS, DLP, VPC Service Controls |
| Visibility | CloudTrail, GuardDuty, Security Hub | Microsoft Sentinel, Defender for Cloud | Security Command Center, Cloud Audit Logs |
The through-line: every provider gives you an identity-aware access layer (AWS Verified Access, Azure Conditional Access, Google BeyondCorp) that is the practical front door to zero trust. If you are standardising across more than one, the governance challenge is keeping policy consistent, which is the same problem we describe in controlling cloud sprawl.
A maturity model: how to actually get there
Zero trust is a journey, not a switch. Trying to do everything at once is how programmes stall. A sane progression:
- Traditional (where most start). Perimeter trust, long-lived credentials, standing admin, flat networks.
- Initial. MFA enforced, SSO/federation in place, logging centralised. The highest-leverage first step and mostly identity work.
- Advanced. Short-lived credentials everywhere, micro-segmentation for critical workloads, device posture checks, least-privilege reviews automated.
- Optimal. Continuous, signal-based access evaluation; policy as code; automated response; data-aware access decisions across all pillars.
Pick your current rung honestly, then advance one pillar at a time, starting with identity. A team that only reaches “Initial” across the board has already removed the majority of real-world attack paths.
Zero trust and compliance
A zero trust architecture makes compliance substantially easier, because the controls auditors ask about (access control, least privilege, encryption, logging, segmentation) are exactly the ones zero trust mandates. ISO 27001 Annex A, SOC 2, and NIS2 all map cleanly onto the pillars above. Build zero trust well and the audit evidence is largely a by-product, as we cover in our ISO 27001 cloud security guide.
FAQ
What is zero trust architecture in simple terms? A security model where nothing is trusted by default. Every request is authenticated and authorised on its own merits regardless of where it comes from, access is least-privilege, and the design assumes an attacker may already be inside.
Is zero trust a product? No. It is an architecture principle implemented with many controls (identity, device, network, workload, data, visibility). Vendors sell products that help, but you cannot buy “zero trust” off the shelf.
Where do I start with zero trust? Identity. Enforce strong MFA, move to federation/SSO, replace long-lived credentials with short-lived ones, and remove standing admin rights. That single pillar removes most real-world attack paths and is the foundation for the rest.
How does zero trust differ from a VPN? A VPN grants network access, which then implicitly trusts you (classic perimeter thinking). Zero trust grants access to specific applications per request based on identity and context, without putting you “inside” a trusted network. Identity-aware proxies (Verified Access, Conditional Access, BeyondCorp) are the zero trust replacement for broad VPN access.
Does zero trust work across multiple clouds? Yes. The principles are provider-agnostic; each cloud has equivalent building blocks. The hard part in multi-cloud is governance: keeping identity and access policy consistent across providers.
Summary
- Zero trust is a principle, not a product: never trust, always verify. Verify explicitly, enforce least privilege, assume breach.
- The NIST pillars make it actionable - identity, devices, networks, workloads, data, visibility - and identity is where every programme should start.
- It is provider-agnostic but implemented natively. AWS, Azure, and GCP each give you an identity-aware access layer; advance maturity one pillar at a time, and the compliance evidence comes largely for free.
If you want help designing or advancing a zero trust architecture across AWS, Azure, or GCP, explore our security and compliance services.
Building a zero trust architecture?
Book a free 30-minute call. We help teams assess where they are on the maturity curve, prioritise the identity-first steps that remove the most risk, and implement zero trust natively across AWS, Azure, and GCP.
