Zero Trust Network Access has earned its place in modern security architecture because it is meaningfully better than legacy VPNs and broad network-level trust. It authenticates each connection, limits lateral movement, creates app-level access instead of network-level exposure, and can inspect requests headed toward applications.
Those are important improvements over traditional physical network security models and flat remote access designs.
But a new claim has become common in the market: that ZTNA “hides” applications and therefore solves the core security problem. That claim needs closer scrutiny.
ZTNA can hide applications from unauthenticated discovery and from users who do not have policy-based access, but it does not truly hide the application from a compromised device that belongs to an authenticated and authorized user.
Once a legitimate session is established, the application is still reachable through the approved micro-tunnel, and that is exactly where the next generation of AI-assisted malware changes the threat model.
What ZTNA does well
ZTNA should not be dismissed. It is a strong step forward from older remote access models because it narrows exposure to specific applications, validates identity and context before granting access, and reduces the risk of broad lateral movement across the internal network.
For large user populations, it is a more scalable and security-aware approach than legacy VPNs.
That matters because most enterprises still need a practical control plane for employees, partners, and distributed users.
ZTNA is often the right default for general secure access. The problem starts when it is presented as a complete answer for protecting highly sensitive applications against malware running on an authorized endpoint.
The flaw in the “hiding apps” narrative
The phrase “hiding applications” sounds stronger than the reality. In practice, ZTNA does not make an application unreachable to the device of an authenticated user. It creates a controlled path to that application.
The path is narrower, policy-driven, and better monitored than a VPN tunnel, but it is still a path from the end-user environment to the target application.
That distinction is crucial. If malware is sitting on a user’s device and that user is authorized to access the application, the malware can leverage the user’s session, tokens, browser context, or active application workflow to interact with the application.
ZTNA does not remove that possibility. It enforces who can connect, but once the connection is approved, the endpoint remains part of the trust chain.
Why AI-assisted malware makes this worse
This is where Mythos-like models introduce a more serious risk. Anthropic’s Mythos model has already surpassed humans in finding and exploiting software vulnerabilities, including autonomously chaining multiple vulnerabilities and surfacing weaknesses in mature software stacks.
That matters because many web protection layers, whether embedded in a ZTNA platform or deployed separately as a WAF, are strongest against known classes of attacks, recognizable payload patterns, or rule-detectable anomalies.
They are not magic shields against entirely new exploit paths discovered and adapted by AI at machine speed. The broader problem is that patching cycles cannot keep pace with AI-scale exploitation and conventional endpoint protections are not designed to stop every AI-assisted zero-day technique.
So the issue is not that request scanning has no value. The issue is that scanning remains reactive to traffic characteristics, while AI-assisted malware can discover sophisticated weaknesses that are not yet covered by signatures, heuristics, or standard web application protection logic.
If the malware already has a valid path to the app through an authenticated endpoint, the application is still exposed.
WAF and ZTNA inspection are not isolation
This is the architectural mistake many organizations make. They confuse inspection with isolation.
A WAF or a ZTNA web protection engine can inspect requests, reject obvious malicious payloads, and reduce noise from common attack techniques. That is useful, and it should remain part of the stack. But these controls still operate on the communication path between the user-side device and the application. They do not sever that path.
If a compromised authorized endpoint is allowed to reach the application, the attacker is no longer forced to attack from outside the perimeter. The attacker can operate from inside an approved workflow using a trusted identity, a valid session, and a sanctioned route.
That is why AI-generated exploit techniques are so dangerous: they do not just attack exposed surfaces; they can weaponize legitimate access paths that defenders already consider acceptable.
Why true isolation matters
For critical applications, the stronger answer is not more traffic inspection alone. The stronger answer is isolation.
Virtual Desktop Infrastructure changes the model by moving application execution away from the endpoint and into IT-controlled infrastructure.
Virtual desktop computing addresses this by keeping user applications and desktop operating systems inside the datacenter or cloud, while the end-user device receives only a remote display stream.
That is a fundamentally different security boundary. The endpoint may still be untrusted, but the sensitive application does not execute there. The attacker may control the local device, but the application, session state, and data remain inside a managed environment. This is what true isolation means in practice.
Three benefits of VDI
VDI becomes especially powerful for sensitive workloads because it changes where data lives, where software runs, and how much trust is placed on the endpoint.
1. Data remains within the datacenter
VDI keeps data within the datacenter, which materially reduces exfiltration risk and also supports data locality and compliance requirements.
This is one of the biggest architectural advantages. When users interact with applications through a remote workspace instead of running them locally, sensitive data is far less likely to be downloaded, copied, cached, or left behind on unmanaged devices.
For organizations dealing with regulated data, privileged consoles, internal admin tools, or confidential operational systems, keeping the data in the datacenter materially reduces risk.
2. Apps run on IT-controlled infrastructure
Because user apps and desktop operating systems run within the datacenter, patching can be centralized and accelerated, monitoring becomes more consistent, and vulnerable critical applications become easier to protect.
This is a major operational benefit as well as a security benefit. Instead of trying to patch, harden, and observe thousands of heterogeneous endpoints, IT can standardize images, accelerate refresh cycles, centralize logging, enforce policy consistently, and monitor user activity in a controlled environment.
In a world where AI-assisted exploits move faster than endpoint patch cycles, central control matters enormously.
3. The end-user device matters far less
VDI also reduces dependency on device and location and isolates device OS vulnerabilities from the enterprise network.
That makes VDI highly relevant for hybrid work, unmanaged devices, third-party users, and contractors. When the endpoint is reduced to a window into a controlled environment, device hygiene still matters, but it stops being the decisive security boundary for the application itself.
This is the right model when the organization cannot fully trust every laptop, home PC, or personal device that may be used to access sensitive resources.
ZTNA is still a good access layer for broad user populations. But for sensitive applications, sensitive modules within applications, and high-risk user categories, VDI should be the preferred access path because it provides the isolation ZTNA does not.
Several use cases stand out:
· Privileged users should access management consoles, administrative interfaces, and management networks only through VDI, because these surfaces carry outsized risk if a local endpoint is compromised.
· Server access should be delivered through VDI, because administrators and operators should not connect to critical infrastructure directly from local machines that may be phished, infected, or poorly managed.
· BYOD users should work through VDI wherever sensitive applications or data are involved, because VDI reduces dependency on personal device posture and keeps enterprise data inside the controlled environment.
· Vendor and third-party access should be pushed toward VDI as much as possible, because external users typically introduce the highest variability in device hygiene, patch level, and operational discipline.
This is also the right design for selective application protection. Not every application needs VDI, and not every user needs a full virtual desktop all the time.
But the most sensitive modules, privileged workflows, regulated data paths, and critical operations should be isolated rather than merely brokered.
ZTNA versus VDI is the wrong framing
The right architecture is not ZTNA versus VDI. It is ZTNA for scalable secure access, and VDI for true isolation where risk is highest.
ZTNA remains the better option than legacy VPNs for broad-based access because it authenticates every connection, restricts lateral movement, and scales cleanly for large user bases.
But when the security question becomes, “What if the authorized endpoint is already compromised by AI-assisted malware?” then ZTNA’s strengths are no longer enough on their own.
At that point, the key requirement is to break the direct trust relationship between the endpoint and the application.
That is what VDI does.
The new problem of ZTNA
The new problem is not that ZTNA is weak. The new problem is that the market often asks ZTNA to solve a problem it was never designed to solve.
ZTNA is designed to control access. It is not designed to fully isolate application execution from the endpoint. As long as a legitimate user’s device can still interact with the target app through an approved session, a sufficiently advanced piece of malware can try to exploit that path. With AI models accelerating vulnerability discovery and payload adaptation, that gap becomes more dangerous than before.
For organizations protecting critical workloads, the lesson is clear: hiding applications from the internet is not the same as isolating them from compromised endpoints. And against AI-assisted malware, isolation is the stronger defense.
Closing argument
The future of secure access will not be built on visibility reduction alone. It will be built on a combination of identity control, policy enforcement, traffic inspection, and most importantly, isolation where it matters most.
ZTNA should remain the default control for modern application access because it is materially better than legacy network-centric models.
But for privileged users, server administrators, BYOD users, vendors, and anyone touching crown-jewel applications, VDI should be treated as the security boundary that truly separates the endpoint from the application.
In the AI era, that distinction is no longer academic. It is the difference between inspecting an attack path and eliminating it.