Zero trust remote access (ZTNA)
We replace the traditional VPN with application-level access: users see only what they are authorized to use, and they can connect only from a verified device.
VPN and ZTNA
What changes compared with a VPN
With a VPN, a remote user works as if sitting in the office. If the laptop is compromised, the attacker is working from the office too.
Application-level connection
Once connected over a VPN, the user is on the internal network. With ZTNA, they connect to one specific application, and only to that one.
Every request judged on its own
VPN logic says that whoever got in can be trusted. ZTNA checks every access request separately, wherever it comes from.
Nothing to discover
Anything not explicitly allowed stays invisible, so it cannot be discovered even from a compromised machine.
Device health counts too
The decision takes into account whether the machine is known, whether its disk is encrypted, whether endpoint protection is running on it, and whether its operating system is up to date. An unmanaged device does not get the same access as a company device.
Logs at application and action level
A VPN logs the connection. ZTNA also logs who did what in which application. By default this log does not reach the SIEM; forwarding it has to be set up separately.
The migration
Off the VPN, step by step
ZTNA is built on identity. Central authentication and MFA have to be in order first, then device management, and only after that comes the migration itself, or the project stalls.
-
Application inventory
We map what users reach over the VPN today. The list is usually shorter than expected, and much of what is on it nobody uses anymore.
-
The first application
It makes sense to start with a well-defined web application and a smaller group of users.
-
External parties
Suppliers and subcontractors come next. This is where risk drops the most, and since the process is new to them anyway, they push back less.
-
Parallel operation
The VPN stays live until ZTNA covers the main use cases. Switching it off should be a deliberate decision, made without pressure.
-
Retiring the VPN
Legacy applications often drag this out for a long time. As long as the VPN is running, it needs MFA and network segmentation too. Operation after the rollout is available under a custom agreement.
Deliverables
What you get at the end
items handed over
- Assessment of remote access needs
- Per-application access rules
- Device compliance check at connection time
- Phased migration from the existing VPN
Related services
What ZTNA relies on
We also offer these areas as separate services.
Identity and access management (IAM)
Who can access what, with which kind of authentication, and what happens when people join, change roles, and leave.
Endpoint protection (EDR/XDR)
Behavior-based protection on workstations and servers.
SIEM and log management
Real-time threat detection and dashboards for the entire environment.
Frequently asked questions
The questions we hear most
When is it worth moving from VPN to ZTNA?
When you work with many external parties, such as suppliers, subcontractors, or maintenance contractors: with a VPN they can see the network, with ZTNA only what they need to work on. Also when the organization mostly uses cloud applications, because a VPN routes that traffic through the central site on its way to the cloud. And when the VPN concentrator has become the bottleneck, which has been the case in many places since remote work took off. We go through these criteria in detail in our article comparing ZTNA and VPN.
What if identity management is not yet in order?
In that case it makes sense to start with identity and access management, and ZTNA can then build on it. We covered the wider background of the principle in our article on Zero Trust architecture.
Can every application be moved to ZTNA?
Not all of them. A large share of ZTNA solutions are optimized for web protocols, and support for older client-server applications is uneven. Supplier access in OT environments needs different tools: a jump server, session recording, and on-demand activation. We covered this in our article on remote maintenance in OT.
What else needs attention during the rollout?
ZTNA does not replace endpoint protection: if the machine is infected, ZTNA lets the infected machine into the application. The ZTNA gateway sits on the critical path for access, and if it goes down, nobody can work. That is why it needs redundancy and a tested outage scenario.
