Zero Trust in the Cloud: Beyond the Buzzword

There are few terms in enterprise technology that have been stretched as far as "zero trust." Originally coined by John Kindervag at Forrester in 2010, the concept has been co-opted by every security vendor as a marketing label. The result: organisations are investing heavily in "zero trust solutions" while their actual security posture remains fundamentally unchanged.

In this post, I want to strip away the marketing and focus on what zero trust actually means in a cloud environment, what implementing it requires, and where organisations most commonly go wrong.

The Core Principle

Zero trust can be summarised in a single sentence: never trust, always verify. In a traditional network security model, resources inside the corporate network were implicitly trusted. Firewalls protected the perimeter, and anyone inside it was assumed to be legitimate.

Cloud computing destroyed this model. Resources are no longer inside a network perimeter — they're distributed across multiple cloud providers, accessed from home offices, mobile devices, and partner systems. The perimeter is gone.

Zero trust responds by assuming the network is always hostile. Every access request — regardless of where it originates — must be authenticated, authorised, and continuously validated.

The Five Pillars of Zero Trust in Cloud Environments

1. Identity as the New Perimeter

In a zero trust cloud environment, identity is the primary security control. Every human user, service account, and workload must have a cryptographically verified identity. Key practices:

• Enforce MFA everywhere — including service accounts where possible
• Implement just-in-time (JIT) access — users and services receive elevated permissions only for the duration they need them
• Audit all privileged access — every use of administrative credentials should be logged and reviewed
• Federate identity — integrate cloud IAM with your corporate identity provider (Azure AD, Okta, etc.)

2. Device Trust

Access decisions should incorporate the security posture of the device making the request. A managed, compliant device should receive broader access than an unmanaged device.

• Integrate your cloud access policies with mobile device management (MDM) signals
• Enforce certificate-based device authentication where possible
• Block access from non-compliant devices for sensitive resources

3. Network Segmentation and Micro-segmentation

Even though the perimeter is gone, network controls still matter. In cloud environments:

• Use VPCs with granular security groups — every workload should only be able to communicate with the services it explicitly needs
• Implement private endpoints — connect to managed services (databases, storage) without traversing the public internet
• Encrypt all traffic — even east-west traffic within your VPC should be encrypted (mTLS between services)
• Avoid flat networks — if an attacker compromises one workload, they should not have unrestricted lateral movement

4. Application-Layer Security

Network controls are necessary but not sufficient. Application-layer security includes:

• API gateway authentication — all APIs should require authentication, even internal ones
• Service mesh with mTLS — service-to-service communication should be mutually authenticated
• Input validation and output encoding — fundamental application security controls that cloud adoption does not replace
• Secrets management — never hardcode credentials; use a secrets management service (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault)

5. Continuous Monitoring and Validation

Zero trust is not a state you achieve — it's a continuous process. This requires:

• Centralised logging — all authentication events, API calls, and resource access should be aggregated in a SIEM
• Behavioural analytics — detect anomalous access patterns that may indicate compromise
• Automated response — configure automated responses to high-confidence threat signals (e.g. automatic session termination on impossible travel detection)
• Regular access reviews — periodically review and prune all access grants

Where Organisations Go Wrong

Treating zero trust as a product purchase. No single vendor product implements zero trust. It's a framework that requires changes across identity management, network architecture, application design, and operational processes.

Starting with the wrong layer. Many organisations start with network controls and neglect identity. Identity is the foundation — get that right first.

Ignoring workload identity. Human identity management is maturing, but workload identity (service accounts, application credentials) is often neglected. This is where breaches increasingly originate.

Skipping the inventory step. You cannot apply zero trust controls to assets you don't know exist. A comprehensive inventory of all identities, devices, workloads, and data flows is a prerequisite.

Failing to communicate the change. Zero trust implementations often break existing workflows. Change management and developer enablement are as important as the technical controls.

A Pragmatic Roadmap

For organisations beginning a zero trust journey, I recommend this sequence:

1. Inventory and classify — understand what you have and what matters most
2. Harden identity — enforce MFA, implement JIT access, review all service account permissions
3. Segment the network — implement micro-segmentation and reduce standing network access
4. Secure application interfaces — API authentication, secrets management, mTLS
5. Instrument and monitor — centralised logging, SIEM, alerting
6. Iterate and improve — zero trust is a continuous improvement process, not a destination

Conclusion

Zero trust in cloud environments is not a product category — it's an architectural philosophy that requires sustained commitment across identity, network, application, and operational domains. The organisations that implement it well gain a dramatically improved security posture and, counterintuitively, often find that their developer experience improves as well (particularly through self-service identity and access management).

The ones that treat it as a checkbox exercise — buying a "zero trust product" without changing underlying practices — remain vulnerable.

If you're working through a zero trust implementation and want to discuss specifics, I'm always happy to connect on LinkedIn or via the contact form.