Remote Access in 2026: Stop Arguing VPN vs Zero Trust and Build a Portfolio
If I have to sit through one more sales pitch telling me that “VPN is dead” and that their specific ZTNA product is the silver bullet for my entire enterprise, I might scream.
The industry loves a winner-take-all debate. For the last five years, we have been told that we are in a binary transition: you are either on the sinking ship of legacy VPN, or you are on the pristine life raft of Zero Trust.
But as an architect, I don’t live in a sales deck. I live in reality. And the reality is that our requirements are messy and heterogeneous. We have employees needing seamless SaaS access, third-party vendors needing restrictive access to HVAC controllers, sysadmins managing domain controllers, and legacy AS/400 workloads that will never speak modern web protocols.
Every couple of months, the same conversation shows up in security circles. Someone posts that VPN is dead. Someone else replies that Zero Trust is just marketing for “VPN with MFA.” A third person jumps in with screenshots of a ZTNA console and declares victory. Meanwhile, inside actual organizations, people are just trying to get a stable connection to the systems they need without blowing up audit findings or creating the next incident.
The reality in 2026 is pretty simple: if you are running a non-trivial environment, you already have a remote access portfolio. You might not call it that, and you might not have designed it that way on purpose, but it is there. Employees use one path, admins use another, vendors use something entirely different, and legacy workloads quietly hang off a classic full tunnel VPN.
The problem is not that multiple patterns exist. The problem is that they grew organically, without clear intent, so your risk exposure is shaped more by history and convenience than by design. The work now is not to pick a single “winner.” The work is to treat remote access as an explicit portfolio, decide what belongs in it, and make the patterns hang off the same set of principles.
The false choice: VPN vs Zero Trust
The VPN versus Zero Trust argument survives because it is emotionally satisfying. It offers a story that goes like this: the old way was VPN, the new way is Zero Trust, and if you buy the right product and flip the switch, you can retire one and replace it with the other.
That story fits nicely in a slide deck. It does not match what most architects see when they look at their environment.
A payroll vendor still requires a traditional IP based connection. A critical thick client only speaks to a database over a specific subnet. Operations staff need full interactive desktops to manage older systems. At the same time, new internal applications are written for browser access and can sit behind an identity aware proxy with device checks. Security wants privileged access to flow through a separate tool entirely so you can record sessions and handle just in time workflows.
Those are not “use VPN” versus “use Zero Trust” questions. They are “what is the right shape of access for this class of work” questions.
Once you admit that your environment has multiple kinds of work, the winner take all framing stops making sense. You are no longer arguing about whether VPN or ZTNA is superior in the abstract. You are deciding how each pattern earns its place and where its boundaries are.
The real perimeter is not the network
The other reason the VPN versus Zero Trust debate is misleading is that it keeps attention on the transport rather than the trust anchor.
For years, the mental model was simple: the corporate network was the trusted place. If you were on it, you were “inside.” If you were not, you were “outside.” VPN was the extension cord that pulled the inside out to where you were. Everything else was detail.
That model never really matched how attackers operate, and it certainly does not match how modern environments operate. Users are on unmanaged networks all the time. Devices move between home, office, and public spaces. Applications live in multiple clouds and third party platforms. The idea that there is one “inside” is more nostalgia than reality.
In practice, the perimeter in 2026 is made up of a few different signals: who you are, what you are using to connect, what you are trying to reach, and what is happening in the session. Identity, device posture, location, and runtime behavior do more to determine trust than the IP address you came from.
That shift is important because it means remote access patterns have to plug into identity and device controls first, not network location first. Whether the transport is a VPN tunnel, a ZTNA connector, or an RDP session into a hardened desktop, it should be hanging off the same identity system and the same view of device health. Otherwise you end up with parallel universes of trust that drift apart.
The four remote access patterns you actually run
If you walk through most large organizations and trace how people connect, you usually find four stable patterns hiding in plain sight.
The first is some form of enterprise remote desktop. It may be a classic RDS farm, a modern virtual desktop solution, or a cloud hosted service that delivers complete workstations. The point of this pattern is containment. You are not punching holes back to every internal subnet. You are delivering a full desktop in a controlled environment, then letting people connect to that from a variety of endpoints. This is often where high risk or regulated workflows belong, especially when you cannot fully trust the client device.
The second pattern is application specific remote access, what the industry has decided to label ZTNA. Instead of dropping you onto a network, it publishes specific web apps, APIs, or services behind an identity aware proxy. You authenticate, your device is checked, policies are applied, and you get access to that one resource rather than an entire segment. This pattern shines for modern internal applications that already speak HTTP or similar protocols and where the teams are willing to live behind an identity platform.
A third pattern is privileged remote access. This is remote access for administrators and vendors who can make big changes. It tends to sit on top of the other two patterns, but with tighter controls. Think credential vaulting, jump hosts, session recording, approval workflows, and just in time elevation. It is the place where Tier 0 lives, even if no one wants to use that term in meetings.
The last pattern is legacy VPN. No matter how many articles declare it obsolete, it is still there in 2026. Some workloads cannot migrate easily. Some internal tools are welded to network locations. Some acquisitions have their own expectations. Full or split tunnel VPN remains the blunt instrument that connects entire device networks to entire corporate networks. For a decision framework on which workloads should stay on VPN and which should move, see VPN Strategy in 2026.
None of these patterns are inherently good or bad. They are tools. The problem shows up when you ask a pattern to do something it was never designed for. Using full tunnel VPN for vendor access to a critical regulated environment, with shared accounts and no session control, is not a “VPN problem.” It is a portfolio problem.
Matching use cases to patterns
If you treat remote access as a portfolio, the core design work becomes a mapping exercise. You look at classes of use case and decide which pattern they belong on and why.
For a typical knowledge worker who only needs SaaS and a few internal line of business apps, application specific access backed by strong identity is usually the right answer. They authenticate through your identity provider, device posture is evaluated, and they land directly in the apps they need. No network level exposure, no arbitrary lateral movement.
Providing a way in for a vendor who needs to administer a specific system, the right shape is often a privileged remote access path that drops them into a controlled jump host or a constrained desktop. Credentials are handled by your vault. Their session is recorded. Their access is constrained to the systems they are contracted to manage.
Remote access for admins who handle domain controllers or other Tier 0 systems, you may decide that their normal day to day work happens on eRDS or a similar environment that never lives on the same device they use for email and web browsing. Their remote access is then a two stage process: first into the privileged desktop, then from there into the sensitive systems.
Securing niche legacy applications that only work when the client appears on a specific subnet, VPN might still be the only practical option for now. The key is that you treat it as a contained pattern with clear boundaries and a roadmap, not as the default way that everything connects.
When those decisions are made explicitly and written down, two good things happen. First, your remote access requests stop being one off arguments with every project team, because you can point to a set of patterns and say “this is how we do this class of work.” Second, it becomes much easier to see where risk is out of alignment, because you can identify the use cases that are on the wrong pattern entirely.
Principles that hold the portfolio together
Portfolios are only manageable if they hang off a shared spine. Otherwise they turn into a junk drawer.
For remote access, that spine usually comes down to a handful of principles.
Identity and device form the trust decision. Every pattern, from VPN to PRA, should plug into the same identity provider and device posture signals. If the organization decides that unmanaged devices cannot reach certain data types, that rule should not depend on whether the transport is a tunnel or an app proxy.
That identity-centric model is incomplete if you only govern humans. Service principals and workload identities are often the cleanest route around those controls, which is why Workload Identities Are the Real Perimeter.
Least privilege and segmentation apply everywhere. VPN configurations should minimize what is reachable by default. ZTNA policies should publish only what is needed, not “all internal.” eRDS environments should separate high risk desktops from general purpose ones. Privileged access solutions should enforce separation between admin sessions and everyday work.
Admin and vendor access get extra controls. This is where you lean harder on just in time access, approval workflows, and additional factors. Normalizing that expectation in the portfolio prevents “special cases” from quietly becoming the rule.
Remote access products are treated as Tier 0. The systems that decide who can reach what are themselves crown jewels. Their management interfaces should live in protected enclaves. Changes should be controlled through the same rigor you use for identity, directory, and core key management services.
Once those principles are agreed and repeated enough, they become the way you judge changes. A new tool that plugs cleanly into identity and respects device posture has a chance of joining the portfolio. A tool that wants to introduce its own parallel identity universe should raise alarm bells.
The messy reality: drift and shadow access
On a whiteboard, portfolios look tidy. In real environments, they collect drift.
Temporary VPN rules do not get removed after a project ends. A “quick” exception for a vendor becomes a permanent hole. A team stands up their own remote access gateway for a pilot and forgets to decommission it. A cloud environment inherits security groups and peering arrangements from three different acquisitions and no one is quite sure what talks to what anymore.
Shadow remote access often appears wherever official patterns are too slow, too rigid, or too hard to use. When the path of least resistance is a long approval process and outdated tooling, people will find a way around it. They will set up backdoor tunnels, bypass centralized controls, or reuse credentials in places you did not intend.
Treating remote access as a portfolio does not magically eliminate this mess, but it gives you a way to talk about it.
You can inventory actual paths into your environment and classify them as “in portfolio” or “out of portfolio.” You can look at out of portfolio paths and decide case by case whether to migrate them to an existing pattern, redesign the pattern, or deliberately accept the risk for a period of time. You can adjust friction on the “good” patterns so that they are easier to adopt than rolling your own.
Most important, you can stop treating each discovery as a personal failure and instead as evidence that your portfolio and your organization’s needs were out of sync. That is something you can fix.
What “good” looks like in 2026
A mature remote access portfolio in 2026 does not look like a world where VPN has vanished. It looks like a world where VPN is no longer the reflex answer to every question.
Most employee access to internal apps flows through identity aware access solutions that evaluate user and device context on each connection. A meaningful chunk of high risk or regulated work flows through remote desktop environments that are locked down and monitored. Administrators and vendors use a privileged access platform that gives the organization control over credentials, sessions, and approvals.
VPN still exists, but its footprint is smaller and more deliberate. It is used for specific legacy workloads or controlled connectivity between environments, not as the default way to feel “inside.” Its exposed interfaces are minimized, and it is surrounded by the same level of care you would give any other Tier 0 component.
From the outside, this does not look flashy. There is no single product that saves the day. Instead, there is a small set of patterns, each with a clear purpose, and a rhythm in how they evolve over time as applications move, vendors change, and infrastructure shifts.
The benefit is not only technical. When someone asks “how do we provide remote access for this new thing,” you are no longer inventing the answer from scratch. You are inviting that use case into a portfolio that already has language, controls, and expectations.
Moving from where you are to where you want to be
Getting from a tangle of tunnels and exceptions to a coherent portfolio is not a one quarter project. It is more like a one to two year refinement loop, and it needs to run alongside everything else you are doing.
A practical starting point is inventory and classification. Map the ways people currently connect: VPN concentrators, remote desktop gateways, jump hosts, cloud bastions, vendor tools, and one off ports that never got closed. For each one, ask a basic question: which pattern is this trying to be, and who uses it.
Then define, in plain language, what your “official” patterns are. You might decide that you support three or four for now, with a clear description of who should be on each and what controls apply. Write that down somewhere visible. Socialize it with security, infrastructure, and application teams. Make it the default reference when someone requests a new path.
As you execute other work, use every touchpoint as a chance to align with the portfolio. A cloud migration project is an opportunity to move an app from VPN to ZTNA. A vendor renewal is a chance to bring their access path under your privileged access platform. A major endpoint refresh can enforce new device posture expectations.
None of this requires a big bang cutover. It requires persistent, opportunistic alignment over time, backed by the same principles every time the conversation comes up.
You will still have exceptions. You will still have pockets of “we cannot change this yet.” What changes is that those pockets are clearly identified, surrounded by compensating controls where possible, and show up on a roadmap rather than quietly living under the radar.
The portfolio is the strategy
It is tempting to talk about remote access as if the main decision is which product to buy next. In practice, the enduring decision is how you want work to reach your systems, and what you are willing to tolerate when that work does not match the ideal.
In 2026, the organizations that are in the best shape are not the ones that “eliminated VPN” or “went all in on Zero Trust.” They are the ones that accepted early that they would always have multiple patterns, then took ownership of that fact and turned it into a design problem.
They defined a small portfolio. They tied it tightly to identity and device. They treated remote access infrastructure as Tier 0. They cleaned up drift as they found it. They used ongoing projects to migrate use cases toward better patterns over time.
If you are building or refactoring your own approach, that is the work. Choosing tools is part of it, but only part. The real leverage is in the portfolio itself and the clarity around how people, devices, and applications are allowed to connect.
Remote access in 2026 is not about betting on a single technology. It isn’t about buying the quadrant leader and installing an agent. It is about managing an ecosystem that reflects the messy reality of enterprise IT.
The work of the architect is not to pick a winner. It is to shape a portfolio with clear boundaries, strict controls, and consistent expectations. We stop looking for the silver bullet and start building a better arsenal.
