Why Your VPN Is a Liability: Zero-Trust Network Access in Modern SaaS

Zero-Trust Network Access (ZTNA) replaces VPN-based perimeter security with identity-aware, application-level authorization enforced on every request. The network is treated as hostile. Every request -- whether from a remote developer or a Kubernetes microservice -- must be authenticated, authorized, and continuously validated before access is granted.

The stakes are concrete: IBM's Cost of Data Breach 2025 report puts the average breach cost at $4.88 million USD. In Seven Labs' VAPT engagements, misconfigured VPN access controls appear in over 60% of network assessments, making them one of the most consistently exploited attack vectors in modern SaaS environments. The blast radius from a single compromised VPN credential routinely covers an entire production subnet.

What Is Zero Trust Architecture and Why Does It Matter More for SaaS Than Traditional Perimeter Security?

Zero trust architecture (ZTA) treats every access request as untrusted by default, regardless of network origin. For SaaS environments, this matters more than in traditional enterprise networks because the perimeter no longer exists: developers work remotely, services run across multi-cloud Kubernetes clusters, and third-party integrations multiply the attack surface on every release cycle.

The traditional castle-and-moat model grants broad network access once a VPN authenticates a user. In SaaS, that model creates lateral movement risk that is structurally unacceptable. Gartner forecasts that by 2026, at least 10% of large enterprises will have a mature, measurable zero trust program -- up from less than 1% in 2023. [Source: Gartner Zero Trust Security Forecast 2024]

NIST SP 800-207 defines zero trust as a framework requiring dynamic policy decisions per request, per session. This is incompatible with VPN-based access, which makes a single authorization decision at login and then grants persistent network-level access for the duration of the session.

Three structural flaws make perimeter security unfit for SaaS:

1. Implicit trust. Any entity operating from an internal IP address is trusted. A compromised developer laptop becomes a direct production tunnel with no additional authentication required.
2. Lack of granularity. VPNs operate at OSI Layer 3 or 4, granting subnet-level access rather than application-level access. Enforcing "Alice can access the metrics dashboard but not the billing API" requires a maze of network ACLs that few teams maintain correctly.
3. Performance bottlenecks. Routing all traffic through a central VPN gateway introduces latency and bandwidth constraints that scale poorly as service counts grow and remote workforce size increases.

"Identity is the new perimeter. Organizations that continue to rely on network location as a trust signal are making a security decision based on an architectural assumption that has not been valid for a decade." -- John Kindervag, Creator of Zero Trust Model, Palo Alto Networks

How Does Zero Trust Network Access Work Differently From a VPN?

ZTNA replaces the VPN gateway with an Identity-Aware Proxy (IAP) that mediates every HTTP request at Layer 7. Access decisions are made per-request, based on user identity, device posture, and contextual signals -- not on whether a connection originates from an internal IP address.

The difference is not incremental. The following table contrasts both approaches across the factors that matter most in a SaaS security architecture:

In Seven Labs' security architecture deployments, switching from VPN to ZTNA reduced the simulated blast radius of a compromised endpoint from full production network access to zero lateral movement past the initially targeted application.

The ZTNA request flow works as follows:

1. DNS resolves the internal service hostname to the IAP's public IP.
2. The browser initiates a TLS connection to the IAP.
3. The IAP checks for a valid cryptographic session cookie. If absent, it redirects the user to the IdP via OpenID Connect (OIDC).
4. The user authenticates with the IdP using phishing-resistant MFA such as a YubiKey or passkey.
5. The IdP returns an identity token to the IAP.
6. The IAP passes identity, device context, and requested URL to the Policy Engine.
7. The Policy Engine evaluates access rules: user role, device management status, time-of-day, and application sensitivity classification.
8. If authorized, the IAP forwards the request to the upstream application with a signed JWT injected into the request headers.
9. The upstream application validates the JWT to confirm the request passed through the trusted proxy -- not from a rogue process inside the cluster.

Why Is Transitioning From Perimeter Security to Identity-Aware Access Architecturally Difficult?

The shift from network-centric to identity-centric security is hard because it requires replacing IP addresses as a trust signal with cryptographic identity, and that means every application in the environment must participate in that trust chain. Most organizations have legacy internal tools that predate OIDC by a decade.

This creates three distinct operational problem areas:

Identity federation. Every application must integrate with the IdP -- Okta, Google Workspace, or Azure AD. Legacy tools that only support Basic Auth or have no authentication layer at all cannot plug into an OIDC flow without proxy-level translation or complete replacement.

Policy management. VPN access is binary: on the network or not. ZTNA policies are highly granular and contextual. Rules must account for user role, device management status (is disk encryption enabled? is endpoint detection installed?), and the sensitivity classification of the target application. This policy management overhead is real and requires dedicated tooling to sustain.

Performance at scale. Every request passes through the IAP for authentication and authorization. If the proxy adds 50-100ms per request, a microservices architecture making hundreds of internal calls per second degrades noticeably. The IAP must cache policy decisions and cryptographic key material to maintain acceptable latency at p99.

"The challenge with zero trust is not the technology -- it is the organizational change. Teams accustomed to VPN tunnels resist per-application policy management because it requires security thinking at the application layer, not the network layer." -- Chase Cunningham, VP Security Market Research, Forrester

How Do You Implement ZTNA With Pomerium on Kubernetes?

Pomerium is an open-source identity-aware proxy that integrates natively with standard IdPs and deploys on Kubernetes. Deploy it in front of any internal service to enforce zero-trust access policies without modifying application code. This guide targets Kubernetes v1.29+ with a Grafana dashboard as the protected service.

Step 1: Deploy Pomerium via Helm, configured against your IdP.

1# pomerium-values.yaml
2authenticate:
3  idp:
4    provider: google
5    clientID: "YOUR_GOOGLE_CLIENT_ID"
6    clientSecret: "YOUR_GOOGLE_CLIENT_SECRET"
7    serviceAccount: "base64_encoded_service_account_json"
8
9ingress:
10  enabled: true
11  className: "nginx"
12  hosts:
13    - authenticate.internal.yourcompany.com
14  tls:
15    - secretName: pomerium-tls
16      hosts:
17        - authenticate.internal.yourcompany.com
18
19config:
20  sharedSecret: "generate_a_random_base64_string_here"
21  cookieSecret: "generate_another_random_base64_string_here"

helm repo add pomerium https://helm.pomerium.io
helm install pomerium pomerium/pomerium -f pomerium-values.yaml --namespace pomerium --create-namespace

Step 2: Define access policy as code with a PomeriumRoute CRD.

1# grafana-route.yaml
2apiVersion: ingress.pomerium.io/v1
3kind: PomeriumRoute
4metadata:
5  name: grafana-secure-route
6  namespace: monitoring
7spec:
8  from: https://metrics.internal.yourcompany.com
9  to: http://grafana.monitoring.svc.cluster.local:80
10  policy:
11    - allow:
12        and:
13          - domain:
14              is: yourcompany.com
15          - claim/groups:
16              has: "engineering-team@yourcompany.com"

Step 3: Validate the Pomerium JWT assertion at the upstream application.

This is the step most teams skip. An attacker who compromises a pod inside the cluster can bypass Pomerium entirely by sending requests directly to the upstream service on its internal cluster address. True zero trust requires the upstream application to validate the

X-Pomerium-Jwt-Assertion

1func requirePomeriumAssertion(next http.Handler) http.Handler {
2    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
3        assertion := r.Header.Get("X-Pomerium-Jwt-Assertion")
4        if assertion == "" {
5            http.Error(w, "Missing Pomerium Assertion", http.StatusUnauthorized)
6            return
7        }
8
9        // Fetch Pomerium JWKS public keys and validate JWT signature
10        ctx := context.Background()
11        set, err := jwk.Fetch(ctx, pomeriumJWKSURL)
12        if err != nil {
13            http.Error(w, "Failed to fetch keys", http.StatusInternalServerError)
14            return
15        }
16
17        token, err := jwt.Parse(assertion, func(token *jwt.Token) (interface{}, error) {
18            if _, ok := token.Method.(*jwt.SigningMethodES256); !ok {
19                return nil, fmt.Errorf("unexpected signing method: %v", token.Header["alg"])
20            }
21            kid, ok := token.Header["kid"].(string)
22            if !ok {
23                return nil, fmt.Errorf("missing kid header")
24            }
25            key, ok := set.LookupKeyID(kid)
26            if !ok {
27                return nil, fmt.Errorf("key %v not found", kid)
28            }
29            var rawKey interface{}
30            if err := key.Raw(&rawKey); err != nil {
31                return nil, err
32            }
33            return rawKey, nil
34        })
35
36        if err != nil || !token.Valid {
37            http.Error(w, "Invalid Assertion", http.StatusForbidden)
38            return
39        }
40
41        next.ServeHTTP(w, r)
42    })
43}

By enforcing JWT validation at the application layer, the upstream service rejects requests regardless of their network origin. This is the property that makes network boundaries architecturally irrelevant and enforces least privilege access at the service level.

What Are the Most Common Failure Modes in Zero Trust ZTNA Deployments?

Based on Seven Labs' security architecture deployments, three antipatterns recur when organizations attempt ZTNA migrations without disciplined execution. Each one undermines the security properties the architecture is designed to provide.

Ignoring legacy applications. Modern SaaS services understand OAuth or OIDC natively. Legacy internal tools -- ticket systems, internal wikis, monitoring consoles -- often rely on Basic Auth or hardcoded IP allowlists. Do not attempt to rewrite these immediately. Use the IAP to inject Basic Auth headers or perform auth translation at the proxy layer. For non-HTTP protocols (SSH, RDP), choose a proxy with native tunneling support: Pomerium and Teleport both handle this correctly.

The "break glass" VPN antipattern. Teams deploy strict ZTNA policies but leave a parallel VPN running for emergencies. Attackers find and target the VPN because it is the weaker authentication path. The correct solution is building redundant IdPs and designing the IAP to cache policy decisions and cryptographic keys during brief IdP outages. The VPN must be decommissioned -- not retained as a fallback.

Alert fatigue from authorization logs. ZTNA logs every request as an authorization event. Sending all events to a SIEM without filtering buries the security team and causes real threats to go undetected. Focus monitoring on denied requests from known corporate devices and impossible travel events in identity logs. These are actionable signals. Raw authorization volume is noise.

Frequently Asked Questions

Does zero trust architecture eliminate the need for network segmentation? No. Zero trust and microsegmentation are complementary controls. ZTNA enforces application-level access at Layer 7. Network segmentation (microsegmentation) limits lateral movement at the network layer. NIST SP 800-207 recommends both. Removing network segmentation while deploying ZTNA increases risk if the IAP itself has a vulnerability that can be exploited from within the network.

Can ZTNA work for non-HTTP protocols like SSH and database connections? Yes, with protocol-aware proxies. Pomerium and Teleport both support tunneling for SSH, RDP, and database protocols over identity-aware connections. The proxy enforces the same identity and device posture checks before establishing the protocol tunnel, maintaining least privilege access and zero trust guarantees across all workload types.

What CVSS score should trigger an immediate ZTNA architecture review? Any finding at CVSS 7.0 or above affecting authentication, session management, or network access controls should trigger an immediate review. In Seven Labs' VAPT engagements, VPN misconfigurations consistently score between CVSS 8.1 and 9.8, placing them in High and Critical categories that require expedited remediation timelines, not scheduled maintenance windows.

How long does a full ZTNA migration take for a mid-size SaaS organization? For a 50-200 person organization with 10-30 internal services, a full migration typically takes 3 to 6 months. The first month covers IdP integration and proxy deployment. Months 2-3 address per-application policy definition. Months 4-6 focus on upstream JWT validation, legacy app handling, and decommissioning the VPN from the network entirely.

If your organization is still routing production traffic through a VPN gateway, contact Seven Labs' security engineering team for a ZTNA readiness assessment. Our VAPT penetration testing includes a dedicated network access control review that surfaces the specific misconfigurations attackers use to achieve lateral movement in SaaS environments. Related reading: BOLA Vulnerabilities in GraphQL APIs and VAPT Security Threats.