The traditional security model assumed everything inside the network perimeter was trustworthy. Employees sat in offices behind corporate firewalls. Servers lived in on-premise data centres. Perimeter security made sense when the boundary was physical. It makes no sense in a world of remote workers, SaaS applications, microservices, and cloud-native deployments where there is no perimeter to speak of.
Zero-trust flips this assumption entirely: trust nothing, verify everything. Every request — regardless of where it originates — must authenticate, must authorise the specific action being requested, and must be logged. A developer on the corporate VPN has no more inherent trust than a request arriving from the public internet. Identity and context replace network location as the security boundary.
The Five Pillars of Zero-Trust
- Identity verification: Every human and machine identity must authenticate via short-lived tokens (JWTs, SPIFFE/SPIRE for workloads). Permanent credentials are eliminated.
- Device health: Endpoint posture checks confirm the requesting device has current OS patches, endpoint detection enabled, and disk encryption active before granting access.
- Least-privilege access: Services and users receive only the minimum permissions required for the specific task. An API that reads orders should never have write access to the payments table.
- Microsegmentation: Internal east-west traffic is explicitly controlled. A compromised microservice cannot reach adjacent services unless explicitly permitted by policy.
- Continuous monitoring: All traffic is logged, analysed for anomalies, and correlated. Unusual access patterns trigger automated investigation, not just alerts that humans ignore.
Practical Implementation on AWS/GCP
In practice, zero-trust on AWS means using IAM roles with conditions (not users with long-lived access keys), VPC endpoint policies that restrict which services can communicate, AWS PrivateLink to eliminate traffic from traversing the public internet, and Service Control Policies at the organisation level to enforce boundaries even against root accounts.
For workload-to-workload authentication, we recommend SPIFFE/SPIRE: each service receives a cryptographic identity certificate (SVID) valid for 60 minutes. Services authenticate each other using mTLS with these short-lived certificates. When a certificate expires, the workload re-attests its identity to SPIRE before receiving a new one. There are no static passwords or API keys to rotate or leak.
Secrets Management
HashiCorp Vault (or AWS Secrets Manager) should be the single source of truth for all credentials. Applications authenticate to Vault using their workload identity, receive dynamic database credentials valid for 15 minutes, and never see a static password. When that credential window expires, the application re-authenticates and receives a fresh credential — automatically rotated, with a complete audit trail of every access.
The Migration Path
Zero-trust is not a product you buy — it's an architecture you build incrementally. Start with identity: enforce MFA everywhere, migrate from long-lived credentials to short-lived tokens, and integrate your IdP (Okta, Azure AD) as the source of truth. Then layer in device health checks. Then tackle microsegmentation. Each phase delivers measurable security improvement without requiring a full architectural rewrite. The organisations that try to implement zero-trust as a big-bang project fail. Those that treat it as a multi-quarter programme of incremental improvements succeed.