{"id":56679,"date":"2026-11-10T14:20:57","date_gmt":"2026-11-10T19:20:57","guid":{"rendered":"https:\/\/www.kaspersky.com\/blog\/?p=56679"},"modified":"2026-11-10T14:20:57","modified_gmt":"2026-11-10T19:20:57","slug":"5-ztna-benefits-over-vpn","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/5-ztna-benefits-over-vpn\/56679\/","title":{"rendered":"Five reasons to switch to ZTNA and zero trust: why companies have outgrown VPN"},"content":{"rendered":"

The tried-and-true recipe for protecting a corporate network has become far less effective than it once was. Guarding the perimeter with a firewall and granting remote access through a VPN gateway has become both cumbersome and risky: day to day, it\u2019s hard to configure how users and cloud services interact, and during cyberattacks the VPN gateway is now a prime target. According to data from insurer At-Bay<\/a>, nearly three-quarters of the successful ransomware attacks in its 2025 analysis began with a compromised VPN.<\/p>\n

To jointly improve network security and operational efficiency, companies need to rethink the remote access model itself. The end goal is a secure connection between an employee and work resources. That by no means implies that an employee (or someone posing as one) should get full access to the corporate network.<\/p>\n

What recent VPN attacks show<\/h2>\n

VPN technology itself isn\u2019t fatally outdated \u2014 as long as you treat it as a way to encrypt and tunnel traffic. The problem is how VPN is most commonly deployed: a user authenticates at the entry point, lands on the company network, and from there restrictions (if there are any) depend on segmentation, firewalls, and the protection of individual systems. Inside the network, behind the VPN gateway, a user can reach a wide range of internal services with minimal restrictions. Often, the VPN gateway itself is a privileged device, and successfully compromising it gives attackers many ways to take over the network.<\/p>\n

For example, in the October attacks on Ivanti Connect Secure gateways<\/a>, the APT group UTA0576 chained three zero-day vulnerabilities to compromise a fully patched device. After gaining root privileges, they used the VPN\u2019s own legitimate service account to query the domain controller and collect passwords and BitLocker recovery keys.<\/p>\n

Before that, vulnerabilities in Check Point<\/a> and SonicWall<\/a> gateways were similarly exploited, with the SonicWall attacks carried out by the Akira ransomware operators.<\/p>\n

Remote work, VPNs, and stolen data<\/h2>\n

Today, depending on the country<\/a>, between 12% and 30% of employees work from home either full or part-time. This shift has significantly increased the number of IT systems that need to be reachable from outside the organizations\u2019 networks \u2014 often from personal devices. Personal devices are far more likely than corporate ones to get infected with infostealers. As a result, the black market is flooded with corporate credentials stolen from such computers: it represents 30% of everything<\/a> initial access brokers (IABs) sell.<\/p>\n

Even over a VPN, a strictly segmented network can grant only very limited access. But in practice, exceptions pile up over years of operation: a contractor needs access to a whole subnet, an admin gets \u201ceverything, temporarily\u201d, an old application needs a few more ports. These exceptions piled up especially fast during the covid pandemic. As a result, a stolen account often opens the door not to a single service but to the entire infrastructure.<\/p>\n

VPN administration overhead<\/h2>\n

For VPN access to work properly and securely, configuring the VPN gateway alone is usually not enough: you have to set up MFA, device posture checks, network segmentation, and log collection separately. Then you have to make all of it work together. A new employee or application may require changes in several systems at once. Each system works correctly on its own, but the rules drift apart, and figuring out why a certain user has no access turns into a tour of five consoles.<\/p>\n

What switching to Zero Trust Network Access changes<\/h2>\n

First and foremost, Zero Trust Network Access (ZTNA) changes the access model itself and its basic unit of access. Instead of \u201cthis user has access rights to this subnet\u201d, a ZTNA system makes decisions like \u201cthis user, on this device, in this location, who has passed these levels of verification, can access this specific application\u201d.<\/p>\n

Such a decision takes into account a combination of factors (identity, device, and so on) that the policy specifies. The right to work with a ticketing system or a customer database shouldn\u2019t automatically let someone connect to a file server or a domain controller.<\/p>\n

Depending on the policies, a ZTNA system can grant access to the needed resource behind the scenes through a combination of methods: a dedicated VPN tunnel to a specific internal server, a reverse connection from a corporate application in a private cloud, and others. A legitimate user doesn\u2019t need to know any of this, but an attacker\u2019s ability to move around the network and attack new services will be severely limited.<\/p>\n

Keep in mind that ZTNA is a specific tool \u2014 just one part of a broader zero trust architecture<\/a>. Buying a single product doesn\u2019t mean a company has implemented zero trust.<\/p>\n

Benefits of switching from a traditional VPN to ZTNA<\/h2>\n

A well-implemented ZTNA system primarily reduces the potential damage (the blast radius) if part of the infrastructure or someone\u2019s credentials get compromised; at the same time, deploying it also noticeably decreases an attacker\u2019s room to maneuver.<\/p>\n

Reducing the risk of gateway attacks<\/h3>\n

A VPN gateway usually accepts any connection from the internet. Before verifying the user, the gateway closely analyzes incoming connections, cryptographic messages, and requests to its management and authentication portals. A gateway vulnerability lets an attacker run detailed reconnaissance against the system at this stage and bypass authentication altogether.<\/p>\n

Some ZTNA architectures reduce this exposure. An internal connector establishes an outbound connection to a cloud broker on its own. The user connects to the broker separately, and access to the application opens after the necessary checks. In such a system, there\u2019s no need to expose your own gateway for remote access at all.<\/p>\n

In a ZTNA architecture with a self-hosted broker, you can\u2019t shift the risk to the ZTNA provider. But a number of ZTNA solutions significantly reduce the attack surface of a self-hosted broker too, for example by using Single Packet Authorization. The broker doesn\u2019t process any requests until it receives a correctly formed encrypted packet, which the client uses to prove its authenticity up front.<\/p>\n

Limiting the consequences of compromised credentials and workstations<\/h3>\n

ZTNA can tie access not only to a password but also to the state of the device: whether the organization manages it, whether its certificate is valid, whether the OS is up to date, whether the security software\u2019s databases are up to date, and whether there are any signs of compromise. What\u2019s more, ZTNA can authenticate the same user differently for different tasks. Does the user just want to read the news on the internal portal, and is the computer they log in from already known about? A password is enough. Is the user logging in to a software repository to change application source code, or opening the budget planning system? Then they\u2019ll have to pass phishing-resistant authentication, for example with a hardware key (such as a YubiKey). If the connection type or other parameters change, the user will even have to re-authenticate.<\/p>\n

It\u2019s easy to see how a hypothetical infostealer attack gets more complicated in this scenario. It\u2019s not enough to simply steal a password or a browser session. Trying to use them on a new device will cut the connection.<\/p>\n

Here, ZTNA functions partly overlap with what EDR and MDM\/EMM agents do on the device. That\u2019s why several vendors bundle these capabilities into a single agent. At the same time, ZTNA limits the consequences of an attack but doesn\u2019t replace endpoint protection. If an attacker uses a remote access Trojan (RAT) rather than an infostealer and directly controls an employee\u2019s device, the ZTNA agent may not be able to tell the attacker\u2019s actions from the employee\u2019s.<\/p>\n

Improving observability and detecting anomalies faster<\/h3>\n

When an employee works from home over a VPN, the firewalls, web filters, and SIEM\/XDR often see only shallow network telemetry. That\u2019s why, for example, the actions of the Qilin ransomware operators<\/a> \u2014 who exploited an authentication vulnerability in Palo Alto GlobalProtect (CVE-2026-0257) \u2014 were hard to tell apart from legitimate employee activity.<\/p>\n

ZTNA lets you tie access events to specific identities: users, devices, and applications. Depending on the implementation, SOC teams may get connection logs and, for supported protocols, logs of individual requests to specific applications.<\/p>\n

With this level of log detail and the right SIEM rules in place, anomalies quickly catch SOC analysts\u2019 attention.<\/p>\n

Simplifying access administration<\/h3>\n

\u201cGuest\u201d and \u201ctemporary\u201d VPN access is a perennial headache for IT and infosec teams. Contractor accounts are created as temporary but stay active for years. In 2026, attackers breached a large European financial institution<\/a> through this kind of poorly controlled access. ZTNA makes just-in-time (JIT) access possible. A contractor\u2019s support engineer gets access only to the web interface of the one server they need, and that access shuts off automatically after a set time (say, two hours or two days).<\/p>\n

Reducing regulatory and insurance risks<\/h3>\n

Both regulators and the cyber-insurance market are pushing for stricter access management. In April 2026, CISA explicitly named<\/a> standing contractor VPN access as one of the critical threats to industrial networks. Insurers are also reacting to this trend: organizations with outdated VPN configurations are increasingly hit with rising insurance premiums<\/a>.<\/p>\n

\u00a0<\/p>\n

A quick plan for migrating from VPN to ZTNA<\/h2>\n

Overall, the migration plan looks like this:<\/p>\n