Zero Trust Architecture: Moving Beyond the Perimeter

The traditional network security model assumed that everything inside the corporate perimeter was trustworthy. VPN access was the castle gate: get past it and the internal network was yours. That model collapsed over the past decade under the weight of cloud adoption, remote work, and lateral movement by attackers who had discovered that a phished credential was sufficient to get past the gate.

Zero Trust replaces the perimeter model with a simple principle: no user, device, or service is trusted by default, regardless of network location. Every access request must be authenticated, authorised, and continuously validated before access is granted. The network is no longer a trust boundary. Identity is.

The Three Pillars

Pillar 1: Identity Verification

Strong identity is the foundation of Zero Trust. This means phishing-resistant multi-factor authentication (hardware security keys or passkeys, not SMS or TOTP where avoidable), conditional access policies that evaluate risk signals at every authentication, and just-in-time privilege elevation rather than standing administrative accounts.

// Example: Entra ID (Azure AD) Conditional Access Policy
// Require MFA + compliant device for admin portal access
{
  "displayName": "Require MFA and compliant device for admin access",
  "state": "enabled",
  "conditions": {
    "users": { "includeRoles": ["GlobalAdministrator", "PrivilegedRoleAdministrator"] },
    "applications": { "includeApplications": ["admin-portal-app-id"] },
    "deviceStates": {
      "includeStates": ["All"],
      "excludeStates": ["Compliant"]
    }
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": ["mfa", "compliantDevice"]
  }
}

Pillar 2: Device Health

A valid identity on a compromised device is still a compromised session. Device posture checks should verify OS patch level, endpoint detection and response (EDR) agent presence and health status, disk encryption, and screen lock policy compliance before granting access to sensitive resources. This is enforced at the access policy layer, not just at enrolment time.

Pillar 3: Micro-segmentation

Network micro-segmentation limits lateral movement by enforcing explicit allow-list policies between workloads, even within the same environment. East-west traffic between internal services should be explicitly authorised, encrypted, and logged. An attacker who compromises one workload should face the same access barriers as an external attacker attempting to reach the next.

# Kubernetes NetworkPolicy: explicit east-west allow-listing
# Only allow the payment-service to talk to the database
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-ingress-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: payment-service
      ports:
        - protocol: TCP
          port: 5432
  # All other ingress implicitly denied

A Practical Implementation Roadmap

1. 01Inventory your identities and remove stale accounts and orphaned service accounts. You cannot protect what you have not counted.
2. 02Enable phishing-resistant MFA for all privileged accounts. This single control stops the majority of credential-based attacks.
3. 03Deploy device management and endpoint detection across your fleet. Start with privileged user devices.
4. 04Implement conditional access policies that block access from unmanaged or non-compliant devices to sensitive applications.
5. 05Map your east-west traffic flows and implement explicit allow-listing at the network layer, starting with your highest-sensitivity workloads.
6. 06Migrate remote access from traditional VPN to identity-aware proxy or Software-Defined Perimeter (SDP) solutions.
7. 07Enable continuous session risk evaluation: re-evaluate trust on activity anomalies, not just at authentication time.

The biggest implementation mistakes we see are organisations that buy a Zero Trust product and believe the architecture is done, and organisations that spend years on design without implementing the two highest-impact controls: strong MFA and conditional access. The model is directionally correct but it is only as good as the consistency of its enforcement.