Zero Trust, VPN and TLS Inspection Do Different Jobs

Procurement documents use zero trust, VPN and TLS inspection as if they were the same purchase, and each one answers a question the others cannot. A tunnel builds a protected path, an inspection gateway reads traffic it is able to terminate, and a policy decides whether a named identity may perform a named operation on a named resource. Only the last of those is an authorization decision. A product can do the first two perfectly and still leave the real question open.

Three Mechanisms, Three Questions

The tunnel answers how traffic reaches the network. An inspection gateway answers what a middlebox can see and act on where it is authorized to terminate TLS. A policy engine answers who may do what to which resource, and then it needs an enforcement point able to apply that answer. NIST's zero-trust architecture puts the resource at the centre and refuses to infer trust from where a packet came from.

That framing is harder to satisfy than a label, and much harder to fake in a review. It also moves the question away from which products are deployed, towards which decisions are enforced and by what.

Where the Decision Is Actually Applied

Take one request: a support engineer opens a service console, and a personal machine plugged into the same switch must not inherit that permission just by being nearby. Write down the allowed operation, the device conditions and the component that enforces them. Placement decides everything: an application gateway, a service proxy, a host control, or another boundary the organization actually supports. Whatever that component turns out to be, it has to sit in the path of both remote and on-site attempts.

Traffic that never crosses the VPN ingress is not governed by a check performed there, however thorough that check is. That single gap explains most of the distance between a zero-trust diagram and a working deployment. Draw the request path before you draw the architecture.

Decryption Is Not Authorization

Interception serves narrow inspection goals and carries its own burden of certificates, trusted roots, privacy review and applications that break under it. None of that is what zero trust means, and none of it substitutes for a policy decision. Authenticating a person and authorizing a service is entirely possible without decrypting a single packet. A decrypted flow says nothing about whether the user was entitled to the operation carried inside it.

The policy needs one kind of evidence, and decryption is not it. Device health is one input among identity, resource sensitivity and context, and passing it once does not hand that machine the rest of the network. Mixing the two turns an authorization question into a certificate project.

Where the Gateway Is Nowhere in the Path

Inventory what travels without touching the remote gateway: links between machines on the local segment, calls from one workload to another, and endpoints reached directly inside a cloud account. For each path, name an enforcement method that can actually be deployed today. Equipment that cannot host an agent still needs some other explicitly supported control, and assuming the agent will arrive later closes nothing now. Service-to-service access usually suits workload identity and a check written against the resource better than another overlay network.

Accept the design on behaviour rather than on diagrams: which operations are allowed, which are denied, and where each answer is enforced. Sign off on specific allowed and denied operations, and include one local route that never reaches the gateway. Record who owns the policy, how it changes and how revocation works.

A relabelled tunnel is still a tunnel. A policy decides, and something has to enforce it.