Zero Trust Architecture

Network Boundaries That Truly Matter

In network security, structure wins over improvisation: clear paths, fewer privileges and explicit trust boundaries.

In Zero Trust Architecture the goal is to record decisions that teams can execute consistently and repeatably.

This limits not only the likelihood of incidents, but especially the scope and duration when something goes wrong.

Immediate measures (15 minutes)

• Start with MFA, least privilege and tiering for administrative accounts.
• Implement segmentation and explicit firewall rules on critical paths.
• Ensure logging, detection and recovery tests as a structural operation.

Why this matters

The core of Zero Trust Architecture is risk reduction in practice. Technical context supports the choice of measures, but implementation and assurance are central.

Principles of Zero Trust

Zero Trust rests on three words that sound like a mantra, but in practice require a complete overhaul of network architecture: never trust, always verify.

Concretely this translates to three pillars:

The combination of these three determines whether a request is allowed. Not one of them – all three. An authenticated user on an infected device gets no access. A clean device with stolen credentials gets no access. A verified user on a compliant device who tries to reach a resource that does not fit their profile, gets no access.

Traditional perimeter model vs. Zero Trust

The fundamental shift is the assumption. The perimeter model assumes that the inside is safe. Zero Trust assumes that the inside is already compromised and designs every control as if the attacker is sitting right next to you. That sounds like paranoia. Every penetration test proves it is realism.

Identity-Based Access

Identity is the new perimeter. In a Zero Trust model, your network location does not determine whether you can access something, but rather who you are, how you authenticated, and whether your current session shows suspicious behavior.

Conditional Access

Conditional Access policies evaluate multiple signals before granting access:

Signals:                     Decision:             Enforcement:

- User/group                 ┐                     - Grant access
- Application                ├─→ IF/THEN rules  ─→ - Require MFA
- Location (IP/country)      │                     - Block access
- Device (compliant?)        │                     - Limited session
- Risk signals (AI)          ┘                     - Password reset

Example: Azure Conditional Access policy

{
  "displayName": "Require MFA for all users except trusted locations",
  "conditions": {
    "users": {
      "includeUsers": ["All"]
    },
    "applications": {
      "includeApplications": ["All"]
    },
    "locations": {
      "excludeLocations": ["AllTrusted"]
    },
    "signInRiskLevels": ["low", "medium", "high"],
    "clientAppTypes": ["browser", "mobileAppsAndDesktopClients"]
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": ["mfa", "compliantDevice"]
  },
  "sessionControls": {
    "signInFrequency": {
      "value": 4,
      "type": "hours"
    }
  }
}

Risk-based authentication

Static rules ("always MFA") are a start, but smart attackers bypass MFA via token theft, MFA fatigue or social engineering. Risk-based authentication dynamically adjusts the level of verification:

This requires an identity provider that can evaluate these signals. Entra ID, Okta and Google Workspace offer this. On-premises Active Directory alone does not – another reason to move identity to the cloud, even if the rest of the infrastructure remains on-premises.

Microsegmentation

VLANs are a good start (see chapter 15), but they segment at the network level. Two servers in the same VLAN can communicate freely with each other. Microsegmentation goes further: segmentation at the workload level. Every server, every container, every application has its own security perimeter.

The difference is as follows. Traditional segmentation is an apartment building with secured exterior doors but open hallways. Microsegmentation is an apartment building where every individual door is locked.

Tools for microsegmentation

Example: Calico NetworkPolicy

# Only allow traffic from the frontend to the backend API
# Block all other traffic to the backend
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: backend-api-policy
  namespace: productie
spec:
  selector: app == 'backend-api'
  types:
    - Ingress
    - Egress
  ingress:
    - action: Allow
      protocol: TCP
      source:
        selector: app == 'frontend'
      destination:
        ports:
          - 8443
    - action: Deny
  egress:
    - action: Allow
      protocol: TCP
      destination:
        selector: app == 'database'
        ports:
          - 5432
    - action: Allow
      protocol: UDP
      destination:
        nets:
          - 10.0.30.53/32    # Internal DNS
        ports:
          - 53
    - action: Deny

Example: nftables microsegmentation per host

#!/usr/sbin/nft -f
# Web server: only allow HTTP/HTTPS inbound and database outbound
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iif "lo" accept
        ct state established,related accept
        tcp dport { 80, 443 } accept
        ip saddr 10.0.30.0/24 tcp dport 22 accept  # SSH only from management
        log prefix "nft-drop-web-in: " counter drop
    }
    chain output {
        type filter hook output priority 0; policy drop;
        oif "lo" accept
        ct state established,related accept
        ip daddr 10.0.20.5 tcp dport 5432 accept    # Only to database
        ip daddr 10.0.30.53 udp dport 53 accept     # DNS
        ip daddr 10.0.30.123 udp dport 123 accept   # NTP
        log prefix "nft-drop-web-out: " counter drop
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
}

Microsegmentation is work. A lot of work. You need to know which application communicates with which other application, on which ports, in which direction. But it is precisely this work that makes the difference when an attacker gains a foothold. In a flat network, a compromised web server is a springboard to everything. In a microsegmented network, a compromised web server is a dead end.

Device Trust

A strongly authenticated user on an infected device is like a bank employee who enters the building with the right badge, but carries a bag full of burglary tools. The badge checks out. The intent does not.

Device trust verifies that the device itself is trustworthy:

Intune compliance policy (example)

{
  "displayName": "Workstation compliance policy",
  "platform": "windows10",
  "settings": {
    "bitLockerEnabled": true,
    "secureBootEnabled": true,
    "codeIntegrityEnabled": true,
    "osMinimumVersion": "10.0.22631",
    "passwordRequired": true,
    "firewallEnabled": true,
    "antivirusRequired": true,
    "antiSpywareRequired": true,
    "defenderEnabled": true,
    "defenderVersion": "current-1"
  },
  "scheduledActionsForRule": [{
    "ruleName": "deviceComplianceNeeded",
    "scheduledActionConfigurations": [{
      "actionType": "block",
      "gracePeriodHours": 24
    }, {
      "actionType": "notification",
      "gracePeriodHours": 0
    }]
  }]
}

A device that is not compliant gets no access to corporate resources. Not "limited access." No access. The user receives a notification, resolves the issue (install update, enable encryption), and tries again. That is the consequence that makes the model work.

Zero Trust Network Access (ZTNA)

VPN is the symbol of the perimeter model: authenticate once, get access to the entire network. ZTNA is the replacement: authenticate per application, get access to only that one application.

The difference is fundamental:

Popular ZTNA solutions

Example: Cloudflare Access configuration

# Cloudflare Access policy for internal wiki
application:
  name: "Internal Wiki"
  domain: "wiki.intern.example.com"
  type: "self_hosted"

  policies:
    - name: "Employees with compliant device"
      decision: "allow"
      include:
        - email_domain: "example.com"
      require:
        - device_posture:
            integration_id: "intune-compliance"
            checks:
              - type: "disk_encryption"
                enabled: true
              - type: "os_version"
                operator: ">="
                version: "10.0.22631"
              - type: "firewall"
                enabled: true

  # No direct network access -- only this application
  # All requests are logged
  # Session expires after 8 hours
  session_duration: "8h"

# Set up Cloudflare Tunnel (replaces port forwarding)
cloudflared tunnel create intern-wiki
cloudflared tunnel route dns intern-wiki wiki.intern.example.com

# config.yml for cloudflared
# tunnel: <tunnel-id>
# credentials-file: /root/.cloudflared/<tunnel-id>.json
# ingress:
#   - hostname: wiki.intern.example.com
#     service: http://localhost:8080
#   - service: http_status:404

The beauty of ZTNA is that the internal application is nowhere reachable from the internet. There is no open port. There is no IP address to scan. The tunnel goes from the application to the ZTNA provider. An attacker scanning the network sees nothing. Literally nothing.

Data-Centric Security

Zero Trust protects not only the access to data, but the data itself. Even if an attacker breaks through all controls, the data must be unusable.

Classification

Before you can protect data, you need to know which data you have and how sensitive it is:

Data Loss Prevention (DLP)

DLP prevents sensitive data from leaving the organization via unauthorized channels:

• Endpoint DLP: blocks copying to USB, print, clipboard of classified documents
• Network DLP: scans outbound traffic for patterns (social security numbers, credit card numbers, source code)
• Cloud DLP: scans uploads to cloud storage, SaaS applications

Encryption in three layers

Encryption at rest and in transit are baseline – not optional. Every database, every disk, every connection. Encryption in use is the next frontier, relevant for organizations that process sensitive data in cloud environments where they do not trust the hypervisor (and in a Zero Trust model you trust nothing).

Implementation strategy

You don't implement Zero Trust in a weekend. It is a multi-year program. But you don't have to do everything at once. Start with what has the most impact and build from there.

Phasing

Phase 1: Identity (months 1-3)
├── MFA for all users (not just admins)
├── Conditional Access policies
├── SSO for all applications
└── Privileged Access Management (PAM)

Phase 2: Device (months 3-6)
├── MDM enrollment for all endpoints
├── Compliance policies (encryption, patching, EDR)
├── Device-based Conditional Access
└── Certificate-based authentication

Phase 3: Network (months 6-12)
├── Microsegmentation of critical assets (see chapter 15)
├── ZTNA for external access (phase out VPN)
├── DNS filtering and threat protection
└── Network monitoring and logging

Phase 4: Data (months 12-18)
├── Data classification
├── DLP policies
├── Encryption at rest everywhere
└── Monitoring of data access and export

Quick wins

Not everything needs to be a project. These measures can be implemented this week and deliver immediate results:

What not to do

• Everything at once – Zero Trust is not a big bang. Start with identity, because that delivers the fastest results.
• Buy products before you have a strategy – every security vendor now sells "Zero Trust." Some of those are just a firewall with a new label.
• Turn off VPN overnight – migrate application by application to ZTNA, test, and only disable the VPN when everything works.
• Forget that people have to work with it – if Zero Trust destroys the user experience, users find workarounds. And workarounds are the opposite of security.

Summary

Zero Trust is not a product, not an appliance, not a checkbox. It is an architecture principle that assumes the attacker is already inside and designs every control accordingly:

1. Never trust, always verify – authenticate every user, every device, every request. Network location is not proof of trust
2. Identity is the new perimeter – Conditional Access, MFA, risk-based authentication. Protect credentials as crown jewels (see chapter 7)
3. Device trust – an authenticated user on an infected device is not a trusted user. MDM compliance, health attestation, EDR status
4. Microsegmentation – go beyond VLANs. Segment per workload, per application. See chapter 15 for the basics
5. ZTNA replaces VPN – per-application access instead of network access. No open ports, no attack surface
6. Protect the data, not just the access – classification, DLP, encryption in all three layers
7. Start with identity – MFA and Conditional Access deliver the highest impact with the lowest effort. Build from there

John Kindervag was right in 2010. Google was right in 2014. The concept is not new. The technology is not new. The only thing that is new is the urgency – because the attackers have long understood the perimeter model. They count on it.

Previous: Chapter 18 – Vulnerability Management & Patch Policy Next: Chapter 20 – ...