Zero trust and SASE: what I'd check before switching

I like the idea behind zero trust. I like it less when the explanation turns into a list of products.

If someone tells me a network is zero trust, I want to understand the access decision. Who is requesting access? From which device? To what resource? What can they do after they connect? What happens when that access should end? Those questions tell me more than the label on the gateway.

Separate the ideas

Zero trust is an approach to access. ZTNA is a way of providing controlled access to applications. SASE bundles networking and security services together, usually delivered from distributed service locations. The exact features and enforcement paths depend on the implementation.

A SASE deployment can support a zero trust design. Buying it doesn't establish that design by itself. If the new platform grants the same broad access as the old one, the authorization problem is still there.

A VPN can also be part of a carefully scoped architecture. What I care about is what being connected lets someone reach.

Start with one application

I'd pick a non-critical application with a known owner and a small set of users. Before migrating it, I'd record the existing path and the intended replacement.

For example: a managed laptop, a specific user group, one internal application, and a defined session policy. Then I'd test an unmanaged device, a removed group membership, an expired session, and an account with no application assignment.

Reaching an application and being authorized inside it are separate decisions, and that's easy to miss. A proxy can control the connection while the application still has broken role checks.

Check the paths that don't fit the demo

Browser applications tend to make neat demos. Real environments also have service accounts, non-browser clients, long-running sessions, vendor access, and software that makes assumptions about DNS or source addresses.

I'd ask how each of those works before moving it. I'd also test what happens when a connector is down, a device falls out of compliance, or the identity provider is unavailable.

TLS inspection deserves its own review. It changes where encrypted traffic is decrypted and who operates that boundary. Certificate-pinned applications, privacy requirements, and operational exceptions all need explicit decisions. I wouldn't turn it on everywhere just to finish a checklist.

Measure the result

For me, success would mean fewer unnecessary routes, access that matches actual roles, revocation that behaves as expected, and logs that explain the decision. I'd also compare connection failures and application latency before and after the change.

I wouldn't promise that latency always improves. The traffic path, inspection, connector placement, and application location all matter.

The NIST zero trust publication is a useful starting point because it describes principles without requiring a particular vendor. My takeaway is to make the access policy explicit, then check whether the technology enforces it.