Zero Trust has moved from the pitch deck to the operational checklist. Security teams, auditors and insurers are pushing for it, regulators are starting to codify it, and the principle is well understood: no implicit trust, no uncontrolled lateral movement, access decisions tied to identity rather than a cable or an SSID, and continuous monitoring and remediation. The hard part is applying it to a network that already carries production traffic.
Most organisations aren't building a network from scratch. They have users, devices, legacy VLANs, an established identity system, and a business that has to keep running. The new ALE Zero Trust Design Guide is written for that situation.
What the guide covers
Aligned with NIST SP 800-207, the guide focuses on the network segmentation pillar of Zero Trust: authentication, role-based access control, micro-segmentation at the access edge, and macro-segmentation at the firewall. It shows how those pieces come together in a design that can be deployed in an enterprise environment.
Authentication gets particular attention. The guide details several architectures to fit different environments: UPAM as the central authentication server, compatibility with the major RADIUS vendors the design has been tested against, or integration with Microsoft Entra ID. Whichever path fits, the identity provider you already run can stay in place and interconnect with your ALE network.
A brownfield-first method
Zero Trust in a brownfield environment is a phased programme. The guide opens with visibility, because before you enforce anything you need to know what is connected, which flows are legitimate, and which devices have a real business reason to be there.
From that inventory, the design moves through role definition, policy in observation mode, and progressive enforcement. It sidesteps two familiar failure modes: redesigning everything at once, or switching on restrictive policy before the environment is understood.
Edge and firewall, each in their place
A significant portion of the guide is spent on access-layer micro-segmentation, and rightly so. Most lateral movement happens because endpoints share a VLAN or service. The guide shows how to shut that down at the access switch with role-based policy applied at ingress, and how the model adapts in larger routed campus designs where L3 access policy becomes necessary. The split matters. The access layer controls local communication and east-west traffic. The firewall controls inter-segment traffic and access to shared services and the internet. Each layer does what it's best placed to do.
Built for production
The guide is hands-on. It includes role-based policy examples for employees, machine authentication, BYOD, contractors, guests, and multiple IoT classes including cameras, sensors and HVAC. It also covers the details that decide whether a design survives production: monitoring mode before enforcement, authentication server unavailability handling, 802.1X-based AP attachment, MACsec between APs and switches, and firewall SSO for identity-aware policy.
Visibility and follow-through
A design is only as good as what you can see once it's live. OmniVista analytics give role-aware visibility into connected users, devices and application usage, so you can monitor and control activity per role. OmniVista Network Advisor adds anomaly detection on syslog patterns, flagging authentication failures and unexpected behaviour quickly enough to act on.
Start here
Read the ALE Zero Trust Design Guide for the full walkthrough of identity, segmentation, firewall enforcement and operational visibility in a design built for the enterprise you already run. Your ALE contact can then map it to your environment, your identity infrastructure and your security policies.
