🇮🇩 Baca artikel ini dalam Bahasa Indonesia
TL;DR: The overnight shift to remote work has exposed the limitations of traditional VPN architectures. Zero trust remote access offers a fundamentally different security model — one that assumes no user or device is inherently trusted. But ripping out your VPN overnight is neither practical nor advisable. The right strategy depends on your current architecture, risk profile, and operational maturity.
Six Months In, and the Cracks Are Showing
Six months ago, most organizations treated remote access as a convenience — something for traveling executives and the occasional work-from-home Friday. Then March 2020 happened. Entire workforces went remote in days, not months. IT teams scrambled to scale VPN infrastructure that was never designed to handle 100% of employees connecting simultaneously from home networks of wildly varying quality and security.
I have spoken with dozens of IT leaders since the pandemic began, and the pattern is consistent: VPN licenses were panic-purchased, bandwidth bottlenecks appeared immediately, and help desks were overwhelmed with connectivity issues. More concerning, security teams noticed lateral movement risks they had previously accepted as manageable suddenly becoming existential. This is the context in which zero trust remote access has moved from a forward-looking concept to an urgent boardroom conversation.
The question I keep hearing is simple: should we stick with VPN, move to zero trust, or run both? The answer, as usual, is “it depends” — but I can help you figure out what it depends on.
Understanding the Traditional VPN Model
Virtual Private Networks have been the default remote access mechanism for over two decades. The concept is straightforward: create an encrypted tunnel between the remote user’s device and the corporate network. Once connected, the user is effectively “inside” the network perimeter and can access resources as if they were sitting at their office desk.
This model works reasonably well under specific conditions:
- A relatively small percentage of the workforce is remote at any given time
- Most applications and data reside on-premises
- The organization has a clearly defined network perimeter
- IT can enforce endpoint compliance before granting VPN access
The fundamental assumption behind VPN is perimeter-based trust: once you are inside the wall, you are trusted. This made sense when “inside” meant a physical office with managed devices on a controlled network. It makes far less sense when “inside” means a personal laptop on a shared home Wi-Fi network, with the family’s smart TV and a teenager’s gaming console on the same subnet.
Where VPNs Break Down at Scale
The problems I have seen most frequently in 2020 fall into three categories:
Performance and scalability. VPN concentrators have finite capacity. When 5,000 employees need simultaneous connections instead of the usual 500, you hit hardware limits, licensing ceilings, and bandwidth constraints. Backhauling all traffic through a central data center adds latency, especially for cloud-hosted applications — which is ironic, since traffic goes from the user’s home to the data center to the cloud and back again.
Overly broad access. Most VPN implementations grant network-level access. Once connected, a user can often reach far more resources than their role requires. An accounts payable clerk connected via VPN may technically be able to reach engineering servers. The attack surface is enormous, and if a credential is compromised, the attacker inherits that same broad access.
Endpoint visibility gaps. Traditional VPN solutions verify the user’s identity at connection time but often do limited continuous validation of device posture, user behavior, or contextual risk factors throughout the session.
What Zero Trust Remote Access Actually Means
Zero trust is not a product you buy. It is an architectural philosophy, most commonly associated with the model Forrester Research analyst John Kindervag articulated in 2010. The core principle: never trust, always verify. No user, device, or network location is inherently trusted. Every access request is evaluated individually based on identity, device health, context, and policy.
In practical terms, a zero trust remote access architecture differs from VPN in several critical ways:
| Dimension | Traditional VPN | Zero Trust Remote Access |
|---|---|---|
| Trust model | Trust after authentication at the perimeter | Continuous verification; no implicit trust |
| Access scope | Network-level access | Application-level access (micro-segmented) |
| Visibility | Limited once connected | Continuous monitoring of user and device behavior |
| Network exposure | User joins the network | Applications are hidden; user connects only to authorized resources |
| Cloud readiness | Requires backhauling or split tunneling | Natively supports direct-to-cloud connections |
With zero trust, the network itself becomes less relevant. A remote employee accesses specific applications through an identity-aware proxy or broker. They never “join” the corporate network. The applications themselves are invisible to anyone who has not been explicitly authorized and verified. This dramatically reduces the attack surface.
The NIST Framework for Zero Trust
For organizations looking for structured guidance, NIST Special Publication 800-207 (published in August 2020) provides a vendor-neutral zero trust architecture framework. It defines three core approaches:
- Enhanced Identity Governance — access decisions driven by identity and policy, often using an identity-aware proxy
- Micro-Segmentation — network-level segmentation that restricts lateral movement by placing granular controls around individual workloads
- Software-Defined Perimeter (SDP) — network infrastructure is hidden from unauthorized users; access is brokered on a per-session basis
Most real-world zero trust implementations combine elements of all three. The point is not to pick one but to understand which components address your specific risk profile.
Making the Case: VPN, Zero Trust Remote Access, or a Hybrid Approach
Here is where I push back on the binary framing. The question is not “VPN or zero trust?” — it is “where are we today, and what is the most responsible path forward?”
When VPN Still Makes Sense (For Now)
If your organization is heavily on-premises — legacy ERP systems, file servers, thick-client applications — VPN remains a practical necessity. Zero trust solutions excel at brokering access to modern, web-based applications. They are less elegant when the resource in question is a 15-year-old accounting system that requires a direct network connection to function.
VPN also makes sense as a short-term solution when you need immediate capacity and your team lacks the expertise to implement zero trust architecture safely. A poorly implemented zero trust model can create worse outcomes than a well-managed VPN.
When Zero Trust Should Be the Priority
If your environment is predominantly cloud-based — SaaS applications, IaaS workloads, modern web applications — zero trust remote access should be your primary strategy. The benefits compound:
- Reduced attack surface: Applications are not exposed to the internet. Users connect only to what they are authorized to access.
- Better user experience: No VPN client to connect. Direct-to-cloud routing eliminates the backhaul latency penalty.
- Continuous risk assessment: Device posture, user behavior, and contextual signals are evaluated throughout the session, not just at login.
- Simplified compliance: Granular access logs make it easier to demonstrate least-privilege access for auditors.
The Hybrid Reality
Most organizations I work with in October 2020 are operating in a hybrid state — and will be for some time. They have legacy systems that require network-level access alongside modern SaaS tools that are better served by zero trust. The practical approach is to run both, with a clear migration roadmap.
Here is the framework I use when advising clients:
- Inventory your applications — categorize by deployment model (on-prem, IaaS, SaaS), sensitivity, and user population
- Identify high-value migration candidates — cloud-hosted applications with broad user bases benefit most from zero trust first
- Maintain VPN for legacy access — but restrict scope. Segment VPN access so users only reach the specific legacy systems they need
- Implement identity as the control plane — regardless of VPN or zero trust, strong identity management (MFA, conditional access, device compliance) is non-negotiable
- Set a sunset timeline — VPN should become the exception, not the rule. Define milestones for migrating workloads and decommissioning VPN dependencies
Implementation Realities and Common Pitfalls
I want to be direct about something: zero trust is conceptually elegant but operationally demanding. The organizations that struggle most are those that treat it as a technology purchase rather than an architecture change.
Identity maturity is a prerequisite. Zero trust depends on reliable, consistent identity. If your identity infrastructure is fragmented — multiple directories, inconsistent MFA enforcement, orphaned accounts — you need to fix that first. No zero trust solution will compensate for an identity mess.
Device visibility matters more than you think. You cannot make trust decisions about endpoints you cannot see. Endpoint detection and response (EDR) tools, mobile device management (MDM), and device health attestation are foundational, not optional.
Do not underestimate change management. Users accustomed to VPN will have questions. IT staff managing network-centric security tools will need retraining. Application owners will need to participate in policy definition. This is an organizational change, not just a technical one.
Vendor selection requires scrutiny. The market is flooded with “zero trust” branding. Every CASB, SDP, ZTNA, and SASE vendor claims the label. Evaluate against NIST 800-207 principles, not marketing copy. Ask vendors to demonstrate how they handle your specific legacy integration challenges, not just their greenfield scenarios.
Frequently Asked Questions
Is zero trust remote access only for large enterprises?
No. The principles apply at any scale. In fact, smaller organizations with predominantly cloud-based environments can often adopt zero trust faster because they have fewer legacy dependencies. Several vendors offer zero trust network access (ZTNA) solutions with pricing models accessible to mid-market companies. The key requirement is not company size — it is identity maturity and a clear understanding of your application landscape.
Can I implement zero trust without replacing my existing VPN?
Absolutely, and for most organizations this is the recommended approach. Start by routing access to cloud applications through a zero trust broker while maintaining VPN for legacy on-premises systems. Over time, as you modernize or retire legacy workloads, the VPN footprint shrinks. This phased approach reduces risk and avoids the disruption of a wholesale cutover.
How does zero trust affect end-user experience?
When implemented well, zero trust typically improves the user experience. Users connect directly to applications without launching a VPN client, waiting for tunnel establishment, or dealing with split-tunneling issues. Authentication is handled through single sign-on and adaptive MFA. The friction decreases, not increases — which is one of the strongest arguments for executive buy-in.
What is the relationship between zero trust and SASE?
Secure Access Service Edge (SASE), a framework coined by Gartner in 2019, converges network and security services into a cloud-delivered model. ZTNA is a component of SASE, alongside SD-WAN, cloud access security brokers (CASB), and firewall-as-a-service. Think of SASE as the broader architecture and zero trust remote access as one of its core capabilities. Organizations pursuing SASE will naturally adopt zero trust principles, but you do not need a full SASE deployment to start implementing ZTNA.
Where This Is Heading
I do not think the VPN will disappear entirely — at least not in the next five years. Too many critical systems require network-level access, and migration timelines for legacy applications are measured in years, not quarters. But the direction is clear.
The pandemic has compressed a decade of remote work evolution into six months. Organizations that were already investing in identity-centric, cloud-native security are navigating this moment with significantly less friction. Those still dependent on perimeter-based models are feeling the strain acutely.
Zero trust remote access is not a trend. It is the logical endpoint of a security model that recognizes the perimeter has dissolved. Your users are everywhere. Your applications are everywhere. Your security model needs to follow.
My recommendation: start with identity. Get MFA and conditional access right. Inventory your applications. Pick two or three high-impact candidates for ZTNA and run a controlled pilot. Keep VPN for what still needs it, but stop investing in it as your long-term architecture. The organizations that use this period to build a zero trust foundation — even incrementally — will be materially better positioned for whatever comes next.
