Lire en françaisThe question comes up in almost every conversation we have with IT leaders at mid-sized companies: “we already have a VPN, why would we need a bastion on top of it?”
It is a fair question, and the answer does not fit in a comparison table. The two tools solve different problems. Confusing them leads to a very common situation: an organisation convinced it has secured its administrative access, when all it has secured is the transport.
What a VPN does
A VPN encrypts the link between a remote machine and the company network. It answers one precise question: how can an employee or a provider reach the internal network from outside without traffic travelling in the clear across the internet?
On that ground, it does exactly its job. The tunnel is encrypted, authentication can be strengthened, and the remote machine behaves as if it were on the local network.
That is precisely where the limit sits: the remote machine behaves as if it were on the local network. Once the tunnel is up, the user sees what the network exposes. Not just the server they need to work on, but everything else too, within whatever segmentation is in place, which is rarely as fine-grained as people assume.
What a bastion does
A bastion host connects nobody to a network. It opens a session to one specific machine, for one specific protocol, and watches what happens there.
In practice, when an administrator goes through a bastion:
- they authenticate against the bastion first, with MFA;
- the bastion checks whether they may reach this target, with this protocol, at this moment;
- the bastion opens the session by injecting credentials from a vault, without showing them;
- the session is recorded from start to finish.
At no point does the user get general network access. And at no point do they hold the password of the privileged account they just used.
The difference fits in one sentence
A VPN gives you access to a network. A bastion gives you access to a machine, and keeps a record of what you did there.
Everything else follows from that.
The scenario that settles it: a third-party intervention
Take an ordinary situation. Your business software vendor needs to work on the application server, on a Tuesday afternoon, to fix a bug.
With a VPN alone, you create an account, they connect, and they reach the application server. They can also potentially reach the file server, the hypervisor, and the accounting department’s printer. You send them the server’s administrator password, which now exists in their password manager, in a file on their machine, or in the thread you used to send it. When the work is done, you have to remember to disable the account. And you do not know what was done, short of digging through the server logs, if they exist and if they are usable.
With a bastion, you grant access to that server, over RDP, on that Tuesday. They connect from their browser. The administrator password is injected without being revealed to them. The session is recorded. When the window closes, the access closes with it. If, three weeks later, someone needs to understand the origin of a malfunction, you replay the session.
The difference is not theoretical. These two scenarios are what separates an organisation that can answer an audit from one that will answer “we believe that”.
What a VPN does not record
A VPN connection log tells you that an account connected to the network, from a given IP address, at a given time, and disconnected at another.
It does not tell you which machines were reached, which commands were run, which files were opened, or whether the account used really belonged to the person meant to be doing the work.
That is exactly what Article 21 of the NIS2 directive asks for on privileged access, and what most cyber insurance questionnaires ask for: not proof that the link was encrypted, but proof that access was controlled and that you know what was done with it.
Do you have to choose?
No, and that is the most important point in this article.
A bastion does not replace a VPN, any more than it replaces a firewall. These three building blocks answer three different questions: which network traffic passes, how you reach the network, and who accesses which machine with which rights.
Many organisations keep their VPN for everyday employee use and move administrative access behind a bastion. That is usually the simplest path, and it does not require starting over.
The historical obstacle is gone
If the bastion stayed the preserve of large enterprises for so long, it was not for lack of relevance elsewhere. It was that the cost of entry was off-putting: a dedicated server to maintain, a thick client to deploy on every workstation, firewall rules to negotiate, and a multi-week integration project.
Heimlane Realm starts from the opposite premise. SSH, RDP, and VNC sessions open in the browser, with no client software. No jump server is exposed and no inbound rule is created: a lightweight agent installed on the network opens an outbound tunnel to the platform. Credentials come from Vault and are never displayed. And the whole thing is hosted in France and Germany.
The need has not changed in twenty years. What has changed is what it takes to meet it.
Read more: what a bastion host is, what it is used for, and how to deploy one. You can also ask for a Realm demo and open a recorded session in fifteen minutes.