ZERO TRUST ARCHITECTURE

Designing a zero trust architecture for a multi-site logistics company that is already running is a different problem from designing for one that does not exist yet. The existing network has credentials, traffic flows, and operational dependencies that keep the business alive — and a migration that cannot break any of them. NIST SP 800-207 describes the destination with precision. It says almost nothing about how to get there from a network built ten years ago by people who are no longer employed by the company.

The addressing scheme — 10.SITE.VLAN.0/24, second octet for site, third for function — was chosen for auditability over cleverness. A plan a new network engineer can read in five minutes is one they cannot misconfigure silently. The inter-VLAN traffic matrix was built differently: starting from empty and adding only what each business function demonstrably required, not what the existing network allowed. The existing network allowed too much. This is almost universally true. The identity stack — Step-CA for internal PKI, Authentik as the identity provider with hardware MFA, Teleport replacing direct SSH and RDP — was the most sequencing-sensitive part of the architecture. Misconfigure the trust chain at the CA level and every certificate signed against it is suspect.

The three-year TCO came to approximately €25,200 on QEMU/KVM infrastructure, built from component-level cost attribution rather than vendor quote. The difference matters: a vendor quote tells you what a solution costs to purchase. Component-level attribution tells you what it costs to run — including the operational labour that vendor quotes consistently omit. The NIS2 Article 21 compliance mapping was generated from the architecture documentation, not retrospectively: each control justified against a design decision, not claimed against a deployed component. The homelab implementation ran OPNsense with Suricata in IPS mode on the perimeter, Nginx with CrowdSec on the DMZ, and Wazuh receiving logs from every segment.

Five deployment phases, each leaving the network more restrictive than the last, each designed so that a failure in that phase rolls back without cascading. Phase one deploys the identity infrastructure without deprecating existing credentials — which feels counterproductive and is operationally essential. The paired hands-on lab guide exists for a specific reason: a Technical Architecture Document that cannot be implemented is a design opinion dressed as engineering. The guide closes the gap between the document and the working system.