Zero-trust is one of the most widely invoked and least precisely defined concepts in cloud security. A working definition for cloud environments: zero-trust is a network security model in which no actor — internal or external — is trusted by default, access is verified continuously rather than once at authentication, and the network perimeter is not the primary trust boundary.
In practice, implementing zero-trust in a cloud environment means making specific architectural choices across four dimensions: identity, network, device, and workload.
On the identity dimension, the core requirement is that every access request is authenticated and authorised at the point of access, not at network ingress. Cloud-native implementation: IAM roles rather than shared credentials, mandatory MFA for human access, short-lived credentials for service-to-service access, and centralised audit logging for all authentication events.
On the network dimension, zero-trust replaces the concept of a trusted internal network with explicit allow-listing of service-to-service communication paths. Cloud-native implementation: security groups at the resource level rather than VPC-level trust, no broad internal CIDR allows, explicit service-level policies for each microservice's communication needs.
On the device dimension, cloud environments are accessed by a mixture of engineer workstations, CI/CD systems, and customer devices. Zero-trust requires that device posture is evaluated as part of access decisions. Practical implementation: device certificates for engineer access, device compliance checks in IdP conditional-access policies, certificate-based authentication for CI/CD systems.
A realistic approach for most organisations is to implement the identity and network dimensions first — these deliver the largest security improvement per unit of engineering effort — and phase in the device and workload dimensions over subsequent quarters.
We produce cloud security architecture reviews that assess the current state against zero-trust principles and produce a prioritised roadmap acknowledging the trade-off between security improvement and engineering cost.