Why VPN Access Is Being Replaced by Zero Trust — and What Changes

TL;DR — Traditional VPNs are being replaced because they grant broad network access after a single login, which is hard to secure, hard to scale, and frustrating for users. The most common replacement is zero trust network access (ZTNA, access based on identity and device checks per app), which means you usually stop "joining the whole office network" and instead sign in to each internal app through your browser or company identity provider. Reading time: ~7 min

What it is and where it sits

A VPN (virtual private network, an encrypted tunnel into a private network) was designed to make your laptop behave as if it were inside the office. Once connected, your device could often reach many internal systems: file shares, databases, admin panels, staging sites, and other services that were never meant for the public internet.

What is replacing it is usually called zero trust access or ZTNA. Instead of connecting your whole device to the company network, it connects you to one approved application at a time, based on identity, device posture (basic device health checks), and policy.

That sounds subtle, but the architecture changes a lot:

• Old model: your laptop joins the internal network, then tries to reach apps.
• New model: you authenticate first, then a gateway or proxy connects you only to the specific app you’re allowed to use.

In a typical setup, the new access layer sits between the user and the private app. It talks to:

• your identity provider (IdP, the login system such as Google Workspace, Microsoft Entra ID, or Okta)
• your device management system, if you use one
• the private app itself, usually over HTTPS (web traffic secured by TLS, the standard encryption behind the padlock in the browser)

It replaces the old “VPN concentrator” or “VPN gateway” that accepted a tunnel from the whole device.

[User Browser] ---- 1. open app.example.com ----> [Access Proxy]
[User Browser] <---- 2. redirect to login ---- [Access Proxy]
[User Browser] ---- 3. sign in ----> [Identity Provider]
[Identity Provider] ---- 4. identity result ----> [Access Proxy]
[Access Proxy] ---- 5. allowed request ----> [Private App]
[Private App] ---- 6. response ----> [Access Proxy]
[Access Proxy] ---- 7. page ----> [User Browser]

In plain English: instead of first giving your laptop a network path to everything, the system checks who you are and then brokers access to one app.

That is why people say “the VPN is being replaced.” In many companies, it is not disappearing overnight for every use case. It is being narrowed down to the few things that still truly need network-level access, while browser-based internal tools move to app-level access.

How it actually works

Let’s walk through one realistic example: an employee opens an internal admin dashboard at https://admin.example.internal, and the company has moved that app off the VPN and behind a zero trust access proxy.

Step-by-step example

1. The user opens the app URL in a browser. The DNS record for admin.example.internal points to the access proxy, not directly to the app server.

2. The proxy checks for a valid session. If there is no session cookie (a browser token proving prior login), the proxy redirects the user to the company login page.

3. The user signs in with the normal company account. This is usually the same login already used for email and SSO (single sign-on, one login used across many apps).

4. The identity provider returns claims. “Claims” are simple facts like email address, group membership, and whether multi-factor authentication was completed.

5. The proxy evaluates policy. Example policy:

   • user must be in the admins group
   • login must include MFA (multi-factor authentication, such as an authenticator app code)
   • device must be marked compliant by device management
   • access allowed only from certain countries or IP ranges if required

6. If approved, the proxy forwards the request to the private app. The app server may live on a private subnet with no public IP at all. The user never gets direct network access to that subnet.

7. The app responds normally. To the user, it feels like opening a website after signing in. There is no separate “connect VPN” step.

8. On later requests, the proxy keeps re-checking context. This is a big difference from classic VPNs. Access can be re-evaluated per request or per short session, instead of trusting the device for hours after one connection.

What changes for you as a customer

Usually, three things change:

• You open an app URL directly instead of launching a VPN client first.
• Login becomes more visible because access is tied to identity and MFA.
• Access becomes narrower: being allowed into one app does not imply access to neighboring systems.

That narrower access is the point. If a laptop is compromised, the attacker does not automatically inherit broad network reach just because the VPN was connected.

When to use it (and when not to)

Zero trust access is a strong fit for internal web apps, admin panels, dashboards, and APIs used by people or controlled services. It is a weaker fit for legacy protocols that assume full network presence.

You probably don’t need this if...

• your team only has a few engineers and they only need SSH to a couple of servers
• your critical systems are not browser-based and cannot be fronted by a proxy
• you need machine-to-machine private networking, not human access
• your current pain is unreliable home internet, not over-broad internal access

You probably should prioritize it if...

• staff and contractors need access to internal web tools
• you are tired of “VPN connected but app still broken” support tickets
• you want to remove public exposure from admin tools
• you need cleaner offboarding: disable the user account and access stops everywhere
• you want access decisions tied to SSO, MFA, and device status

Trade-offs

This change is usually worth it, but it is not free.

Two trade-offs matter most in practice:

It reduces network risk, but increases identity importance

If access is now based on SSO, your identity provider becomes part of the critical path. That is usually a good trade, but it means your login system, MFA, and group memberships need to be treated as production infrastructure.

It improves web app access first, not every protocol equally

If your world is mostly browser-based tools, this transition feels clean. If you rely on SMB file shares, old ERP clients, or broad office LAN assumptions, the migration is slower and sometimes partial.

In practice

Below are two examples you could adapt today: one DNS setup pattern and one reverse proxy pattern. These are generic building blocks often used during a move away from VPN-only access.

Example 1: Point an internal app hostname at an access layer

In your DNS provider’s dashboard, go to your zone for the domain, then add a CNAME record. The exact menu varies by provider, but it is usually something like DNS → Records → Add record.

Type: CNAME
Name: admin
Target: access-gateway.example.net
TTL: 300

This makes admin.yourdomain.com resolve to your access gateway instead of directly to the app server. The gotcha: the app itself must trust the forwarded host header and generate links for admin.yourdomain.com, not its old private hostname.

Example 2: Keep the app private behind nginx

⚠️ Changing reverse proxy settings can cause downtime if you reload a broken config. Test the config before reloading.

If your app server is still using nginx internally, you can keep it listening only on a private interface and let the access layer connect to it.

server {
    listen 10.0.2.15:443 ssl;
    server_name admin.internal.local;

    ssl_certificate /etc/nginx/tls/admin.internal.local.crt;
    ssl_certificate_key /etc/nginx/tls/admin.internal.local.key;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Host $host;
    }
}

This keeps nginx reachable only on a private IP (10.0.2.15) while still serving the app to the access proxy. The gotcha: many apps need X-Forwarded-Proto and X-Forwarded-Host to generate correct redirects and callback URLs.

To validate and reload on a Linux server:

sudo nginx -t
sudo systemctl reload nginx

The first command checks the config syntax; the second applies it without a full restart. If nginx -t reports an error, stop there and fix it before reloading.

Example 3: Restrict direct network exposure with a firewall

⚠️ Firewall changes can lock out administrators or production traffic. Apply changes from a console session or with a tested rollback plan.

If your app server currently allows direct inbound HTTPS from anywhere, narrow it so only the access layer can reach it.

sudo ufw allow from 10.0.1.20 to any port 443 proto tcp
sudo ufw deny 443/tcp
sudo ufw status numbered

This allows HTTPS only from 10.0.1.20 (for example, your access proxy or connector) and denies everyone else. The gotcha: rule order matters, so always check the resulting numbered rules before you log out.

Further reading

• NIST SP 800-207 Zero Trust Architecture
• Google BeyondCorp papers
• The "Authentication" and "HTTP access control (CORS)" sections of the MDN Web Docs
• nginx Reverse Proxy guide
• OpenID Connect Core 1.0

This article was written by an AI system and published pending human review. Verify anything you intend to act on.