OT bastion
Self-hosted OT bastion: Zero Trust access to your industrial equipment
An OT bastion is the control point for remote access to industrial equipment. With PipeLinker, the person intervening reaches only the targets opened to them, from a hub you host. The rights, the logs, the recordable sessions and, when you want it, the targets' credentials stay in your hands.
Prise 3
From the equipment to the person working: the path
The path, in this order. The equipment - PLC, HMI, controller - is reached by the agent placed on a machine of its own network. The agent opens an outbound flow to the hub you host: nothing listens on the site, and no inbound firewall rule is requested. The hub carries the telemetry, the rights, the log and the recordable sessions. The authorised person enters through the hub, and reaches only the targets opened to them - never the site's network.
What an OT bastion is
A bastion is the compulsory point of passage to machines you do not reach directly: you authenticate there, it decides what you are allowed to reach, and it keeps the record of what was done. An OT bastion is the same object placed in front of an industrial fleet, where the targets are PLCs, HMIs, controllers and operator workstations, and where you can neither install a client on the target nor stop production for an upgrade.
Bastion, VPN and ZTNA: what separates them
A VPN first establishes a link to a network. Once that link is up, what the person can reach depends on whatever segmentation sits behind it. Fine-grained rights on targets, approval of an access and proof of what was done then call for additional controls, which the VPN does not carry by itself. PipeLinker authorises one target directly, for one named person, and keeps the record of that access in the hub.
Zero Trust does not give the network. It gives one target and one only: this service, on this machine, for this person, now. That is what the acronym ZTNA covers, and it is what the hub does: nothing is reachable by default, every access is a named authorisation, and it is withdrawn in one gesture. The bastion is the piece that carries all of it: the word describes the place, Zero Trust describes the rule.
What our ZTNA covers, and where it stops
Why there is no port to open on the site
Controlling rights by role, by fleet and by device
Rights go to named people, never to a key the team shares: view, open a session, send a command, deploy an update, administer. A fleet is a partition: a site, a customer, a plant, with its own managers and its own agents, blind to the others. A second factor can be required by role.
Bringing in a contractor without handing over the credentials
When you set it up that way, the target's credential stays sealed in the hub: encrypted with a key that lives in the server's configuration and never in the database, and bound to its row, so a secret copied from one fleet onto another does not open. The person intervening receives the right to open the session; they do not receive the machine's password, so they cannot keep it, pass it on, or lose it.
An account is saved once, and serves every service that picks it. A login
with its password, or with its SSH private key and passphrase, kept for the whole instance,
a fleet, a group of machines or a single machine. Renewing it changes what every service
presents from its next opening, on every machine: a service keeps a reference, never a
copy. The console shows only its name, its fingerprint and the public half of a key, to
put in an authorized_keys; the secret never leaves the hub. Writing an account
is a right of its own, since it decides under which identity every service using it
connects; its creation, its renewal and every session opened with it go into the security
log.
The Vault gathers what verifies the equipment and what connects to it: the accounts, the SSH keys - which the hub can generate itself -, the authorities that verify the equipment's TLS, and an Expiries tab that lists by date everything that expires, agent certificates included. Fourteen days before an expiry, an alert announces it: a forgotten certificate no longer cuts off a site on a Monday morning.
What this does not protect, and it is better said: root on the hub, or code running under its identity, read the configuration just as it does.
A person intervening who is proven, not only known
A role can require a security key. Give it to contractors and integrators: until they have registered a key, a wall asks them for one, and the six-digit code no longer opens anything for them, neither in the console nor in PipeLinker Desktop or Mobile. It is the answer to the attack that targets a bastion first: a fake sign-in page relaying the password and the code in real time. A FIDO2 key answers only the real hub.
An employee's account follows your directory. Signed in through Entra ID, Google or Keycloak, it is cut off on the hub as soon as the directory disables it or closes its session - open terminals and screens included, without anyone having to remember it on the bastion side. And if the directory attests a hardware key, the role that requires one accepts it.
Just-in-time access, and the permit to work. A right can last an hour, a day, or open on a window ahead - "tomorrow from 8 am to noon" -, with a reason and the work order's reference. The contractor requests it, a manager approves it from the console or from their phone - two approvals for a critical target -, the sessions of the window are recorded, and at the end the right withdraws itself, cutting what it allowed. Every quarter, a review has the managers reconfirm the standing rights, and its result exports as audit evidence.
Prise 16
A critical target asks for more. Each service, machine or fleet carries a sensitivity - standard, sensitive or critical - that says what it takes to open it: a security key, a device whose state is proven, PipeLinker Desktop or Mobile rather than the browser, recording, an approval. Time windows and origin rules come on top, and a session that runs past its hours is warned, then cut.
- An end date on the contractor's account
- A key required by their role
- A workstation judged before every opening, and cut if it stops complying
- The target's credentials sealed in the hub, never handed over
Logging, recording, revoking
The log keeps who accessed what, when, on which machine and for how long, with what proof and from which device - and the exact reason for every refusal. It exports, and goes to your SIEM: syslog, Splunk, Microsoft Sentinel or OpenTelemetry. Terminal and screen sessions are recorded and replayed; a remote desktop decoded by the hub can be recorded, or given read-only under supervision. Revocation is individual and immediate: it applies at the TLS handshake, before a byte is read, and it also closes the sessions already open.
Why self-host the bastion
A bastion sees the accesses to your production machines go by and keeps the evidence of what was done on them. At a vendor, both of those sit on the vendor's side. Here the hub is one binary and a PostgreSQL database on the machine of your choice: the logs stay there, the retention is yours, and a network cut off from the internet works.
The questions we get
Does anything have to be installed on the PLC?
No. The agent sits on a machine of its network and acts as its gateway; you declare the service - its address, its port, its protocol - and it becomes reachable through the agent.
Does it replace our VPN?
For access to machines, yes, and that is the point: a VPN gives the network, the hub gives a target. For your other uses of the VPN it is a case-by-case question, and we look at it with you rather than answer it on a page.
What can be seen of a session afterwards?
The identity, the target, the time, the duration, and for a terminal or a screen, the whole run, replayable with a time cursor. The rest - files, commands, web access - goes into the audit log.
Page last updated on 6 October 2026. Technical page, maintained by the PipeLinker team at LOOTUS SECURITY, publisher of the product. The date comes from the repository, not from a hand edit.