Trust
What we can see, and what we cannot
A remote-access product asks for a lot of trust. Here is what we actually know, what we do not, and which parts are not finished yet. We would rather you find the limitations here than discover them later.
Line by line
| What | Can we see it? |
|---|---|
| Your account: who you are, when you signed in | Yes. You have an account, so we know it exists and when it is used. |
| Session metadata: that a tunnel existed, and when | Yes. The service brokers the introduction, so it knows a connection happened. |
| The contents of your traffic on the direct path | No. The service is not in the data path once the two ends have connected. |
| The contents of your traffic on the relay path | No. The relay forwards encrypted packets and holds no key that would open them. |
| The credentials or data of whatever you tunnel to | No. They travel inside the encrypted connection between your two machines. |
| Your tunnel configuration stored in your account | Yes, today. Making this unreadable to us is under development. |
Nothing is exposed to the internet
The connector never listens for an inbound connection. There is no port to scan and nothing on the network perimeter that was not there before.
No route into the network
A tunnel reaches the destinations you named for it and nothing else. If the machine holding one is compromised, the blast radius is those destinations — not every device on the remote network.
Nothing installed into the OS
No kernel driver, no network adapter, no service, no boot entry, no firewall or routing change. Close it and the machine is as it was.
Access is time-boxed at enrolment
Install links are short-lived and refuse to run once they expire. Per-connector scope limits and an audit trail are under development.
Limitations
Where we are not finished
Is this zero-knowledge? Can you read my traffic?
We are not in the data path once the two ends have connected, and where a relay is used it forwards encrypted packets it cannot read. What we do know is account and session metadata, because you sign in. We are building stronger client-side key handling so that even your configuration is unreadable to us; until that ships and has been independently reviewed, we do not use the term zero-knowledge — and neither should you when evaluating us.
Has anyone independent reviewed the security?
Not yet. It is planned, and it will happen before we charge anyone money. If an independent report is a hard requirement for you today, piertun is not ready for you, and we would rather say so now than waste your evaluation cycle.
Does this bypass our firewall?
It uses ordinary outbound connections, the same as a browser or an update check. It does not open a port, forward a port, or change any firewall rule. If your policy blocks outbound connections from that machine, piertun will not work — and should not. What it removes is the need for an inbound exception, which is the change that actually increases exposure.
What can someone do with a connector once it is running?
Reach the endpoint the tunnel was configured for, with the rights of the user who started it — nothing more, and nothing else on the machine. Per-connector scope limits that make this enforceable rather than conventional are under development.
Do you have SOC 2 or ISO 27001?
No. Neither exists yet, and we are not going to imply otherwise.
Found a security issue? Write to [email protected] - we'd really appreciate the heads-up.
Judge it on something that does not matter yet
The fastest way to evaluate a remote-access tool is to point it at something unimportant and watch what it does. It costs nothing and takes about two minutes.
Get started — free