Security service edge (SSE)

The request, step by step

1. Reach the service edge from anywhere

   A remote laptop forwards its traffic directly, and branch traffic travels over transport the organisation buys and operates separately before it arrives. Both paths end at the same enforcement point, which is what makes one policy possible.

   • Request: Remote worker to Managed laptop, “Opens a site, a SaaS tenant or an application”
   • Request: Managed laptop to Service edge ingress, “Traffic forwarded to the nearest edge”
   • Request: Branch site to Wide-area transport, “Site traffic over transport bought elsewhere”
   • Request: Wide-area transport to Service edge ingress, “Arrives at the security service edge”

   Emphasised at this step: Service edge ingress.

2. Assemble identity and device context

   The service combines the asserted identity and its risk claims with device posture from the local agent and the destination being requested. Traffic arriving from a branch without an agent carries less context, and the policy has to say what that means.

   • Context: Remote worker to Identity provider, “Authentication and a second factor”
   • Context: Identity provider to Policy engine, “Identity, group and risk claims”
   • Context: Managed laptop to Policy engine, “Device posture from the local agent”
   • Request: Service edge ingress to Policy engine, “Request presented for one decision”

   Emphasised at this step: Identity provider.

3. One decision selects the services

   A single policy engine decides the verdict and which of the constituent services the request must pass through. This step is the entire argument for buying the services together, and the one to verify in a trial rather than assume.

   • Request: Policy engine to Secure web gateway, “Web traffic, with the inspection it requires”
   • Request: Policy engine to Cloud access security broker, “SaaS traffic, with the tenant rules that apply”
   • Request: Policy engine to ZTNA broker, “Private application access, scoped to one app”
   • Request: Policy engine to Data loss prevention, “Data rules for this user and destination”

   Emphasised at this step: Policy engine.

4. Each service enforces its own part

   The web gateway inspects internet traffic, data controls inspect the content of an upload before the cloud access security broker passes it to a sanctioned tenant, and the private-access broker exposes one application rather than the network holding it.

   • Request: Secure web gateway to Web destination, “Permitted web traffic, inspected”
   • Request: Data loss prevention to Cloud access security broker, “Inspected upload passed on”
   • Request: Cloud access security broker to SaaS platform, “Permitted traffic to the sanctioned tenant”
   • Request: ZTNA broker to Private application, “Brokered session, no network route”

   Emphasised at this step: Data loss prevention.

5. Collect the evidence in one place

   Verdicts, web inspection, SaaS usage and data-handling decisions reach security operations as one stream. Correlating them on identity and session is what turns four separate tools' worth of events into an account of what happened.

   • Telemetry: Policy engine to Security operations, “Every verdict and the signals behind it”
   • Telemetry: Secure web gateway to Security operations, “Web inspection and isolation events”
   • Telemetry: Cloud access security broker to Security operations, “SaaS usage, including unsanctioned tenants”
   • Telemetry: Data loss prevention to Security operations, “Data-handling decisions and their matches”

   Emphasised at this step: Security operations.

Attempts shown, and where each one stops

• Adversary attempts:

  • Attack: Adversary to Managed laptop, “Link to a credential-harvesting lookalike”
  • Attack: Adversary to ZTNA broker, “Probes for exposed private applications”
  • Attack: Adversary to Wide-area transport, “Attacks the transport the service does not run”
  • Terminated here by Secure web gateway — “Refused: newly registered domain, no category”. The line stops short and takes a bar, not an arrowhead.
  • Terminated here by ZTNA broker — “No application named, so no session exists”. The line stops short and takes a bar, not an arrowhead.

• Actions a control refused, with no adversary involved:

  • Blocked: Managed laptop stopped at Data loss prevention, “Upload of regulated data refused”. The line stops short of its target: the action did not complete.

Annotations

1. The boundary that defines the term

   Boundary “Wide-area transport, bought separately” (managed)

   This zone is the half SSE leaves out. The circuits, their failover and the steering of traffic across them stay with whoever owned them before, and adding the networking half to what sits beside it is what makes the architecture SASE instead.

2. An attempt with nothing stopping it here

   Relationship — Attack: Adversary to Wide-area transport, “Attacks the transport the service does not run”

   This path ends at no control, which is deliberate. Availability attacks, misconfigured routers and circuit failures land on infrastructure the security service neither operates nor observes, and no amount of inspection at the edge changes that.

3. Not every refusal stops an attacker

   Relationship — Blocked: Managed laptop stopped at Data loss prevention, “Upload of regulated data refused”

   The same terminator appears whether the party stopped is an adversary or an employee doing their job. Most data loss prevention decisions are the second kind, which is why the explanation given to the user matters as much as the rule itself.

4. What consolidation is supposed to buy

   Component “Policy engine”

   One engine reaching one verdict over identity, device, destination and data sensitivity is the difference between an SSE service and four products sold together. If each service keeps its own policy model, the gaps between them survive the purchase.

5. Where two of these services overlap

   Component “Cloud access security broker”

   Inline SaaS controls duplicate much of what a web gateway does. The part that does not overlap is the tenant-side view reached through the platform's own interfaces, which sees sharing and configuration no traffic inspection can observe.

6. ZTNA arrives as one service among four

   Component “ZTNA broker”

   The broker inside an SSE bundle is the same mechanism sold on its own, and inherits the same limits, including that its precision depends on how narrowly each application is defined. Buying it as part of a suite does not narrow the definitions for you.

7. The set applied is an outcome

   Boundary “Security services” (managed)

   Which services a request passes through follows from the verdict, so a web request, a SaaS upload and a private application session traverse different paths from the same ingress point. The zone lists what is available, not what every request receives.