Trust Nothing, Verify Everything
Zero-trust assumes breach. Every access request is verified regardless of source. Internal networks are not trusted. Perimeter security is insufficient. This is the default security model for cloud-native organisations.
The traditional security model is perimeter-based: a strong firewall at the network edge protects internal resources. Once inside, traffic is trusted. Zero-trust replaces the perimeter with identity. Every access request — from any source, to any destination — is authenticated, authorised, and encrypted.
The core principle: never trust, always verify. Verify the user's identity. Verify the device's health. Verify the request's legitimacy. Verify continuously, not just at login. The verification is context-aware: the same user on a managed device in the office gets different access than the same user on a personal device from a hotel WiFi.
Identity-Centric Security
Identity becomes the perimeter. Every user, device, and service must authenticate and authorise before accessing resources. Multi-factor authentication is mandatory. Privileged access is time-limited and audited. Identity providers (Azure AD, Okta) become the control plane.
MFA is not optional. Password-based authentication is fundamentally broken: passwords are stolen, guessed, or phished. MFA adds a second factor that attackers cannot easily compromise. We enforce MFA for all users, all applications, all the time. No exceptions.
Service identities are often overlooked. In a microservices architecture, services communicate with each other constantly. We use mutual TLS (mTLS) for service-to-service authentication: each service presents a certificate, and the receiving service verifies it. This is automatic with service mesh (Istio, Linkerd) and provides strong authentication without application changes.
Micro-Segmentation
Networks are segmented into small zones with explicit allow rules. East-west traffic (between services) is controlled, not just north-south (inbound/outbound). Service mesh (Istio, Linkerd) implements this at the application layer without network reconfiguration.
Service mesh implements micro-segmentation at the application layer. Each service has a sidecar proxy (Envoy) that intercepts all network traffic. The proxy enforces access policies: service A can call service B on port 8080, but not service C. These policies are defined declaratively and enforced automatically. The application does not need to know about the policies; the proxy handles everything transparently.
Continuous Verification
Trust is not granted permanently. Access is re-evaluated based on context: user behaviour, device health, location, and time. Anomalous access triggers step-up authentication or blocks access entirely.
Static policies ("admins can access production") are insufficient. Dynamic policies ("admins can access production from managed devices during business hours, but require MFA step-up from unknown devices") provide stronger security without additional friction for normal operations.
The signals for continuous verification: user behaviour (unusual login times, impossible travel, new devices), device health (compliance status, patch level, security software), location (IP geolocation, known vs unknown networks), and time (business hours vs after hours, weekends vs weekdays). Each signal has a risk score. The combined score determines the access decision: allow, step-up, or block.
Our Recommendation
Start with identity: MFA, conditional access, privileged identity management. Add micro-segmentation with service mesh. Implement continuous verification for sensitive resources. Zero-trust is a journey, not a product.
Zero-trust is not a product you can buy. It is an architecture pattern and an operational discipline. The organisations that succeed treat zero-trust as a continuous practice, not a one-time project.
The implementation order matters. Identity is the foundation: without strong identity, all other controls are weak. Start with SSO and MFA for all users. Add PIM for admin accounts. Then add micro-segmentation: deploy service mesh, define policies, and enforce deny-by-default. Finally, add continuous verification: define risk signals, build policies, and automate responses.