Decommissioning Legacy VPNs: A Zero-Trust Remote Access Architecture for the Enterprise

Executive Summary & Architecture Takeaways

• The Threat Reality: Compromised VPN credentials and unpatched VPN concentrators are a recurring initial-access vector in ransomware incidents. Once authenticated through a legacy VPN, a remote user typically has broad Layer 3 access to internal subnets.
• The Zero-Trust Paradigm: Replace the "trust the internal network" model with "never trust, always verify". Users never land on the corporate network; instead, application-specific connections are brokered per request based on device health, user identity, and session risk.
• Design Outcomes to Aim For:
  • Attack Surface Reduction: no inbound firewall ports for private applications (outbound-only inside-out connectors).
  • Latency: direct connection through the nearest cloud point of presence instead of centralized VPN backhaul.
  • Lateral Movement: sharply reduced. A compromised endpoint can only reach the specific application segments its user is entitled to, not entire subnets.

1. The Death of the Castle-and-Moat Perimeter

For two decades, corporate IT security relied on the castle-and-moat architecture:

1. Everything outside the firewall is untrusted (The Internet).
2. Everything inside the corporate LAN or VPN tunnel is trusted.

This architecture has three fatal flaws in the modern hybrid enterprise:

1.1 The Lateral Movement Playground

When an attacker compromises an engineer's laptop via phishing, the active VPN connection provides a direct route to database clusters, Active Directory domain controllers, and internal code repositories. Tools like BloodHound and Responder exploit this unsegmented Layer 3 visibility quickly.

1.2 Backhaul Bandwidth Choke Points

Forcing remote employees in London, Singapore, and São Paulo to route their traffic through a central datacenter in Dallas to access cloud workloads (AWS, Azure, SaaS) saturates WAN links and degrades video calls, file transfers, and development workflows.

1.3 Appliance Vulnerabilities

Internet-facing VPN appliances from several major vendors have repeatedly been targeted by advanced threat actors, with critical remote code execution vulnerabilities exploited in the wild (many appear in CISA's Known Exploited Vulnerabilities catalog). Every exposed concentrator is a patching race.

2. Zero-Trust Access Reference Topology

Below is a reference architecture for an enterprise deployment:

 +-------------------------------------------------------------------------+
 |                            IDENTITY PLANE                               |
 |   Microsoft Entra ID P2 + Conditional Access + Risk Engine + Intune MDM |
 +------------------------------------+------------------------------------+
                                      |
                           SAML / OIDC Token
                           Issuance & CAE
                                      |
 +------------------------------------v------------------------------------+
 |                             CONTROL PLANE                               |
 |     Zscaler Cloud Broker / Policy Enforcement Point (PEP)               |
 +------------------+------------------------------------+-----------------+
                    |                                    |
          Encrypted TLS Tunnel                 Encrypted TLS Tunnel
              (Port 443)                           (Port 443)
                    |                                    |
+-------------------v-----------------+   +--------------v-----------------+
|             USER PLANE              |   |          DATA PLANE            |
| Remote Workforce / Branch Offices   |   | Corporate VPCs & Private DC    |
| - Zscaler Client Connector (ZCC)    |   | - ZPA App Connectors (VMs)     |
| - Intune Device Compliance Enforced |   | - Outbound-only TLS connection |
| - FIDO2 Security Keys / WHfB        |   | - Core Enterprise Applications |
+-------------------------------------+   +--------------------------------+

3. Microsoft Entra ID Conditional Access Decision Tree

Access is determined not by network location, but by policy evaluation of identity, device and risk signals at every sign-in and token issuance.

3.1 A Conditional Access Policy Matrix

[Incoming Sign-in]
       |
       v
[Signal 1: User & Group Identity] ---> If Guest / Contractor -> Require MFA + 4h Sign-in Frequency
       |
       v
[Signal 2: Device Health & MDM]   ---> Is Device Intune Compliant?
       |                               |- NO  -> Block, or allow only via Virtual Desktop
       |                               |- YES -> Proceed
       v
[Signal 3: User Risk & Sign-in]   ---> Entra ID Protection
       |                               |- High User Risk -> Require Secure Password Change + MFA
       |                               |- Medium/High Sign-in Risk -> Require Phishing-Resistant MFA
       |                               |- Low Risk -> Proceed
       v
[Signal 4: Client Application]    ---> Modern authentication client?
       |                               |- NO  -> Block Legacy Authentication (POP/IMAP/SMTP AUTH etc.)
       |                               |- YES -> Proceed
       v
[Access Decision: GRANT with Controls]
       |- Require Authentication Strength: Phishing-Resistant MFA (FIDO2 / WHfB)
       |- CAE enforced (on by default; optional strict location enforcement)
       |- Defender for Cloud Apps Conditional Access App Control (block download of confidential data)

3.2 Eliminating AiTM Phishing with FIDO2 Security Keys

SMS, voice and push-notification MFA (including Microsoft Authenticator push with number matching) remain vulnerable to Adversary-in-the-Middle (AiTM) reverse-proxy attacks (for example, Evilginx-style kits), because the user can still be tricked into approving a sign-in relayed by the attacker's proxy.

To get phishing-resistant authentication:

1. Retire SMS and voice call MFA wherever possible.
2. Require FIDO2 security keys or passkeys or Windows Hello for Business (via a Conditional Access authentication strength) for administrative roles, engineers, and finance staff first, then expand.
3. These methods cryptographically bind authentication to the origin domain, so a credential harvested by a reverse proxy on a look-alike domain is not usable.

4. Micro-Segmentation with Zscaler Private Access (ZPA)

ZPA decouples applications from the physical network. The application is never exposed to the internet, and the user never joins the network where the application resides.

4.1 How Inside-Out Connectors Work

1. App Connectors are deployed in redundant pairs (as VMs or packages) inside each network that hosts private applications (AWS, Azure, on-premises vSphere).
2. The App Connectors establish outbound-only TLS connections to the Zscaler cloud on port 443.
3. No inbound firewall ports (80, 443, 22, 3389) need to be opened on perimeter firewalls for these applications.
4. When an authenticated user requests https://git.internal.epifive.com, the ZPA broker evaluates the user's identity attributes (from Entra ID via SAML/SCIM) and device posture against the access policy. If authorized, it stitches the user's outbound connection and the connector's outbound connection together.

4.2 Application Segment Granularity

Rather than granting access to an entire 10.100.0.0/16 CIDR block, access is restricted to discrete fully qualified domain names (FQDN) and explicit ports. A database administration segment, for example, would be defined along these lines in the ZPA admin portal or API:

5. Continuous Access Evaluation (CAE) & Session Revocation

A long-standing loophole in token-based authentication is token lifetime. If a session token is valid for 12 hours and an analyst disables the user's account 30 minutes after issuance, a stolen token remains usable until it expires.

With Continuous Access Evaluation (CAE) in Microsoft Entra ID and CAE-capable resource providers (Exchange Online, SharePoint Online, Teams, Microsoft Graph):

• The resource provider subscribes to critical events from Entra ID: user disabled or deleted, password changed or reset, sessions revoked by an administrator, MFA enabled for the user, and elevated user risk detected by ID Protection.
• When such an event occurs, the resource provider rejects the existing token and sends the client a claims challenge, forcing re-authentication. Microsoft documents that this is near real time, but event propagation can take up to about 15 minutes.
• CAE can also enforce Conditional Access IP-location policies at the resource, so a token used from an unexpected network can be rejected (strict location enforcement is configurable).
• Because revocation no longer depends on short lifetimes, CAE-aware sessions receive longer-lived tokens; the security benefit comes from the event-driven revocation, not from token expiry.

6. Migration Playbook & Cutover Strategy

Decommissioning VPNs without overwhelming the helpdesk requires a phased rollout. A typical four-stage plan looks like this:

1. Stage 1: Identity & Device Hardening (Weeks 1 - 4)
   • Enroll corporate devices in Microsoft Intune and define compliance policies.
   • Deploy FIDO2 keys or passkeys to all privileged administrators.
   • Block legacy authentication across the Entra ID tenant.
2. Stage 2: Connector Deployment & Discovery (Weeks 5 - 8)
   • Deploy ZPA App Connectors across internal datacenters and clouds.
   • Use broad wildcard application segments temporarily to discover which internal applications and ports users actually reach, without blocking traffic.
3. Stage 3: Application Segmentation & User Pilot (Weeks 9 - 14)
   • Define least-privilege application segments for the most-used enterprise workloads (for example SAP, GitLab, Jira, internal CRM).
   • Move a pilot group of technically confident users to Zscaler Client Connector and collect latency and helpdesk data.
4. Stage 4: Mandatory Cutover & VPN Decommission (Weeks 15 - 18)
   • Restrict remaining VPN pools to a small allow-list of legacy applications that cannot yet be published through ZPA, with a dated exit plan for each.
   • Replace the broad discovery segments with explicit segments, then turn off VPN concentrator public interfaces permanently.