SASE compared with SSE

The request, step by step

1. Reach the service edge from both directions

   A remote user tunnels out from a managed laptop, and a branch site reaches the same edge through a device that chooses a path per application. Only the first of those two paths is in scope for an SSE purchase.

   • Request: Remote worker to Managed laptop, “Opens an application on the laptop”
   • Request: Managed laptop to Service edge gateway, “Agent tunnel to the nearest edge”
   • Request: Branch site to Branch edge device, “Site traffic reaches the branch edge”
   • Request: Branch edge device to Service edge gateway, “Overlay, steered per application”

   Emphasised at this step: Service edge gateway.

2. Assemble the context for one decision

   The service combines the asserted identity with device posture, the requested application and the destination. Both categories do this the same way, from the same signals.

   • Context: Remote worker to Identity provider, “Sign-on and a second factor”
   • Context: Identity provider to Policy engine, “Identity, group and risk claims”
   • Context: Managed laptop to Policy engine, “Device posture at the time of the request”
   • Request: Service edge gateway to Policy engine, “Request presented for a decision”

   Emphasised at this step: Policy engine.

3. Decide once, then enforce

   One engine decides whether to allow, challenge, isolate or block, and names the services the traffic must pass. The chain is identical in both categories, which is why the delta is not a security feature.

   • Request: Policy engine to Security service chain, “Verdict and the controls it requires”

   Emphasised at this step: Security service chain.

4. Route permitted traffic to its destination

   Allowed traffic continues to the internet, a sanctioned SaaS platform or a private application, which then reads its own records. The private session is brokered, so no route to the wider network is created.

   • Request: Security service chain to Web destination, “Permitted web traffic, inspected”
   • Request: Security service chain to SaaS platform, “Permitted SaaS traffic”
   • Request: Security service chain to Private application, “Brokered session, no network route”
   • Request: Private application to Application records, “Application reads its own records”

   Emphasised at this step: Private application.

5. Steer the network and observe both planes

   Circuit measurements drive path policy at each site, while admission, verdict and inspection events reach security operations. With the networking half absent, the path data comes from a different supplier and has to be correlated by hand.

   • Context: Wide-area orchestrator to Branch edge device, “Path policy for each application class”
   • Telemetry: Branch edge device to Wide-area orchestrator, “Loss, latency and jitter per circuit”
   • Telemetry: Service edge gateway to Security operations, “Session and admission events”
   • Telemetry: Policy engine to Security operations, “Every verdict and the signals behind it”
   • Telemetry: Security service chain to Security operations, “Inspection and data-handling events”

   Emphasised at this step: Security operations.

Attempts shown, and where each one stops

• Adversary attempts:

  • Attack: Adversary to Service edge gateway, “Stolen credential replayed at the edge”
  • Attack: Adversary to Branch edge device, “Probe against the branch internet circuit”
  • Terminated here by Security service chain — “Refused: unknown device, no posture signal”. The line stops short and takes a bar, not an arrowhead.
  • Terminated here by Security service chain — “Refused where branch breakout is steered inward”. The line stops short and takes a bar, not an arrowhead.

Annotations

1. This line is the whole difference

   Relationship — Request: Branch edge device to Service edge gateway, “Overlay, steered per application”

   An SSE purchase does not include it. Something still has to carry site traffic to the enforcement point, and whatever that is remains your design, your contract and your failure domain. The security services on the far side are the same either way.

2. What an SSE purchase leaves unsolved

   Boundary “Branch site network” (managed)

   Circuits, routers, path selection and local internet breakout stay where they are. That is often the correct choice, but it should be a decision with an owner rather than a gap discovered after the security service is live.

3. A local circuit is an uninspected path

   Relationship — Attack: Adversary to Branch edge device, “Probe against the branch internet circuit”

   Traffic leaving a site directly reaches the internet without meeting the service chain at all. The networking half exists partly to pull that traffic inward so the same policy applies to it, rather than relying on a separate device at every site to be configured consistently.

4. The service chain is not the differentiator

   Component “Security service chain”

   Brokered private access, web inspection, cloud application controls, firewalling and data-loss prevention appear in both categories. Judging two shortlists by counting these services compares them on the axis where they agree.

5. One decision is the point of both

   Component “Policy engine”

   Identity, device posture, application, destination and current risk reaching one engine is what makes a verdict reviewable. Several tools each reaching their own verdict is the state both categories were defined to replace.

6. Convergence is a claim to test, not a label to read

   Boundary “Cloud service edge” (managed)

   Two products behind one invoice can still hold two policy models, two consoles and two identity integrations. Ask which single object holds the policy, whether one change updates both halves, and whether the events from each half share identifiers and clocks.