intellimetrics Learning
Zero Trust Implementation Module 3 · Devices and Networks

Per-App Access, Not Perimeter

Last reviewed

Intermediate

What you'll learn

~20 min
  • Replace network-grants-access with per-app policy, one application at a time
  • Place ZTNA/SASE honestly: what it solves, where VPN legitimately persists
  • Avoid the edge-trust anti-pattern: verify the path, not just the peer

The VPN grants a network. Nobody needs a network.

Meridian’s VPN, like everyone’s, answers the question “may this person reach the network?” — and then the network’s flatness answers everything else. A phished contractor credential doesn’t get the dispatch app; it gets a subnet, and from the subnet, whatever listens. Tenet 2 (location grants nothing) has a concrete implementation, and this is its lesson: replace the network grant with per-application access decisions.

Perimeter world:  authenticate once ──► ON the network ──► lateral everything
Per-app world:    each app sits behind its own PEP; each request evaluated
                  by the PDP with full signals (identity + device compliance
                  from 3.1 + risk); the app is never "on a network" a user
                  can roam - it's a destination with a gate

The mechanism is ZTNA (zero-trust network access): a connector/broker fronts each private app, publishes it to the identity platform, and every session terminates at the broker — evaluated per-app, per-session, with your CA baseline’s conditions. The user experience is better than VPN (no client juggling, apps just work), which is why this is the rare security migration users cheer.

Why now: the edge became the beachhead

The 2024-26 exploit wave made this migration urgent rather than aspirational: internet-facing VPN concentrators and edge appliances themselves became the most-exploited entry class — culminating in a nation-state compromise of a major edge vendor that triggered an emergency federal directive forcing agencies to patch-or-disconnect within days. The bitter irony writes the lesson: the box that granted network trust was the attacker’s front door. Every app you migrate off the concentrator shrinks the blast radius of the next appliance CVE.

The migration: one app at a time, by tier

Inventory apps ──► for each: publish behind ZTNA with per-app policy
                   (dispatch app: compliant device + phishing-resistant;
                   cafeteria menu: MFA only)
              ──► move its users; watch; remove the app's subnet from
                   VPN scope
              ──► repeat. The VPN's address space shrinks app by app
                   until what remains is the honest residue.

The honest residue is real, and pretending otherwise breaks things (Lesson 1.3, killer #5): thick-client apps speaking proprietary protocols, server-initiated flows, some VoIP, the vendor system that only speaks IPsec. Those stay on a shrunken, segmented VPN — per-app-group scoped, device-gated, and explicitly inventoried with expiry-dated exceptions — while their replacements get scheduled. “VPN is dead” is vendor poetry; “the VPN grants three legacy subnets to forty named people, reviewed quarterly” is Zero Trust.

For federal readers, the same move has a compliance name: modern TIC 3.0 guidance explicitly blesses SASE architectures — the cloud-delivered bundle of ZTNA + secure web gateway + related controls — as the replacement for the old trusted-internet-connection perimeter stack. Commercial or federal, the architecture is identical; the federal version just comes with a use-case document.

The anti-pattern: trusting the edge’s word for it

One pattern deserves its warning here because real implementations keep shipping it. An organization terminates mutual TLS at its CDN/WAF edge, and the edge forwards the verified client certificate to the origin app in an HTTP header. The app validates the header’s certificate — fingerprint, subject, validity — and feels rigorous. The hole: nothing proves the request came through the edge. If the origin is reachable directly (and it usually is), anyone can send that header themselves with a copy of the — publicly transmitted — certificate, and the whole mTLS ceremony collapses into a bearer token whose value is a public document.

The principle violated is tenet 2 again, wearing service clothes: the app trusted where the request claimed to come from. The fix restores the chain: the origin accepts connections only from the edge (mutual auth on the edge→origin hop, or hard network isolation), so the header is trustworthy because the path is verified. Generalize it: every hop that asserts something on another party’s behalf must itself be authenticated. You’ll apply the same rule to service meshes, reverse proxies, and header-based SSO shims.

💬SASE procurement is not the program

The market wraps ZTNA into SASE/SSE bundles, and the bundles are fine — Meridian will likely buy one. The trap (Lesson 1.3, killer #2): the purchase order that gets renamed “our Zero Trust initiative.” A ZTNA pointed at “all subnets” with an any-any policy is the old VPN with better marketing. The unit of progress is APPS MIGRATED TO PER-APP POLICY — a number you can report quarterly against the scorecard — not appliances replaced.

KNOWLEDGE CHECK

Meridian's network lead proposes finishing the ZTNA migration in one stroke: 'Publish a single ZTNA app entry that fronts the entire 10.20.0.0/16 datacenter range, require MFA + compliant device on it, and decommission the VPN Friday.' What's the verdict?

Key takeaway

Access is granted to applications, never to address space: each app behind its own gate, evaluated with full signals, migrated one at a time while the VPN shrinks to an inventoried, expiring residue. The edge itself is attack surface — both the concentrator you’re retiring and the shortcut of trusting an edge’s forwarded assertions without verifying the path. Next: what contains the things that do share a network.

Search lessons