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 by default. 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 [Source: IBM Security, 2025]. Based on 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.

Why Does Zero Trust Architecture 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, the network 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. Traditional castle-and-moat perimeter security fails structurally in this model.

The perimeter approach 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 and per session, a requirement that is incompatible with VPN-based access models.

Three structural flaws make perimeter security unfit for SaaS cloud security posture:

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 that scales poorly as service counts grow.

BeyondCorp, Google's internal implementation of zero trust, eliminated VPN access for its entire workforce of over 60,000 employees and shifted to identity-aware proxy controls at the application layer [Source: Google BeyondCorp Research, 2014-2020]. That model is now the architectural foundation for enterprise ZTNA adoption globally.

"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 security boundary shifts from the network to the identity.

The following table contrasts perimeter security and zero trust across the factors that matter most in a SaaS security architecture review:

Based on 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 with mutual TLS (mTLS) and least privilege enforcement 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 and not from a rogue process inside the cluster.

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

The shift from network-centric to identity-centric security is difficult because it requires replacing IP addresses as a trust signal with cryptographic identity. That means every application in the environment must participate in the trust chain, and 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, whether Okta, Google Workspace, or Azure AD. Legacy tools that only support Basic Auth or have no authentication layer 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 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 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. Microsegmentation at the network layer works alongside ZTNA to limit lateral movement even when IAP performance degrades.

"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 header on every request.

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, consistent with NIST 800-207's requirement for continuous verification.

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

Based on Seven Labs' VAPT penetration testing and security architecture engagements, three antipatterns recur when organizations attempt ZTNA migrations without disciplined execution. Each one undermines the SaaS security guarantees the architecture is designed to provide.

Ignoring legacy applications. Modern SaaS services understand OAuth or OIDC natively. Legacy internal tools, including ticket systems, internal wikis, and 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. Based on Seven Labs' engagements, organizations that retain a parallel VPN during ZTNA migration experience credential-based attacks targeting that VPN within a median of 47 days of deployment.

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: Zero Trust Architecture

Does zero trust architecture eliminate the need for network segmentation and microsegmentation?

No. Zero trust and microsegmentation are complementary controls. ZTNA enforces application-level access at Layer 7. Network segmentation limits lateral movement at the network layer. NIST SP 800-207 recommends both. Removing microsegmentation while deploying ZTNA increases risk if the identity-aware proxy itself has an exploitable vulnerability.

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 for a SaaS organization?

Any finding at CVSS 7.0 or above affecting authentication, session management, or network access controls requires an immediate review. Based on 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, not scheduled maintenance windows.

How long does a full ZTNA migration take for a mid-size SaaS company?

For a 50-200 person organization with 10-30 internal services, a full VPN replacement migration typically takes three to six months. Month one covers IdP integration and proxy deployment. Months two and three address per-application policy definition. Months four through six focus on upstream JWT validation, legacy app handling, and full VPN decommission.

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.