SECURITYATLAS✳

✳ The reference desk / In practice

SASE

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

Secure access service edge

What it means

SASE combines wide-area networking with security services commonly delivered through a distributed cloud edge. The networking portion helps connect users, branches, and applications; the security portion applies controls such as web filtering or access policy. Actual offerings vary in architecture, integration, and supported traffic. The useful question is how a specific design carries and protects your organization’s traffic. SASE does not remove application authorization, endpoint security, or the need to understand dependency and outage behavior. It also does not imply that every traffic path automatically passes through the controls.

The idea at a glance / Access

Failover must preserve security and app permissions.

Keep path selection, security enforcement and the application’s own decision together.

Fictional Branch183 uses a selected networking-plus-security design. A controlled Path A endpoint returns 503, so the modeled router selects Path B for the same flow through Edge183. Maya can read her department’s O183, while the edge refuses a prohibited destination and the app refuses another department’s record. Sam’s Q183 for wider failover testing remains open.

SASE: Keep path selection, security enforcement and the application’s own decision together. The explanation below describes the relationships.Branch183 · selected SASE designPath, security and app permissionBranch · selected routePath A probe → 503Path B carried the selected flowEdge183 · same security policyProhibited destination → 403Allowed app path stays availableApp · Maya’s department scopeOwn O183 200 · other O184 403Original O183 remainsSam · wider testing Q183Selected requests tested onlyWider failover coverage openNEW PATH · SAME PERMISSION RULES

READ THE PICTURE

Route beside enforcement

Path B carries the selected request after Path A’s controlled failure. Edge policy still refuses the prohibited destination; the app allows Maya’s own record and refuses the other department.

Keep in mindThis is local HTTP/SQL path selection, not real SD-WAN, WAN availability or a SASE certification. A 503 fixture is an endpoint failure, not proof of a broken physical link. Identity, protected channels and trustworthy route configuration are assumed. Only these paths and requests are tested; latency, session continuity, identity outages and remote-client behavior remain unassessed.

Read the complete example
  1. Route beside enforcement. Path B carries the selected request after Path A’s controlled failure. Edge policy still refuses the prohibited destination; the app allows Maya’s own record and refuses the other department. The modeled Branch183 router actually probes Path A and observes HTTP 503, then chooses Path B, which forwards the selected requests through the same Edge183 rules. An allowed application request returns Maya’s O183 with 200. A prohibited destination gets 403 at the edge without reaching its origin. A request for O184 reaches the app but its department rule returns 403. The two refusals have different owners. O183 stays unchanged, and Sam’s Q183 for broader failover coverage is unperformed. A separate both-paths-unavailable control yields 503 without calling the app. This demonstrates only the exercise’s specified path/security/app behavior, not physical WAN failure, full continuity, performance or all SASE attributes.

This is local HTTP/SQL path selection, not real SD-WAN, WAN availability or a SASE certification. A 503 fixture is an endpoint failure, not proof of a broken physical link. Identity, protected channels and trustworthy route configuration are assumed. Only these paths and requests are tested; latency, session continuity, identity outages and remote-client behavior remain unassessed.

Diagram references: Mplify: agreed SASE security and connectivity attributes · NIST SP 800-215: cloud controls, ZTNA and combined networking/security

AN ILLUSTRATIVE SCENARIO

A backup path with separate access decisions

Branch183 switches from a controlled 503 endpoint to Path B while retaining Edge183 policy. Vera’s own record returns 200, a prohibited destination gets an edge refusal, and another department’s record gets an app refusal. O183 stays unchanged and broader Q183 testing remains open. The local model tests no physical WAN or performance guarantee.

Put it to work

  1. Map users, locations, applications, and traffic types. Define access, performance, resilience, and logging requirements before comparing product bundles or deployment models.
  2. Pilot identity integration, traffic steering, and policy enforcement on representative devices and sites. Document bypasses, unsupported protocols, and application-specific access controls that remain necessary.
  3. Test failover and outage behavior with network and security owners. Agree how policy changes, troubleshooting, certificates, and incident evidence will be managed across the service.

How to check your work

Trace an approved user’s path to an application from a branch and a remote connection. Confirm expected policy and logs, then test a disallowed action and a controlled failure scenario. Compare actual behavior with the documented design.

Connect the ideas

  • SSE

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

  • ZTNA

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

  • Trust boundary

    A place where identity, network, or data assumptions change and a fresh check is required.

  • Availability

    The property that authorized people can use a system or record when they need it.

Explore a field lesson

Find your next idea.

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