From Unboxing to Zero Trust in 4 Hours: What Deployment Actually Looks Like

What a Zero-Trust OT Deployment Actually Requires

Regardless of which vendor or architecture you choose, deploying zero trust on an OT network requires four things, in order:

1. Device discovery — You need a complete inventory of every device on the network: PLCs, HMIs, switches, historians, engineering workstations, and the communication flows between them. You cannot write access policies for devices you do not know exist.

2. Zone definition — Group devices into logical zones based on function, criticality, and communication requirements. The IEC 62443 zone-and-conduit model is the standard framework here. Zones define what should talk to what; everything else is denied by default.

3. Policy creation — Define the access rules between zones: which protocols are allowed, which devices have cross-zone access, and what constitutes a violation. These policies must reflect actual operational traffic patterns, not theoretical network diagrams.

4. Enforcement — Apply the policies to live traffic. Block unauthorized flows, log violations, and monitor for false positives. This is where monitoring-only solutions stop and segmentation begins.

These four steps are the same whether you are using a Claroty/firewall stack, a Cisco ISE deployment, a Fortinet fabric, or an Access Gate appliance. The methodology does not change. What changes is how long each step takes and how many products are involved.

What This Timeline Looks Like with Traditional Tools

With a traditional multi-vendor approach, the four steps above map to separate procurement cycles, separate deployments, and separate integration efforts:

The bottleneck is not any single phase — it is the handoffs between phases. Each transition involves a different vendor, a different product, and often a different team. The monitoring platform identifies traffic patterns, but those patterns must be manually translated into firewall rules. The firewall rules must be tested against production traffic. Every integration point is a potential delay.

During those 4-8 months, the network remains unsegmented. Discovery is happening, but enforcement is not.

This is not a criticism of any specific product. Claroty, Nozomi, and Dragos are strong monitoring platforms. The timeline is a consequence of the architecture — separate products for separate functions require integration work between them.

How the Access Gate Compresses This to 4 Hours

When monitoring, policy creation, and enforcement ship in a single appliance, the four deployment phases run back-to-back instead of waiting on separate procurement and integration cycles. Here is what that looks like in practice, based on production installations including the reference deployment documented in the Thales partnership.

Hour 0-1: Physical Install and Initial Setup

What happens:

• Unbox the Access Gate appliance
• Rack mount in the network cabinet (1U form factor, standard 19" rack)
• Connect the monitoring port to a switch SPAN/mirror port (this gives the appliance passive visibility into network traffic)
• Connect the management port to a management VLAN or directly to a laptop
• Power on

What the operator sees:

The appliance boots in under 3 minutes. A web-based console is accessible at the management IP. The initial setup wizard walks through:

1. Set admin credentials
2. Configure network interfaces (management IP, monitoring interface)
3. Set time zone and NTP source (or manual time if air-gapped)
4. Name the site

No agents to install. No cloud account to create. No license server to reach. The appliance validates its license locally.

At the end of Hour 1: The appliance is physically installed, powered, connected to the network, and accessible via its management console.

Hour 1-2: Network Discovery

What happens:

• Enable passive discovery on the monitoring interface
• The appliance listens to all traffic on the SPAN port
• Devices are identified by MAC address, IP address, hostname (if available), and protocol fingerprint
• Communication flows between devices are mapped automatically

What the operator sees:

The asset inventory populates in real time. Within 15-30 minutes, the appliance has identified most active devices on the network. The dashboard shows:

• Device list with IP, MAC, manufacturer (from OUI database), and detected protocols
• A network map showing which devices communicate with which
• Protocol breakdown — what percentage of traffic is Modbus TCP, EtherNet/IP, OPC UA, HTTP, etc.
• Unrecognized or anomalous traffic flagged for review

Note: Some devices only communicate on long polling intervals (e.g., daily historian backups, weekly firmware checks). The appliance continues discovery in the background and adds newly seen devices to the inventory over the following days.

At the end of Hour 2: The operator has a complete picture of what's on the network, what's talking to what, and what protocols are in use. This is the asset inventory most organizations spend weeks building manually.

Hour 2-3: Policy Creation and Zone Definition

What happens:

• Define network zones based on the discovered topology (e.g., "PLC Zone," "HMI Zone," "Engineering Workstations," "IT DMZ")
• Assign devices to zones — drag and drop in the console or auto-assign by subnet
• Define access rules between zones:
  • Which zones can communicate with which
  • Which protocols are allowed per zone pair
  • Which devices have cross-zone access (e.g., the historian that reads from the PLC zone)
• Configure the overlay segmentation — the appliance creates logical network segments without requiring physical network changes

What the operator sees:

The policy editor presents the discovered communication flows as a baseline. The operator decides which flows are legitimate and should be allowed, and which should be blocked. For a 50-device network, this typically involves:

• 4-8 zone definitions
• 10-20 inter-zone access rules
• 5-10 device-specific exceptions

The appliance suggests policies based on observed traffic patterns. The operator reviews and approves. This is not auto-generated policy running unsupervised — the operator makes every decision, but the appliance does the heavy lifting of identifying what needs to be decided.

At the end of Hour 3: Zone definitions and access policies are configured. The appliance knows what traffic should exist on the network and what should not.

Hour 3-4: Enforcement and Verification

What happens:

• Switch from monitor mode to enforce mode
• The appliance begins actively enforcing the defined policies
• Legitimate traffic flows uninterrupted
• Unauthorized cross-zone traffic is blocked and logged
• The operator monitors the dashboard for false positives — legitimate traffic that was incorrectly blocked

What the operator sees:

The enforcement dashboard shows:

• Allowed flows — traffic matching a policy rule, flowing normally
• Blocked flows — traffic that violates a policy rule, dropped with a log entry
• Alerts — potential false positives flagged for operator review

In practice, the first 30 minutes of enforcement require active monitoring. The operator watches for blocked flows that should be allowed and adds exceptions as needed. After the initial tuning, enforcement runs autonomously.

At the end of Hour 4: The network is segmented, access policies are enforced, and the audit trail is running. Zero trust is operational.

What Happens After Hour 4

Deployment is not the end. Here's what the ongoing operation looks like:

Day 2

• Review the overnight logs for any blocked traffic that shouldn't have been blocked (devices with infrequent communication patterns)
• Add 1-3 additional policy exceptions based on overnight activity
• Verify that all production processes ran normally through the first shift change

Week 1

• Discovery has now captured 99%+ of devices, including those with long polling intervals
• Review the full asset inventory and flag any unknown or unauthorized devices
• Fine-tune zone boundaries if discovery revealed unexpected communication patterns
• Run a compliance report to verify controls mapping against your target framework (CMMC, NIS2, IEC 62443)

Month 1

• The system is in steady-state operation
• Review monthly audit logs and export for compliance documentation
• Test the policy against a simulated lateral movement scenario
• Document the deployment for your compliance auditor
• Ongoing management overhead: 2-4 hours per week for a 50-device network

The Methodology, Summarized

Whether you deploy in 4 hours or 4 months, the underlying methodology is the same:

1. Discover everything on the network
2. Define zones based on function and risk
3. Create policies based on observed traffic
4. Enforce and tune

The traditional approach spaces these steps across months because each step involves a different product and a different integration effort. An integrated appliance runs them back-to-back because there are no handoffs.

The speed difference is architectural, not magical. If your deployment requires deep protocol inspection, multi-site orchestration, or integration with an existing SIEM/SOAR stack, the timeline will be longer regardless of which product you choose. The 4-hour timeline applies to single-site deployments where the goal is monitoring + enforcement with a single appliance.

For organizations with multiple sites, see how this same deployment model scales in our guide to multi-site OT security across 50+ locations. And for a comparison of the overlay segmentation approach versus traditional VLANs, read overlay networking vs VLANs for OT segmentation. If you have a network cabinet, a SPAN port, and a clear afternoon, your OT network can be segmented and enforced by end of day.

For more Zero Trust OT resources, architecture guides, and comparisons, visit the Zero Trust for OT Networks hub.