Network security / service edge
SASE secure access service edge
Put users, endpoints, branches and business applications into one access decision. Choose nearby network and security edges by identity, device, application and risk; view paths and policy separately and combine them by scenario rather than assuming one fixed traffic chain.
Separate business paths from the management plane before choosing edge capabilities.
01 Define the access problem first
Put access and security back on one decision chain
When offices, branches, cloud platforms and SaaS applications are distributed, the question is more than whether a network exists: the user, device condition, target application and changing risk can all change how a request is handled.
SASE is an architectural approach that combines network connectivity with cloud-delivered security services. It can place policy and enforcement near users, endpoints or applications without requiring one vendor, one node or one serial path for every capability.
Network access
Identify sites, endpoints, circuits and application locations, then decide which connections need SD-WAN, tunnels, an internet exit or a local path.
Access decision
Evaluate requests using identity, device state, application, location, time and risk, then establish access according to least privilege.
Edge enforcement
Enforce policy at the appropriate service edge or enterprise boundary, leaving reviewable logs, changes and incident records.
02 Business path / management plane
Users reach the edge first; policy decides the next hop
Business traffic reaches private applications, SaaS or Web along a suitable path. The management plane supplies identity, device state, application inventory, risk and logs to policy decisions. They are related but are not the same data path.
The relationship view shows users, endpoints and branches reaching a nearby service edge, then accessing private applications, SaaS or Web by identity, device, application and risk policy. Dashed lines show management inputs; solid lines show business paths.
Compose connectivity and security capabilities as needed
Different paths use different capabilities; not every flow passes through every component in sequence.
03 Security service-edge boundaries
Map the business path before choosing security capabilities
These capabilities may come from one platform or be combined in phases. The key is to match business, protocols, data and ownership rather than buying every acronym.
Secure Web gateway
For Web URLs, domains, malicious content and usage policy. It handles Web paths, not fine-grained authorisation for private applications.
Cloud access security broker
For SaaS visibility, application-use controls and selected API or data-governance scenarios. Capability depends on application interfaces, access method and authorisation scope.
Zero-trust network access
Create request-authorised paths from users or devices to private applications, limiting resources by identity, device state and context without exposing the whole internal network.
Cloud firewall service
For paths that need network-layer, stateful or non-Web protocol control. Confirm policy location, protocol support, addressing and application identification against the live network.
Data loss prevention
Set rules around data classification, content identification and egress channels. Without data classification, exception processes and response ownership, DLP does not become complete governance automatically.
Capabilities are tools on a path
Public Web, SaaS, private applications, branch interconnection and industrial control use different paths. Combine capabilities by risk and business outcome, retaining a pilot boundary that can roll back.
04 SASE / SSE / SD-WAN
Three terms answer three different questions
Do not treat product names as an architecture conclusion. First decide whether the need is site connectivity, cloud security, private-application access or one governance framework combining them.
| Concept | Main question | Typical focus | Does not mean |
|---|---|---|---|
| SD-WAN | How are sites, circuits and wide-area connectivity organised? | Multiple circuits, path selection, site interconnection, circuit state and migration windows | Does not mean complete cloud security or private-application authorisation |
| SSE | How are security policies applied when users and devices access Web, SaaS and private applications? | SWG, CASB, ZTNA, FWaaS, DLP and unified policy | Does not include the complete wide-area connectivity layer |
| SASE | How should network access and security services coordinate around edge, identity and policy? | SD-WAN + SSE, distributed enforcement, unified governance and an operations view | Does not guarantee one vendor, every capability, global acceleration or zero risk |
05 Choose the path by scenario
One policy set applied to different business contexts
Start architecture delivery from current access relationships rather than a product list. The scenarios below are starting points for path selection, not default capability promises.
Branch and campus access
Use SD-WAN to organise multiple circuits and site paths, then steer internet, headquarters, cloud or local services by business. Document the local exit, security checks and fault rollback.
Remote work and private applications
Use ZTNA to narrow access to specific applications, authorising by identity, device state and risk. Do not treat a successful login as trust in every later resource.
SaaS use and data governance
List the SaaS services, accounts, data types and egress scenarios actually in use before assessing CASB, DLP, API or endpoint controls, and define which channels can be observed, blocked or logged only.
Partner and temporary access
Limit third parties by people, devices, time, applications and operations, retaining approval, logs and revocation paths rather than granting access to the whole network.
06 Industrial and critical-business boundaries
OT is not another office-network exit
Industrial control and other critical business have distinct reliability, security and change requirements. Assess assets, data flows, zones and communication directions before deciding whether SASE capabilities belong at the boundary.
- Segment IT and OT, limiting the required systems, protocols, directions and maintenance windows.
- Protect cross-domain connections with firewalls, DMZs or other boundary controls, retaining change and anomaly records.
- Have teams familiar with control systems, security and site continuity assess and exercise the design.
SASE can be part of an overall boundary design, but it does not replace industrial-control security, site security or specialist reliability assessment.
07 Implementation and validation
Map access first, then move policy to the edge in steps
The implementation order should make every change explainable, testable and reversible. Record the control and business planes separately so an issue can be located in identity, endpoint, policy, circuit or application.
- 01
Inventory resources and traffic
List users, endpoints, branches, private applications, SaaS, Web, protocols, data types, existing exits and ownership boundaries.
- 02
Choose capabilities by path
For each access type, choose the necessary combination of SD-WAN, SWG, CASB, ZTNA, FWaaS or DLP and document exclusions and exceptions.
- 03
Small-scope pilot
Choose representative users, devices and applications to validate identity, policy matches, access results, logs, experience and rollback without switching the whole network.
- 04
Handover and ongoing operations
Confirm ownership for policy changes, certificates and connectors, alerts, incident response, configuration backups, access reviews and maintenance windows.
08 Frequently asked questions
Clarify the SASE boundary first
How are SASE, SSE and SD-WAN related?
SASE places connectivity and security services in one service-edge architecture. SD-WAN handles wide-area connectivity, path choice and site interconnection; SSE is the security-services layer and commonly includes SWG, CASB, ZTNA and FWaaS. An organisation with SD-WAN can add SSE first or combine the layers as its network changes.
Does all traffic pass through SWG, CASB, ZTNA, FWaaS and DLP in sequence?
No. Capabilities are selected by business path, protocol, application location, data policy and deployment. Public Web may use SWG, private applications may use ZTNA, and SaaS governance may combine CASB or DLP; branch-to-private-network paths may use SD-WAN and firewall policy. Traffic does not automatically traverse every component in sequence.
Does adopting SASE guarantee global acceleration, zero risk or automatic compliance?
No. Access experience depends on access quality, service-edge location, application and data locations, policy configuration and operations. A named architecture does not remove risk; compliance still requires industry, data, contract and audit checks.
Can an industrial network connect directly to a SASE service edge?
An office-network design cannot be applied directly. OT and industrial-control networks need segmentation, boundary protection and specialist assessment for security, reliability, real-time and change requirements. Necessary IT/OT connections should be limited to named systems, protocols, directions and maintenance windows, not routed into office or cloud-security paths by default.
Yuqi Intelligent implementation and handover
Hand paths, policy and ownership to operations
Yuqi Intelligent reviews existing users, endpoints, sites, circuits, applications and data flows, then supports access mapping, capability selection, pilot configuration, path validation and operations records. Products, licences, connection methods and ownership are confirmed in the project scope.
View implementation scope
- Map access subjects, application locations, circuits, identity sources, device management and security checkpoints.
- Configure edge, policy and logs within the pilot scope, then validate representative business paths and rollback conditions.
- Record changes, alerts, troubleshooting, access reviews, configuration backups and maintenance windows.
View handover records
- Business-path and application-access matrix
- Identity, device, risk and policy rule list
- Edge nodes, connectors, circuits and dependency configuration
- Pilot validation, alert response and follow-up actions
Next step / TECHNICAL DISCUSSION
Start with one real access path
Tell us how users, endpoints, branches, private applications and SaaS relate, and which security boundary is hardest to verify. We will confirm the pilot and handover scope together.