The questions you are asking yourself

Is PipeLinker a gateway or a bastion?

Both, and they are two distinct functions rather than two products. The gateway gathers: the agent placed on an IT, OT or IoT machine calls the hub outbound, reports its state and makes reachable whatever lives behind it. The bastion controls: who enters, on which target, with which rights, and what is left of it in the log. The hub carries both, and that is why there is no port to open: what connects and what controls are in the same place. The word the industry uses today for the second half is ZTNA, Zero Trust Network Access; the question « Is this ZTNA? » says what it covers here, and where it stops.

Do we need to open a port on the remote site?

No. The agent itself establishes an outbound, encrypted connection to the hub, and everything goes through it: telemetry, commands, updates, remote access. No inbound port to open, no firewall rule to obtain, no fixed address to ask the carrier for.

Where is the data stored?

On your premises. PipeLinker Hub is self-hosted: one binary and a PostgreSQL database, on the machine of your choice. Your PostgreSQL backup and monitoring procedures apply as they are.

Does the product work without internet access?

Yes. Nothing calls an outside service to work: a fully isolated network is fine, which is the common case in industry. The agent and application binaries are then dropped onto the hub by hand.

How long does the installation take?

One public address, two names pointing at it - the console and the agents' door -, a certificate covering them, a PostgreSQL database, and the hub's Debian package, which sets the rest up in seven questions - or the Docker Compose stack published with every version. A team that already runs a server does it alone, with the documentation; the onboarding we offer is bought to go fast and sleep well, not because it is indispensable.

How do the hub and the agents update?

The agents update from the hub, through a progressive rollout you trigger: a canary, a test group, then the rest, and every binary is signed before being accepted. The hub itself can fetch versions from our portal if you enable it - a setting, off by default, four checks a day that you can adjust - or receive the files you drop yourself.

Why PostgreSQL alone, and not TimescaleDB?

Because the TimescaleDB features that would justify adopting it are not under a free licence, and a product delivered on your premises would then impose its terms of use on you. We stayed on plain PostgreSQL, with our own aggregation tables.

Which systems does the agent run on?

Linux and Windows, on x64 and ARM64 - and Linux on 32-bit ARM too, for industrial boards -, with the same native binary and the same protocol. And Android, on ARM 32 and 64, x86 and x64, for purpose-built devices: kiosks, rugged terminals, production tablets. And for a microcontroller, a C library speaking the same contract, supplied on quotation and integrated into the board's firmware.

What does the Android agent do, and what does it not do?

It carries telemetry, application inventory, commands, signed updates, a terminal, files and tunnels to equipment on the local network - within the limits Android leaves to a non-rooted application: the terminal runs under the agent's identity, in its sandbox, and the files are the folders the device has granted. It does not serve its own screen - that is a permission the agent does not ask for - but the screen of equipment behind it is reached through the tunnel, as from any other agent. The table on the agents page says it box by box.

Can we reach the web interface of equipment behind the agent?

Yes. The hub opens the equipment's web HMI in your browser, through the agent's connection, with no VPN and no client to install. The access is authenticated by the hub and traced like the rest.

What about PLCs that cannot carry an agent?

An agent on a machine of the same network acts as their gateway. You declare the service in the console - its address, its port, its protocol - and it becomes reachable through the agent: SSH, Telnet, SFTP, FTP and FTPS, VNC, RDP, web interfaces, SNMP v2c and v3, RTSP and ONVIF cameras, and any declared TCP port. Nothing to install on the PLC, and nothing open on the site.

Can we keep our usual tools, PLC client or remote desktop?

Yes, with PipeLinker Desktop on the workstation. It opens a local proxy for your browser and forwards a local port to a declared service: your PLC client, your database client or the vendor's utility reach the equipment by name, with no address to rewrite. With the PipeLinker network, any program on the workstation reaches a declared device by name, over TCP and UDP alike: off by default, it resolves only declared names, and every new program is put to the person. A remote desktop opens in the workstation's own client, in one click.

Is there a mobile application?

Yes, PipeLinker Mobile, on Android: the fleet, the map and the trips, the alerts. And on a machine, a terminal, the files, a VNC screen, an RDP desktop, the internal web pages. It enrols through a one-time code obtained in the console; the hub's password never goes in. Android only, for now.

How does a device authenticate?

By a client certificate of its own, never by an API key shared across the fleet. The private key is generated on the device and does not leave it. Revocation is individual and immediate.

Where does the private key live?

In the best shelter the machine offers. On the workstation, in the TPM - through the key store on Windows, through /dev/tpmrm0 on Linux -, then failing that the software store and a file sealed by DPAPI, or a file readable by the account alone. On Android, in the Keystore, tied to unlocking. On the agent, a file created with restricted permissions from the moment it is written. A backup restored elsewhere carries no identity.

What happens if a machine is compromised?

You revoke its certificate from the console, and the hub refuses it at the TLS handshake, before a byte is read. The other machines have nothing in common with it: each has its own identity, and each fleet its own certificate authority, which makes an identity from one fleet fail on another.

Where are the machines' credentials kept?

In the hub, and sealed. A declared service carries its credential - a password, a key, an SNMP community or keys -, which the hub encrypts with a key that lives in its configuration and never in the database. The seal is bound to its row: the table, the column and the primary key go into the computation, so copying a sealed secret from one fleet onto another does not open it. The person intervening receives the right to open the session, not the password of the machine. What this protects: a stolen database, a replica, a backup taken by a third party, a managed database. What it 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.

Are sessions recorded?

Terminal and screen sessions are recorded and replayed, with a time cursor. A session in progress can also be watched from the console, by someone who can send nothing, and the person being watched knows it. A supervised remote desktop, which the hub decodes, is recorded and can be handed over read-only, in the browser as in the workstation's RDP client; a relayed desktop, whose bytes the hub only carries, is not recorded. The rest - files, commands, web access - goes into the audit log: who, what, on which machine, when, for how long.

Can the logs go to our SIEM?

Yes. Every access decision - opening, refusal, cut, end - is a dated event that says who, from which device and with what proof, towards which target, and why. It goes out as syslog (RFC 5424, in CEF or JSON, over TCP or TLS), to Splunk, Microsoft Sentinel or OpenTelemetry, to several destinations at once, and an unreachable destination receives what was waiting for it when it comes back. The hub also flags anomalies, account by account and against its own history: an unusual hour, an address or a country never seen, a new device, an abnormal volume of sessions or refusals. In every offer, at no extra cost.

Can we sign in with our directory, Entra ID or Google?

Yes, through OIDC: Entra ID, Google, Keycloak, or any provider that publishes its discovery document, in every offer and at no extra cost, on the console as in PipeLinker Desktop and Mobile. The provider says who you are, the hub decides what you may do: only accounts declared in the hub get in, and their roles remain the hub's. When the directory closes a session or disables an account, the hub cuts at once whatever the person held open, through OpenID Connect back-channel logout or through CAEP shared signals. A local administrator account remains the fallback route, and every sign-in through it is logged. No SAML for now, and accounts are not created from the directory automatically.

Are FIDO2 security keys and passkeys supported?

Yes: a YubiKey, the key built into the workstation or a phone's passkey, as a second factor instead of the code, or alone, with no password, on the console - and as a second factor on PipeLinker Desktop and Mobile, over USB, NFC or the phone's passkey. A role can require one, administrators too. A sensitive gesture - changing a right, touching the vault - asks for the key again. The hub keeps only the public key, and refuses a key whose counter goes backwards: that is the sign of a cloned key, and it is logged.

Is this ZTNA, Zero Trust Network Access?

Yes. Nobody reaches the network, only a declared service, target by target, and the agent calls outbound: nothing listens on the site. Every access is judged on three proofs - the identity, through your directory or a FIDO2 key; a certificate per machine and per device; the device's state, proven by its TPM or its chip - and on the target's sensitivity. Verification is continuous: what stops complying is cut, and every decision goes to the access log and to your SIEM. What stays declared: antivirus and LUKS encryption; and the browser measures nothing.

Zero Trust access in detail

Who is allowed to do what?

Rights are granted by role and by fleet, to named people: view, open a session, send a command, deploy an update, administer. A second factor can be required by role, and a security key too. An access is limited to one destination and one duration, and is withdrawn in one gesture, which at once cuts what it allowed. A target can be marked sensitive or critical, and then require a key, an attested device, a recorded session or an approval; time windows and origin rules come on top. An access review, quarterly by default, has the managers reconfirm the standing rights. Two roles ship for the common cases: "Integrator", which declares the services of the machines entrusted to it without being able to widen what they allow, and "Security", which reads and acknowledges the alerts, and nothing else.

Can a contractor be given access for the length of the job?

Yes, in two ways. The right itself can carry a duration - an hour, a day, until a date - or a window ahead, like a permit to work: "tomorrow from 8 am to noon", sessions recorded, and it withdraws itself. The contractor can also request it, and a manager approves it, from the console or from their phone. And the account carries an end date: once it passes, the account opens nothing, and a session already open is closed within the minute. Expired is not deactivated: moving the date back is enough to let the account in, with nothing else to undo. Operations are warned before the deadline, seven days by default and adjustable, and the message goes to those who can extend it rather than to the person losing the access. An administrator cannot carry a date: that is a database rule and not a console one, so a hub is never left with nobody able to enter it.

Does the product help answer the Cyber Resilience Act?

On the part the fleet must be able to say, yes: inventory of installed packages with a normalised identifier, CycloneDX export per machine, search for a package across the whole fleet, signed updates and an audit log. It does not produce the SBOM of your own software and does not itself match against vulnerability databases.

What does the licence count?

Installed agents - a machine carrying the agent -, users, isolated fleets and services - what is opened through an agent, on the machine or on equipment behind it. Never sessions, connections or minutes: open ten terminals or two hundred, the bill does not move. The whole hub is in every offer; what varies is the size, and the two applications, Desktop and Mobile.

Do we need a licence per site, or per customer?

No. One instance, one licence, and one fleet per site or per customer inside it: each has its managers, its rights, its agents, and does not see the others. The number of fleets is a licence ceiling, like devices and accounts - depending on the offer, and as many as there are customers on the custom one. It is generous at every step because a fleet is a logical partition the hub carries anyway: what makes the price is the machines and the accounts, not the partitions between them.

What happens when the licence expires?

The hub keeps running, and it never refuses to start. The agents stay connected, telemetry comes in, alerts work, the console opens and the fleet can be consulted. What stops is what touches a machine: opening a session, sending a command, enrolling a device. The console warns you thirty days ahead.