SECURITYATLAS✳

✳ The reference desk / In practice

SSE

Cloud-delivered security services such as secure web access without requiring the networking half of SASE.

Security service edge

What it means

SSE groups cloud-delivered security capabilities for accessing web, cloud, and private applications. Common functions include secure web access, cloud application controls, and zero-trust network access. Unlike the broader SASE category, SSE does not require the wide-area networking component to be part of the same offering. Product boundaries still vary. What matters is which traffic and applications receive which controls, how identities are checked, and what evidence operators can retrieve. An SSE service complements the organization’s network design and application permissions rather than making them unnecessary.

The idea at a glance / Access

A covered browser path does not cover every client.

Keep the selected security functions, covered result and bypassing client visible together.

Fictional Edge182 supplies a selected web gate and inline cloud-upload rule. Maya’s browser uses that path: an allowed document read works and a prohibited upload is refused before reaching the app. A separate native-client exception goes directly to the upload service and stores C182. The private-app connector is absent. Sam’s Q182 restriction is unapplied.

SSE: Keep the selected security functions, covered result and bypassing client visible together. The explanation below describes the relationships.Edge182 · selected SSE coverageConfigured services; different pathsSelected security functionsWeb gate + inline upload rulePrivate-app connector absentCovered browser pathDocument 200 · upload 403Blocked upload never reached appDirect native-client exceptionUpload 201 · C182 read backThis client bypasses Edge182Sam · restriction task Q182Original F182 stays unchangedNative restriction unappliedCOVERED PATH ≠ EVERY CLIENT

READ THE PICTURE

Coverage beside access

The covered browser reads an allowed document and cannot upload externally. The direct native client still stores C182; the bundle name does not close that exception.

Keep in mindThis models selected HTTP proxy/app rules, not a complete SSE service or packet inspection. Client steering, identity and protected channels are explicit assumptions; the direct-client exception is intentionally allowed by this exercise. Private-app, other protocol, content and outage coverage are untested. A service category or installed client does not establish that every path is covered.

Read the complete example
  1. Coverage beside access. The covered browser reads an allowed document and cannot upload externally. The direct native client still stores C182; the bundle name does not close that exception. Edge182’s selected scope is a secure-web access gate plus an inline cloud-upload policy; private-app access has no connector in this exercise. An actual browser-path GET reaches the application and returns F182 with 200. A prohibited browser upload returns 403 before its origin is called, and no corresponding copy exists. A separate native path uses the application’s otherwise valid upload permission directly: 201 stores C182 and independent readback returns its bytes. The application separately refuses an unauthorized document edit with 403. F182 remains unchanged. Sam’s Q182 to restrict native access is applied=false and verified=false. This is a demonstrated selected path gap, not proof that all SSE offerings permit bypass or that other traffic has been inspected.

This models selected HTTP proxy/app rules, not a complete SSE service or packet inspection. Client steering, identity and protected channels are explicit assumptions; the direct-client exception is intentionally allowed by this exercise. Private-app, other protocol, content and outage coverage are untested. A service category or installed client does not establish that every path is covered.

Diagram references: Mplify: SSE security functions and scoped service testing · Microsoft: supported session controls and paths that can bypass them

AN ILLUSTRATIVE SCENARIO

A covered browser and an uncovered native client

Edge182’s browser path permits document reading and refuses an external upload before the app sees it. A direct native-client exception still stores C182; app permissions separately refuse document editing. The private-app connector is absent, F182 remains, and Q182 to restrict the native path is unapplied. The selected security services do not themselves prove coverage of every path.

Put it to work

  1. Identify the users, devices, applications, and traffic in scope. Specify required web controls, private-application access, data handling, and investigation records separately.
  2. Pilot the actual access paths and identity policies. Document how traffic reaches the service, what can bypass it, and which unsupported clients or protocols need another approach.
  3. Agree policy ownership, exception handling, and outage procedures. Test operational effects before enabling disruptive filtering or encrypted-traffic inspection across the whole organization.

How to check your work

Check a permitted workflow, a prohibited workflow, and a known exception from representative devices. Verify policy decisions and usable logs, then confirm how access behaves during a service interruption or identity-provider failure.

Connect the ideas

  • SASE

    A category combining wide-area networking with cloud-delivered security services.

  • ZTNA

    Access that brokers application connectivity per identity and policy instead of placing users on a flat network.

  • CASB

    A control point for observing or constraining use of cloud services, including unsanctioned ones.

  • Authorization

    The decision about whether a person, device, workload, or anonymous requester may perform a particular action on a resource.

Explore a field lesson

Find your next idea.

Tip: press / to open search. Escape closes this window.