What are the key requirements for secure access service edge (SASE)?

Secure access service edge, or SASE, is an industry term for delivering networking and security functions together as a cloud service, so users and offices connect through nearby points of presence instead of a central data center. It is not a formal standard. Judge any offer by the capabilities it actually provides.

What does SASE usually bundle?

Offers differ, but they usually combine a wide area network function (often SD-WAN) with security services: a secure web gateway, a cloud access security broker, firewall as a service and zero trust network access. The word "usually" matters. Some bundles lack one or more parts, and some parts are resold from other providers.

NIST SP 800-207 on zero trust architecture is the neutral reference for the access piece. It describes a policy decision point and policy enforcement point deciding each request, instead of trusting a connection because of where it came from.

What requirements should you write down?

Start from your traffic and users, not the product.

Coverage. Which users, sites, devices and applications must pass through the service? Include contractors, unmanaged devices, branch offices and operational technology if relevant.

Access decisions. Can policy use identity, device state and the specific application, not only network location? This is the NIST 800-207 idea in practical form.

Inspection. What can the service inspect, and what happens to encrypted traffic? Decrypting TLS adds visibility and creates new trust and privacy questions.

Performance. Where are points of presence relative to your people? A service with none near a branch office adds delay.

Resilience. What happens when a point of presence fails? Is there a fallback path, and do you fail open or closed?

Visibility and logging. Can you export logs in usable formats to your own monitoring, and for how long are they kept?

Data handling. Where is traffic decrypted and logged, and under which jurisdiction?

Exit. How hard is it to move policies out? Heavy use of one provider's policy language raises switching cost.

A constructed comparison

A company with 12 branches and 800 remote staff wants to retire a VPN concentrator. Their short list produces a table with three columns: requirement, how it will be tested, and result. For "block access to a file share from an unmanaged laptop", they create a test laptop without management tools and attempt access. One candidate allows it because device posture is only checked at sign in. That finding is worth more than any brochure line.

What should you ask about the contract?

Ask which components the provider runs itself and which it resells. Ask where traffic is decrypted, where logs live and how long they are kept. Ask for uptime commitments per point of presence, not just overall. Check what happens to your policies, logs and configuration if you leave, and get the export format in writing.

Short pilots with a clear exit usually teach more than long evaluations.

How to check or apply this

1. Inventory applications by how users reach them today: web, SSH, internal tools, legacy ports.
2. Write ten policy tests, such as unmanaged device blocked, terminated user blocked, high risk location challenged.
3. Run a pilot with two groups, one office and one remote team.
4. Measure latency before and after for the same tasks.
5. Test a failure: disable the nearest point of presence and see the behavior.
6. Confirm logs reach your SIEM and include user, device, application and decision.
7. Plan migration in stages and keep the old path until the new one is proven.

Quick check

Sources

• NIST SP 800-207, Zero Trust Architecture
• CISA Zero Trust Maturity Model
• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy

Last reviewed: 18 October 2026.