Zero Trust
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’s 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, nearly three-quarters of the successful ransomware attacks in its 2025 analysis began with a compromised VPN.
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.
What recent VPN attacks show
VPN technology itself isn’t fatally outdated — 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.
For example, in the October attacks on Ivanti Connect Secure gateways, the APT group UTA0576 chained three zero-day vulnerabilities to compromise a fully patched device. After gaining root privileges, they used the VPN’s own legitimate service account to query the domain controller and collect passwords and BitLocker recovery keys.
Before that, vulnerabilities in Check Point and SonicWall gateways were similarly exploited, with the SonicWall attacks carried out by the Akira ransomware operators.
Remote work, VPNs, and stolen data
Today, depending on the country, 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’ networks — 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 initial access brokers (IABs) sell.
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 “everything, temporarily”, 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.
VPN administration overhead
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.
What switching to Zero Trust Network Access changes
First and foremost, Zero Trust Network Access (ZTNA) changes the access model itself and its basic unit of access. Instead of “this user has access rights to this subnet”, a ZTNA system makes decisions like “this user, on this device, in this location, who has passed these levels of verification, can access this specific application”.
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’t automatically let someone connect to a file server or a domain controller.
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’t need to know any of this, but an attacker’s ability to move around the network and attack new services will be severely limited.
Keep in mind that ZTNA is a specific tool — just one part of a broader zero trust architecture. Buying a single product doesn’t mean a company has implemented zero trust.
Benefits of switching from a traditional VPN to ZTNA
A well-implemented ZTNA system primarily reduces the potential damage (the blast radius) if part of the infrastructure or someone’s credentials get compromised; at the same time, deploying it also noticeably decreases an attacker’s room to maneuver.
Reducing the risk of gateway attacks
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.
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’s no need to expose your own gateway for remote access at all.
In a ZTNA architecture with a self-hosted broker, you can’t 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’t process any requests until it receives a correctly formed encrypted packet, which the client uses to prove its authenticity up front.
Limiting the consequences of compromised credentials and workstations
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’s databases are up to date, and whether there are any signs of compromise. What’s 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’ll 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.
It’s easy to see how a hypothetical infostealer attack gets more complicated in this scenario. It’s not enough to simply steal a password or a browser session. Trying to use them on a new device will cut the connection.
Here, ZTNA functions partly overlap with what EDR and MDM/EMM agents do on the device. That’s why several vendors bundle these capabilities into a single agent. At the same time, ZTNA limits the consequences of an attack but doesn’t replace endpoint protection. If an attacker uses a remote access Trojan (RAT) rather than an infostealer and directly controls an employee’s device, the ZTNA agent may not be able to tell the attacker’s actions from the employee’s.
Improving observability and detecting anomalies faster
When an employee works from home over a VPN, the firewalls, web filters, and SIEM/XDR often see only shallow network telemetry. That’s why, for example, the actions of the Qilin ransomware operators — who exploited an authentication vulnerability in Palo Alto GlobalProtect (CVE-2026-0257) — were hard to tell apart from legitimate employee activity.
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.
With this level of log detail and the right SIEM rules in place, anomalies quickly catch SOC analysts’ attention.
Simplifying access administration
“Guest” and “temporary” 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 through this kind of poorly controlled access. ZTNA makes just-in-time (JIT) access possible. A contractor’s 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).
Reducing regulatory and insurance risks
Both regulators and the cyber-insurance market are pushing for stricter access management. In April 2026, CISA explicitly named 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 quick plan for migrating from VPN to ZTNA
Overall, the migration plan looks like this:
- Take inventory of your remote access: VPNs, RDP servers, vendor gateways, service accounts, and configured firewall exceptions.
- Design and fully document an access structure built around applications and roles instead of the familiar subnets.
- Review and, if needed, improve your granular system for identifying users, devices, and applications (identity management), since effective ZTNA depends on it. Enable phishing-resistant MFA, and set up policies for access recovery, posture checks, and session revocation.
- Outline an isolated pilot scenario that’s relatively easy to implement but not trivial. For example, start with contractor access to a few applications.
- Gradually extend ZTNA to new groups of employees and services.
- After each migration stage, disable or significantly restrict the access methods that are no longer needed. For the VPNs that remain, apply strict segmentation and monitoring.
Some legacy applications, industrial systems, and site-to-site connections will still need VPN for a long time to come. The goal isn’t to remove those three letters from your infrastructure at any cost, but to make sure VPN gateways stop being an easy target and an effective launchpad for attacks on your network.
Tips