Zero Trust Architecture in Practice — From Theory to Implementation

Remote work, multi-cloud environments, supply chain attacks like SolarWinds — traditional perimeter security based on firewalls and VPNs is dead. Being “inside the network” no longer means being trusted. Zero Trust Architecture (ZTA) reverses this assumption: never trust, always verify. In this article, we break down what Zero Trust actually means, what pillars it rests on and how to implement it pragmatically within 6–12 months.

What Zero Trust Is and Is NOT¶

Zero Trust is a security architecture approach, not a product you can buy. No vendor will sell you a “Zero Trust box.” Yet the term has become a marketing buzzword — every firewall, every VPN, every SIEM suddenly claims to be “Zero Trust ready.”

Zero Trust is based on principles defined in NIST SP 800-207:

• No implicit trust: Every access request is verified regardless of network location — the internal network is not a safe zone.
• Least privilege: Users, devices and applications receive the minimum necessary permissions, and only for the duration needed.
• Assume breach: The architecture assumes the attacker is already inside. The goal is to minimise the blast radius.
• Continuous verification: Trust is not granted once at login — it is verified continuously based on context (device health, location, behaviour).

What Zero Trust is not: it is not a single product, it is not “just MFA,” it is not migrating from one VPN to another, and it is certainly not a project you finish in a month. It is a continuous journey — a gradual transformation of your security architecture.

5 Pillars of Zero Trust Architecture¶

CISA (Cybersecurity and Infrastructure Security Agency) defines five pillars in its Zero Trust Maturity Model. Each pillar requires its own strategy:

• Identity: Identity is the new perimeter. Every user and service account must be strongly authenticated and authorised. Entra ID, Okta or Google Workspace as the central IdP with conditional access policies.
• Device: Access depends on device state — is it managed (MDM)? Are patches current? Is disk encryption enabled? Microsoft Intune, Jamf or CrowdStrike Falcon for device posture assessment.
• Network: Microsegmentation replaces the flat network. East-west traffic is filtered as strictly as north-south. No “trusted VLAN.”
• Application: Applications verify identity and authorisation independently of the network. Every API call carries a token. A service mesh (Istio, Linkerd) ensures mTLS between microservices.
• Data: Data is classified and protected at the object level — encryption at rest, in transit and in use. DLP policies prevent exfiltration.

Identity-First Approach¶

In Zero Trust architecture, identity is the fundamental control plane. It is not just “username and password” — it is a rich context encompassing who, from where, on what device, at what time and what exactly they want to do.

Key components of an identity-first approach:

• Conditional Access: Policies in Entra ID that dynamically decide on access based on risk score. Access from an unknown device from an unusual location at 3 AM? → block or require step-up authentication.
• Passwordless authentication: FIDO2 keys (YubiKey), Windows Hello, passkeys in the Apple/Google ecosystem. Passwords are the weakest link — eliminate them. Microsoft reports a 99.9% reduction in phishing attacks after deploying passwordless.
• MFA everywhere: Every access request requires at least two factors. Push notifications (Microsoft Authenticator) or hardware tokens. SMS MFA is a fallback, not the primary method — SIM swapping is a real threat.
• Identity Governance: Regular access reviews, automated provisioning/deprovisioning via SCIM. Tools: Entra ID Governance, SailPoint, Saviynt.
• Workload Identity: Not just people — services need identity too. The SPIFFE/SPIRE framework assigns cryptographic identities to workloads in Kubernetes. No shared API keys in environment variables.

Microsegmentation — The End of the Flat Network¶

A traditional network is flat: once an attacker gets inside, they can move laterally across the entire infrastructure. Microsegmentation stops this movement.

Implementation approaches:

• Kubernetes Network Policies: Native L3/L4 rules. Define which pods can communicate with which. Requires a CNI plugin (Calico, Cilium).
• Service Mesh (Istio, Linkerd): L7 segmentation with mTLS. Istio AuthorizationPolicy enables rules at the HTTP method and URL path level.
• Cilium with eBPF: Kernel-level enforcement without sidecar proxies. Lower latency, lower resource overhead.
• Host-based segmentation: For legacy VMs and bare metal. Illumio, Guardicore (Akamai).

Critical metric: east-west traffic visibility. Before you start segmenting, you need to know what communicates with what.

ZTNA vs VPN — Why VPN Is Not Enough¶

A classic VPN connects the user to the corporate network and gives them access to everything. ZTNA works fundamentally differently:

• Application-level access: The user connects not to the network but to a specific application. The dark cloud principle.
• Identity + context based: Access depends on identity, device posture and location.
• No inbound connections: The ZTNA connector creates an outbound tunnel. No open ports on the firewall.
• Continuous evaluation: The session is evaluated on an ongoing basis.

Practical ZTNA solutions: Zscaler Private Access, Cloudflare Access, Tailscale, Entra Private Access.

Data-Centric Security¶

• Data classification: Automatic classification using Microsoft Purview or Google DLP. Sensitivity labels: Public, Internal, Confidential, Highly Confidential.
• Encryption at rest: AES-256, customer-managed keys (CMK) for sensitive data.
• Encryption in transit: TLS 1.3 everywhere. mTLS between services.
• Encryption in use: Confidential computing — Intel SGX, AMD SEV. Azure Confidential VMs.
• DLP: Policies preventing exfiltration of sensitive data. Microsoft Purview DLP, Netskope, Zscaler DLP.

Implementation Roadmap¶

Phase 1: Foundations (months 1–3)¶

• Identity consolidation on Entra ID or Okta. MFA for everyone.
• Asset inventory — map all devices, applications and data flows.
• Device compliance — MDM (Intune, Jamf), baseline policies.
• ZTNA for 3–5 key applications (Cloudflare Access, Tailscale).

Phase 2: Segmentation (months 4–6)¶

• Network visibility (Cilium Hubble, ntopng).
• Kubernetes Network Policies — default deny.
• Passwordless rollout — FIDO2 for admins, passkeys for users.
• Data classification in the M365 tenant.

Phase 3: Maturity (months 7–12)¶

• Service mesh (Istio, Cilium) with mTLS.
• Workload identity (SPIFFE/SPIRE).
• VPN sunset — migration to ZTNA.
• SIEM integration and behavioural analytics.
• Governance — quarterly access reviews.

Conclusion¶

Zero Trust is a journey, not a destination. Start with identity — MFA + Conditional Access + device compliance eliminates 90% of common attacks within 3 months. Most enterprise organisations already use M365 and Entra ID. The foundations are laid — you just need to activate them.