# SSE / SASE single-pass architecture explainer

> Describe a request \u2014 where it is going, how it is steered, whether the device is managed, whether TLS is decrypted \u2014 and see the single pass: which SSE services engage, which are pillars and which are cross-cutting, and what a chain of separate appliances would have done instead. Deterministic and offline.

- Tool: https://ronutz.com/en/tools/sse-architecture-explainer
- Family: Security & WAF

---

## What it does

Describe a request — where it is going, how it is steered, whether the device is managed, whether TLS is decrypted, whether it carries a payload — and the tool shows the single pass: which services engage, in what order, which are **pillars** and which are **cross-cutting**, and what a chain of separate appliances would have done instead. Deterministic and offline; it describes an architecture rather than querying one.

## The point it exists to make

**DLP and threat protection are not pillars.** They are cross-cutting: they run inside the same pass and receive whatever the pillars decrypted. That is why one data profile covers web, software-as-a-service and private applications alike, and why the same rule in a chained architecture has to be written four times in four dialects.

The pillars are about **where traffic is going** — secure web gateway for the general web, cloud access security broker for SaaS activity, zero trust network access for a private application, cloud firewall for the ports the others do not cover. Change the destination in the tool and watch which pillars engage while the cross-cutting engines stay constant.

## The claim you can check

Single-pass means **the payload is decrypted once** and the same stream is handed to every engine. Chained appliances decrypt and re-encrypt at each hop, and that repetition is most of the latency people blame on inspection.

The tool states this as the contrast on every result, because "converged" is often a bundling claim rather than an architectural one. The question worth asking a vendor is whether the payload is decrypted once, or once per engine.

## What it will not do

It does not model any specific tenant, and it is not a policy simulator. Turn decryption off and it will tell you that everything below application identification is working from metadata — which is the failure mode it most wants a learner to internalise, because a policy written as though content were visible will sit in the console looking correct.

## Vendor scope

The stage names follow Netskope's published description of its Zero Trust Engine, since that is the platform this site's training covers. The structural argument — single pass, cross-cutting inspection, full compute at the edge — is general to SSE and is presented as such.

## Standards and references

- [Netskope - Zero Trust Engine](https://www.netskope.com/netskope-one/zero-trust-engine)
- [Netskope One Security Service Edge](https://www.netskope.com/products/security-service-edge)
- [Netskope One platform](https://www.netskope.com/netskope-one)

## Related reading

- [Choosing how traffic reaches the service edge](https://ronutz.com/en/learn/netskope-steering-methods.md): Client, IPsec, GRE, explicit proxy or proxy chaining. Each one changes what the edge can know, not just how packets arrive — and the client disables itself when it finds a tunnel.
- [What single-pass actually means](https://ronutz.com/en/learn/sse-single-pass-architecture.md): Every SSE vendor says converged. This is what it means mechanically: one decryption instead of four, pillars versus cross-cutting engines, and why DLP is not a pillar.