Status, September 2026: ZoneSentry is not currently taking on new sites, and development of the platform is paused. The regulatory guides on this site remain available — last verified against primary sources on 13 September 2026.

What ZoneSentry Is

Last updated September 13, 2026 · A technical description of the platform

Read this as a description, not an offer. Development of ZoneSentry is paused and we are not taking on new sites. Everything below describes how the platform was built and how it behaves — it is accurate, and it is here because the design reasoning is worth reading whether or not you ever use it. What it is not is an available service.

The Core Idea

Every managed firewall on an OT network generates syslog. These logs contain a complete record of which devices are communicating, where they're reaching, what protocols they're using, and whether traffic was allowed or denied. This data is almost always ignored.

ZoneSentry ingests this syslog over an encrypted TLS connection, parses it, builds behavioural baselines for every device observed, and uses AI-powered analysis to flag anomalies — all without deploying hardware, installing agents, or touching the OT network.

Architecture

ZoneSentry is a multi-tenant platform. All firewall connections are encrypted over TLS. For firewalls that support it, mutual TLS (mTLS) using client certificates issued by ZoneSentry's private certificate authority provides cryptographic device authentication. Data from different tenants is isolated at every layer.

Outside the control loop. ZoneSentry receives a copy of firewall logs. It never sends commands to firewalls, never modifies rules, never injects traffic. It's a passive observer of boundary traffic — the monitoring equivalent of reading the security camera feed, not operating the door locks.

What We See

Any device that communicates across a firewall zone boundary is visible to ZoneSentry. For each connection, we capture:

From this data, ZoneSentry builds a device inventory, maps zone-crossing relationships, and constructs per-device behavioural baselines.

What We Don't See

ZoneSentry provides boundary-observed device inventory. A device that only communicates within its own VLAN — traffic that stays on local switches and never hits a firewall rule — is invisible to us.

For most OT environments with 8–30 devices on a flat VLAN, the boundary view catches the threats that actually matter: a device reaching the internet, talking to something in a different zone, or appearing where it shouldn't be. Intra-zone threats require deep packet inspection hardware at every site — that's what the enterprise platforms sell, and why they cost what they cost.

What If My Network Isn't Segmented?

Many OT environments — especially at junior producers and smaller operators — run flat networks without formal zone separation. If that's your situation, ZoneSentry still provides value, but the visibility model is different.

With a flat network, ZoneSentry monitors what crosses your perimeter firewall: which OT devices are reaching the internet, which external hosts are connecting inward, and what protocols are in use at the boundary. You get perimeter anomaly detection rather than inter-zone monitoring.

This is also the first step toward segmentation. ZoneSentry's device inventory and traffic mapping shows you exactly what's talking to what — which is the data you need to design a segmentation plan. Many operators start with perimeter monitoring and use ZoneSentry's baseline data to plan their first zone boundaries.

If you're working with an integrator to build segmentation, ZoneSentry's traffic map becomes the blueprint. And as you add zones, ZoneSentry's visibility grows automatically — no reconfiguration needed, just more firewall zone boundaries generating more syslog.

Regulatory note: CSA Z246.1:21 Clause 7.2.3 (SHALL) and IEC 62443's zone/conduit model both require network segmentation. Operators who aren't segmented yet need to get there. ZoneSentry helps you understand what you have before you start building zones.

Device Profiling

When a new device appears, ZoneSentry identifies it via MAC OUI lookup (manufacturer), then searches its profile database for known make/model combinations. Profiles define what a device is expected to do:

Profiles are confidence-scored. A curated profile (manually verified) scores higher than an AI-researched one, which scores higher than one generated purely from observed traffic. Alert aggressiveness scales with confidence.

Baseline & Anomaly Detection

Over the first 24–72 hours, ZoneSentry builds a behavioural baseline for each device: typical destinations, typical ports, typical communication peers, typical traffic volumes. As more data accumulates, the baseline becomes more confident.

The daily analysis engine compares recent activity against both the device profile (what this type of device should do) and the behavioural baseline (what this specific device normally does). Deviations generate alerts.

Alert Types

Alert TypeWhat It Means
Unknown deviceA device appeared that hasn't been seen before
Unexpected protocolA device used a protocol not in its profile
Unexpected destinationA device reached a host it has no business talking to
Unexpected peerTwo devices communicated that don't normally interact
Policy violationTraffic crossed a zone boundary that policy doesn't allow
Baseline deviationTraffic volume, timing, or pattern changed significantly

Every alert includes a plain-language narrative explaining what happened, why it was flagged, and what the operator should consider doing. Written by AI for humans who don't read packet captures.

Security Model

Syslog is transported over TLS 1.2+ on TCP port 6514 (RFC 5425). Each tenant firewall connects to a dedicated TLS endpoint. All connections are encrypted in transit. Where the firewall supports mutual TLS (mTLS), a unique client certificate issued by ZoneSentry's private CA provides cryptographic device authentication and the receiving endpoint verifies the certificate chain against an allowlist.

All data is stored in Canada.

Supported Firewalls

ZoneSentry works with any firewall that can send syslog over TLS. The parser architecture is modular — adding a new firewall brand is a drop-in module, not a platform change. If your firewall speaks syslog, we can support it.

Deployment

Deployment required one firewall configuration change on the customer side: add ZoneSentry's endpoint as a syslog destination over TLS, import the CA chain, and install the client certificate. No hardware, no rack space, no power, and no site visit for remote locations.

Time to first alert. Device inventory populates within hours of a firewall starting to send, and the first behavioural baseline forms within about 24 hours. The analysis engine runs daily. Those figures come from the platform's own behaviour in testing — ZoneSentry has not run a commercial customer deployment, and we are not going to dress test results up as a customer track record.

Questions about any of this?

The platform is paused, but the thinking behind it is not secret. Ask.

Get in touch