---
title: Zero Trust Networks
description: Enforce identity-aware traffic controls, segmentation, and explicit policy decisions for east-west and north-south communication paths.
sidebar:
  label: Zero Trust Networks
  order: 18
source_url: "https://framework.stackit.cloud/migration/design-and-mobilize/security-and-compliance/zero-trust-networks/"
source_file: "docs/migration/design-and-mobilize/security-and-compliance/zero-trust-networks.mdx"
---

## Purpose

Zero Trust Networks ensures that every traffic path is explicitly authorized, constrained, and observable instead of implicitly trusted by topology.

## Control objectives

- **Policy-driven connectivity**: Every allowed flow has a defined policy owner and approved purpose.
- **Minimal lateral movement**: East-west paths are segmented and narrowly scoped.
- **Explicit ingress and egress**: Internet and inter-zone traffic follows controlled and monitored routes.
- **Continuous verification**: Network policy compliance is validated during operation, not only at design time.

## Design recommendations

- **Start with deny-by-default**: Open only required communication pairs between workloads and services.
- **Separate trust zones**: Isolate workload groups by sensitivity, runtime profile, and ownership model.
- **Apply centralized controls where needed**: Use firewall and routing governance for regulated and shared paths.
- **Preserve workload-level policy**: Keep service-local controls close to applications and APIs.

## Implementation checkpoints

- **Connectivity matrix**: Approved north-south and east-west flows with business justification.
- **Segmentation baseline**: Mandatory zone and subnet policy model for each landing zone type.
- **Egress governance**: Defined outbound controls for software updates, third-party APIs, and external integrations.
- **Telemetry coverage**: Logging and evidence for policy decisions, drops, and anomalies.

## STACKIT references

- **Network Area and Routing Tables**: <LinkChip href="https://docs.stackit.cloud/products/network/core-networking/network-area/basics/concepts/">Concepts</LinkChip> and <LinkChip href="https://docs.stackit.cloud/products/network/core-networking/network-area/basics/routing-tables/">Routing Tables</LinkChip>
- **Unified Firewall**: <LinkChip href="https://docs.stackit.cloud/products/network/network-security/unified-firewall/basics/introduction/">Documentation</LinkChip>

Treat routing as path selection rather than traffic authorization. Verify the routing-table
scope below, then enforce the approved flows with the appropriate firewall and workload controls.

> From the STACKIT docs: [Routing tables › Routing tables overview](https://docs.stackit.cloud/products/network/core-networking/network-area/basics/routing-tables/#routing-tables-overview) (Source updated 14.04.2026, copied 06.10.2026)

A routing table is a collection of routes that define how traffic moves between networks, services, and external systems. You configure routing tables at the network architecture level and apply them to any routed network within the same environment. Each STACKIT Network Area includes one default routing table. STACKIT creates this table automatically when you create a new environment. All routed networks follow the default table unless you assign a different one. You can define multiple routing tables per STACKIT Network Area. One network can use only one routing table at a time, but you can assign a single routing table to multiple networks. Routing tables determine the path that outbound traffic takes from a service or network component. They do not control how inbound traffic reaches the destination.

## Anti-patterns to avoid

- **Flat trust zones**: Broad network reachability across unrelated workloads.
- **Implicit inter-service trust**: East-west communication allowed without policy ownership.
- **Firewall-only mindset**: Central controls replace service-level and identity-aware controls.
