Cisco Secure Access Architecture and Core Components
Learning Objectives
Diagram the high-level architecture of Cisco Secure Access and its data path, describing the three planes (management/control, data/enforcement, and connectivity/edge) and how a packet moves from a user to an application.
Identify the core security services bundled in the platform — Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), DNS-layer security, and Cloud-delivered firewall (FWaaS) — and explain what each one inspects.
Explain how traffic is steered to the cloud edge — from roaming endpoints via the Cisco Secure Client, from branches via IPsec network tunnels, and from private applications via Resource Connectors.
Pre-Reading Check — The Unified Cloud Platform
1. Cisco Secure Access is architecturally organized into three cooperating planes. Which plane is responsible for actually inspecting and enforcing on live traffic?
2. What is the primary design goal achieved by placing security controls in distributed cloud Points of Presence (PoPs) close to users?
3. An administrator writes a single DLP rule: "Block outbound transfers of documents containing customer Social Security numbers." Why does this rule apply consistently across web uploads, Microsoft 365 sharing, and internal-app access?
4. According to Cisco, what is the main risk of a "fragmented SSE" built from separate point products (SWG from one vendor, CASB from another, ZTNA from a third)?
5. Which set of components correctly belongs to the management / control plane?
1. The Unified Cloud Platform
Cisco Secure Access is a cloud-native Security Service Edge (SSE) platform grounded in zero trust. It unifies DNS-layer security, Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), Firewall-as-a-Service (FWaaS), and Zero Trust Network Access (ZTNA) behind a single policy engine, a single client, and a single management console — delivering all of these controls from distributed cloud points of presence to users and sites anywhere.
Think of the platform as a modern airport built for security screening: instead of every traveler driving back to one central checkpoint in a distant city (the old "backhaul to headquarters" model), Cisco builds identical, fully-staffed checkpoints in every major metro area. Those metro checkpoints are the Points of Presence, the screening lanes are the security services, and the rulebook is the unified policy engine.
Key Points
Three cooperating planes. A control plane (console + policy engine + identity/posture), a data plane (distributed PoPs running every engine), and a connectivity plane (the on-ramps that steer traffic in).
Single management console. One browser-based front door configures security, access, and data policies and monitors every service, eliminating the "swivel-chair" problem of correlating across four dashboards.
Points of Presence run the full stack. Every PoP runs DNS, SWG, CASB, FWaaS, and ZTNA engines side by side; proximity to users avoids backhaul and often lowers latency versus legacy VPN.
Unified policy engine. One cloud-native engine evaluates who the user is, which device, where, and which app — so a rule authored once applies across every service.
Regional resilience. Because every PoP is identical, deploying multiple tunnels/connectors per region lets traffic shift if one PoP or path degrades.
The three planes
Plane
What it does
Key components
Management / Control Plane
Defines and evaluates policy; where admins configure everything
Cloud-native policy engine, single management console, IdP and EDR/MDM integrations
Figure 2.1: The three cooperating planes of Cisco Secure Access
flowchart LR
subgraph Control["Management / Control Plane"]
Console["Single Management Console"]
Policy["Unified Policy Engine"]
IdP["IdP + EDR / MDM Integrations"]
end
subgraph Data["Data / Enforcement Plane"]
PoP["Distributed Cloud PoPs DNS · SWG · CASB · FWaaS · ZTNA"]
end
subgraph Connectivity["Connectivity / Edge Plane"]
Client["Cisco Secure Client"]
Browser["Clientless Browser Access"]
Tunnel["Site-to-Cloud IPsec Tunnels"]
RC["Resource Connectors"]
end
Console --> Policy
IdP --> Policy
Policy -->|"Defines & evaluates rules"| PoP
Client --> PoP
Browser --> PoP
Tunnel --> PoP
RC --> PoP
PoP -->|"Forwards to app"| App["Applications / Internet / SaaS"]
Animation 1 — The three planes light up in sequence
Control plane defines policy → enforcement plane inspects at the PoP → connectivity plane steers traffic in.
Key Takeaway: Cisco Secure Access is one cloud-native SSE platform organized into three planes — a control plane (single console + unified policy engine + identity/posture integration), a data plane (distributed PoPs running every security engine), and a connectivity plane. A single console and single policy engine mean you write a rule once and it applies everywhere, eliminating the gaps and complexity of stitching together separate point products.
Post-Reading Check — The Unified Cloud Platform
1. Cisco Secure Access is architecturally organized into three cooperating planes. Which plane is responsible for actually inspecting and enforcing on live traffic?
2. What is the primary design goal achieved by placing security controls in distributed cloud Points of Presence (PoPs) close to users?
3. An administrator writes a single DLP rule: "Block outbound transfers of documents containing customer Social Security numbers." Why does this rule apply consistently across web uploads, Microsoft 365 sharing, and internal-app access?
4. According to Cisco, what is the main risk of a "fragmented SSE" built from separate point products (SWG from one vendor, CASB from another, ZTNA from a third)?
5. Which set of components correctly belongs to the management / control plane?
Pre-Reading Check — Core Security Services
1. Which core service inspects DNS resolution and can block malware, phishing, and command-and-control callbacks over any port simply by refusing to resolve malicious domains?
2. A plain URL filter cannot distinguish a sanctioned corporate Dropbox tenant from a random personal file-sharing account. Which service can tell them apart and enforce different policies?
3. Which service is described as covering the "non-web, generic-IP traffic beneath" SWG and CASB — the arbitrary ports and protocols that the web-focused engines do not handle?
4. CASB operates in two complementary modes. What does the API-based (out-of-band) mode add that inline CASB cannot do on its own?
5. In the worked example of a user browsing the internet, what is the correct order in which the services act on the connection?
2. Core Security Services
The enforcement plane bundles four core internet-and-SaaS security services — DNS-layer security, SWG, CASB, and FWaaS — plus ZTNA for private apps (covered in the next section). Rather than four unrelated products, think of them as stacked, complementary layers of a screening line: each inspects a different aspect of the same traffic, and each hands context to the next.
Service
Inspects
Primary layer
How it is delivered
DNS-layer security (DNS Defense)
DNS queries (domain resolution)
First-line, any port
DNS queries steered to Cisco cloud resolvers
SWG
HTTP/HTTPS web traffic
Web / application content
Client tunnel, PAC/proxy, or site tunnel to PoP
CASB
SaaS application usage and data
SaaS governance
Inline (via SWG) + out-of-band API integration
FWaaS
Generic IP / non-web traffic (L3/L4 + NGFW)
Network
IPsec/route-based tunnels from sites to PoP
Key Points
DNS-layer security is the fast bouncer at the door. A lightweight, any-port allow/block/redirect decision on the domain — usually the first service an organization turns on.
SWG is the deep-inspection engine. It opens the content of HTTP/HTTPS sessions for URL filtering, malware scanning, SSL decryption, and DLP; high-risk pages can be pushed through Remote Browser Isolation.
CASB is SaaS-aware. Inline through the SWG plus out-of-band API scanning of data at rest — it distinguishes a sanctioned corporate app instance from a personal one.
FWaaS covers everything underneath. L3/L4 and NGFW controls for non-web, generic-IP traffic, delivered from the cloud with no physical appliance per site.
One pass, one policy engine. All four run in every PoP and consult the same policy engine, so a single connection can be screened by every layer in one path.
How the four services chain together (user browsing the internet)
DNS request. The device sends its DNS query to Cisco's cloud resolvers; a known-malicious domain is blocked or redirected right here.
Web connection. For an allowed domain, the browser connects via the SWG (through the client tunnel or a proxy), routed to the nearest PoP.
SWG inspection. The SWG applies URL category rules, malware filtering, SSL decryption (if policy allows), and DLP — with identity and posture from the shared engine influencing the decision.
FWaaS and network controls. If the traffic originated from a branch, it reached the PoP through a FWaaS tunnel, and FWaaS enforces any L3/L4 rules in parallel.
Figure 2.2: The four core services as a stacked screening line
flowchart LR
User["User Device"]
subgraph PoP["Nearest Cloud PoP"]
direction TB
DNS["1. DNS-layer Security Domain reputation · allow / block / redirect"]
SWG["3. SWG URL filtering · malware · SSL decrypt · DLP"]
CASB["CASB SaaS-aware policy (inline via SWG)"]
FWaaS["4. FWaaS L3 / L4 · NGFW for non-web traffic"]
end
Engine["Shared Policy Engine identity · device · location · app"]
User -->|"DNS query"| DNS
DNS -->|"Allowed domain"| SWG
SWG --> CASB
User -->|"2. Web connection"| SWG
User -->|"Generic IP / branch tunnel"| FWaaS
Engine -.->|"Consulted by every layer"| PoP
SWG --> Internet["Internet / SaaS"]
FWaaS --> Internet
Animation 2 — One packet screened through the stacked layers
A request passes DNS → SWG → CASB → FWaaS inside a single PoP, then out to the internet/SaaS.
Key Takeaway: The four core services are stacked, complementary layers, not competitors. DNS-layer security makes fast domain decisions first (the bouncer at the door); SWG deep-inspects web content; CASB adds SaaS-awareness and data control on top of SWG plus out-of-band API scanning; and FWaaS covers the non-web, generic-IP traffic underneath. All four run in every PoP and share one policy engine, so a single connection can be screened by every layer in one pass.
Post-Reading Check — Core Security Services
1. Which core service inspects DNS resolution and can block malware, phishing, and command-and-control callbacks over any port simply by refusing to resolve malicious domains?
2. A plain URL filter cannot distinguish a sanctioned corporate Dropbox tenant from a random personal file-sharing account. Which service can tell them apart and enforce different policies?
3. Which service is described as covering the "non-web, generic-IP traffic beneath" SWG and CASB — the arbitrary ports and protocols that the web-focused engines do not handle?
4. CASB operates in two complementary modes. What does the API-based (out-of-band) mode add that inline CASB cannot do on its own?
5. In the worked example of a user browsing the internet, what is the correct order in which the services act on the connection?
Pre-Reading Check — Traffic Steering and Connectivity
1. Which on-ramp is designed for roaming/remote users on laptops, using Tunnel Mode and Split DNS settings to decide per-packet whether traffic goes to Secure Access?
2. What is the defining trait of a Resource Connector that lets it reach a private app with no inbound firewall ports or public IPs?
3. In the Cisco Secure Client per-packet steering decision, what happens when a packet's destination matches an exclude / bypass rule?
4. Two properties of a branch IPsec network tunnel are worth memorizing. Which pair is correct?
5. How do Resource Connectors represent a philosophical shift from legacy Umbrella cloud tunnels?
3. Traffic Steering and Connectivity
None of the enforcement engines can help unless traffic actually reaches a PoP. Traffic steering is the discipline of deciding which flows are sent to Secure Access and which stay local. Cisco offers three primary on-ramps — one for roaming users, one for branches, and one for private applications — and all three make their decisions based on policy: destination IP/prefix, domain name, application, or proxy/PAC rules.
On-ramp
Best for
Transport
Steering decision
Cisco Secure Client
Roaming/remote users, laptops
IPsec user/machine tunnels; proxy/PAC for web
Tunnel Mode (full vs split) + DNS Mode (Split DNS)
Network tunnel (IPsec)
Branch offices, whole sites
IPsec (~1 Gbps/tunnel, all ports/protocols)
Route-based: which prefixes point at the tunnel
Resource Connector
Private/internal applications
Outbound-only DTLS/QUIC over 443
Application-centric: per-app Private Resources
Key Points
Cisco Secure Client (roaming). Builds user and always-on machine tunnels; Tunnel Mode (full vs split) and Split DNS decide per-packet what goes to Secure Access. A synthetic range (e.g., 6.6.0.0/16) elegantly links DNS resolution to tunnel selection.
Per-packet rule matching. An include rule places the packet into the Secure Access tunnel; an exclude/bypass rule sends it direct to the internet or a legacy VPN — the basis of VPN coexistence designs.
Network tunnels (branch). IPsec from a router/firewall/SD-WAN edge; accepts all ports and protocols, ~1 Gbps each, steered by routing. GRE is normally not required to reach a PoP.
Resource Connectors (private apps). A call-home VM with outbound-only tunnels — MQTT/TLS control channel plus DTLS/QUIC data channel over 443, no inbound ports. Grouped into Resource Connector Groups for redundancy and segmentation.
Application-centric, identity-aware. Unlike legacy network-centric tunnels, connectors publish specific apps and enforce per-user/per-device policy before traffic reaches the connector — preventing lateral movement by design.
Cisco Secure Client per-packet steering
The steering decision on the endpoint is a rule-matching process. A packet destined for an internal RDP host (a TCP SYN to 10.101.5.20) is evaluated against traffic steering rules: an include match (e.g., 10.101.0.0/16 or a synthetic range like 6.6.0.0/16) places it in the tunnel; an exclude/bypass match sends it direct or to a legacy VPN. There is an elegant interplay between the two knobs: when Split DNS resolves a private-app FQDN to an address in the synthetic range — which is also in the Tunnel Mode exception list — the traffic is automatically steered into the tunnel the instant resolution completes.
flowchart TD
Start["Device generates packet (e.g. TCP SYN to 10.101.5.20)"]
Eval{"Match traffic steering rules?"}
Include["Include rule matched (e.g. 10.101.0.0/16 or 6.6.0.0/16)"]
Exclude["Exclude / bypass rule matched"]
Tunnel["Place packet into Secure Access tunnel"]
Local["Send direct to internet or legacy VPN (e.g. Cisco ASA)"]
PoP["PoP: identity · policy · posture checks"]
App["Forward to real application"]
Start --> Eval
Eval -->|"Include"| Include
Eval -->|"Exclude / bypass"| Exclude
Include --> Tunnel
Exclude --> Local
Tunnel --> PoP
PoP --> App
Resource Connectors and the three-leg ZTNA path
Reaching a private application flips the direction: the cloud must reach inward to an app with no public exposure. A Resource Connector is a customer-deployed VM (VMware/Azure/AWS) that builds outbound-only tunnels to the PoPs — an MQTT-over-TLS control channel and a DTLS/QUIC data channel, both over port 443. The end-to-end ZTNA path has three legs: (1) Client → Zero Trust Proxy at the PoP via MASQUE over QUIC (HTTP/3), (2) PoP → a healthy Resource Connector selected from the appropriate group, and (3) Connector → the private application. Connectors are organized into Resource Connector Groups for redundancy, load distribution, and segmentation.
Figure 2.4: The three-leg ZTNA private-application path
sequenceDiagram
participant C as Cisco Secure Client (ZTNA module)
participant P as Zero Trust Proxy (PoP)
participant R as Resource Connector (in customer environment)
participant A as Private Application
Note over C,P: Leg 1 — Client to PoP
C->>P: App request mapped to ephemeral IP (100.64.0.0/10) MASQUE over QUIC (HTTP/3)
Note over P: Enforce per-user, per-device policy
Note over P,R: Leg 2 — PoP to Connector
P->>R: Select healthy connector from Resource Connector Group via established outbound tunnel
Note over R,A: Leg 3 — Connector to App
R->>A: Resolve FQDN / IP and forward into internal network
A-->>R: Return traffic
R-->>P: Retrace path
P-->>C: Response to client
Animation 3 — The three-leg ZTNA private-app path
Client → Zero Trust Proxy (policy) → Resource Connector (outbound-only) → Private App. Watch the packet traverse all three legs.
Key Takeaway: Three on-ramps steer traffic to the cloud edge. Roaming laptops use the Cisco Secure Client, whose Tunnel Mode and Split DNS settings decide per-packet whether to send traffic to Secure Access. Branches use ~1 Gbps IPsec network tunnels that carry all ports/protocols and are steered by routing. Private apps are reached via outbound-only Resource Connectors (MQTT/TLS control + DTLS/QUIC data over 443, no inbound ports) organized into groups for resiliency — an application-centric, identity-aware model that replaces network-centric legacy tunnels.
Post-Reading Check — Traffic Steering and Connectivity
1. Which on-ramp is designed for roaming/remote users on laptops, using Tunnel Mode and Split DNS settings to decide per-packet whether traffic goes to Secure Access?
2. What is the defining trait of a Resource Connector that lets it reach a private app with no inbound firewall ports or public IPs?
3. In the Cisco Secure Client per-packet steering decision, what happens when a packet's destination matches an exclude / bypass rule?
4. Two properties of a branch IPsec network tunnel are worth memorizing. Which pair is correct?
5. How do Resource Connectors represent a philosophical shift from legacy Umbrella cloud tunnels?