Platform capability · Tunnels

Native tool access,
governed by the platform.

For OT work that cannot be completed through a browser session, Otector Tunnels give engineers controlled access to approved native tools, while scope, device trust, approvals, monitoring and audit evidence stay with the client.

Tunnels extend Otector's access model; they do not replace browser-based remote access. They are used when a task requires local engineering software, vendor diagnostic tools, database clients, maintenance applications or other approved native TCP tools.

Book a demo Explore the architecture Back to platform

Scope

One destination

Asset, CIDR, ports and protocol profile

Trust

Device-bound

Registered Tunnel Client, per engineer

Access

Direct or request

Approved windows, same as sessions

Evidence

Per flow

Connection decisions, alerts, optional PCAP

The problem

Some OT work still needs native tools.

Browser-based access is ideal for many remote sessions, but engineering and diagnostic work often requires native software with controlled TCP connectivity to specific systems. The usual ways of granting that access give away far too much.

VPNs reach too far

A site VPN grants a broad network route when the engineer needs one asset on one port.

Jump hosts add friction

Standing infrastructure to bounce through, with credentials and access that are hard to retire.

Vendor tools bypass audit

Point solutions shipped by suppliers rarely feed a central, attributable record.

Ports and destinations are hard to govern

Once a route exists, constraining exactly what it can reach becomes a networking project.

Device trust is weak

Access is tied to an account, not to a known, registered engineering machine.

No per-flow evidence

Network teams cannot show which connections were opened, to where, and why.

The approach

Make every native-tool connection explicit.

With Otector Tunnels, administrators define exactly what a tunnel can reach. Before any local port opens, the Tunnel Client proves the engineer and the device. Before any destination socket opens, Otector validates the flow against policy.

01 /

Explicit scope

A tunnel profile sets the hostname, IP or CIDR boundary, allowed ports, protocol profile, application labels and access permission.

02 /

Bound to the device

Every Tunnel Client installation generates a device-specific key, protected by the operating system. Downloaded profiles carry no private key.

03 /

Approval-aware

Tunnels follow the same Direct, Request or Hidden model as browser profiles. Request-based tunnels need an approved window first.

04 /

Per-flow enforcement

Each individual flow is checked by both the Client Portal and Site Agent before the Site Agent opens one destination socket.

VPN vs. Otector Tunnel

Narrow, explicit and governed, not a network route.

Traditional VPN

Broad site route
Hard to bind to a specific engineering device
Limited per-flow visibility
Often always-on or standing access
Weak evidence for audits
Hard to separate providers from internal users

Otector Tunnel

Explicit asset, CIDR, port and protocol scope
Registered Tunnel Client with a device-bound key
Chronological flow decisions and audit trail
Direct or approval-gated access windows
Session evidence, alerts and optional packet capture
One governance model for internal and provider engineers

Audit & flow decisions

Every tunnel flow becomes reviewable evidence.

Tunnel sessions appear in Audit alongside browser sessions. The analysis view combines chronological connection decisions, linked alerts and, where enabled, bounded packet evidence.

Optional passive packet capture

Administrators can enable bounded, retained packet capture for selected tunnels. Capture runs as an independent tap, so failure or slow analysis can never block, modify or delay the production byte stream. Encrypted protocols remain encrypted in the capture — protected content is not shown as plaintext.

Optional protocol inspection

For selected tunnel types, and only where technically supported, deeper inspection can be enabled. It is disabled by default, configured per tunnel profile, and must declare an explicit failure mode — allow the flow uninspected with an alert, or refuse the flow.

Use cases

Native access, scoped to the job.

PLC engineering software

Give programming environments a path to one controller, on defined ports, inside an approved window.

Database & historian diagnostics

Let a database client reach a specific historian without exposing the wider data network.

Vendor diagnostic tools

Allow a supplier utility to connect to its own equipment, and nothing else, under client control.

Maintenance applications

Grant a maintenance tool temporary reach to a defined asset or boundary during a change window.

Explore maintenance access

Approved maintenance windows

Time-box native access to the exact asset, port or boundary the work requires.