Netskope Architecture & Traffic Steering: — Client, NewEdge & SSL Inspection

① How traffic actually reaches Netskope

In Lesson 1 we said Netskope is the cloud checkpoint between your people and every app. This lesson answers the obvious next question: how does the traffic physically get there? Because a checkpoint only works if cars are routed through it. In Netskope, that routing is called steering.

The most common on-ramp is the Netskope Client — a small agent on the laptop. When it starts, it builds an encrypted tunnel to the nearest Netskope data centre: TLS over TCP/443 or DTLS over UDP/443. Your web and app traffic rides inside that tunnel to a POP, gets inspected, and egresses to the internet wearing a Netskope public IP — not your home IP.

That global network of full-compute data centres is NewEdge. As of 2026 it spans 120+ data centres across 80+ regions, with data-sovereignty controls in two dozen countries and a NewEdge AI Fast Path for agentic-AI workloads. For an L1, the practical point is simpler: there is almost certainly a POP near your users, so steering to it adds little delay.

Four words for the plumbing

Tap each card — these are the moving parts of steering.

C:\> "C:\Program Files (x86)\Netskope\STAgent\nsdiag.exe" -f

Orgname          : wipro
Steering Config  : BLR-HQ-Managed-Laptops
Client status    : enable
Tunnel status    : NSTUNNEL_CONNECTED
Gateway          : gateway-bom1.goskope.com
Gateway IP       : 163.116.144.50
Tunnel Protocol  : DTLS
Traffic Mode     : All Traffic
Dynamic Steering : enabled

Client status: enable plus Tunnel status: NSTUNNEL_CONNECTED to a nearby Gateway (here gateway-bom1 = Mumbai) means traffic is actually steered. Read the Steering Config and Traffic Mode lines together — they tell you WHICH configuration and how much traffic it captures. If Tunnel status shows anything other than NSTUNNEL_CONNECTED, or Traffic Mode is None, the Client builds no useful tunnel and inspects nothing — even when Client status says enable.

② Steering methods and modes — Client, tunnels and proxies

The Client is not the only on-ramp. You pick the steering method based on the device, and the steering mode based on how much traffic you want captured. Methods and modes are independent dials — set both.

The five steering methods

Netskope Client — best for managed laptops; per-user, follows the device anywhere. IPsec and GRE tunnels — from a branch router/firewall, they steer a whole site’s traffic without touching endpoints (great for kiosks, OT, unmanaged desktops); you build them under Settings → Security Cloud Platform → IPSec (or GRE), picking a primary and backup POP per source peer. Explicit Proxy — a PAC file points browsers at Netskope; no client, no tunnel. Reverse Proxy — the clientless path: a SAML redirect (configured under Settings → Security Cloud Platform → Reverse Proxy → SAML → Add Account) steers unmanaged/BYOD devices to sanctioned SaaS only.

The three traffic modes

Inside a Steering Configuration you choose one mode: Cloud Apps Only (just sanctioned SaaS), Web Traffic (all HTTP/S on 80/443), or All Traffic (web plus non-web ports — SSH, SMTP, custom TCP/UDP). All Traffic needs the Cloud Firewall licence, because inspecting non-web ports is firewall work, not web-proxy work. There is also a None setting, where the Client establishes no tunnel at all.

New for steering: Dynamic Steering. Tick Enable Dynamic Steering and you get separate On-Premises and Off-Premises dropdowns (each can be Cloud Apps Only / Web Traffic / All Traffic / None). An On-Premises Detection Profile (Egress IP, DNS or HTTP check) tells the Client which mode to use, and it re-checks every 3–5 minutes.

③ SSL/TLS decryption — why Netskope must open the envelope

Steering gets traffic to the POP. But almost all of that traffic is HTTPS — encrypted end to end. You cannot scan for malware, block an upload, or run DLP on bytes you cannot read. So Netskope performs SSL/TLS decryption: a controlled man-in-the-middle during the TLS handshake.

Mechanically, the POP runs two TLS sessions. Session one is between the endpoint and the POP; session two is between the POP and the real server (using the server’s real certificate). In the middle, the POP decrypts, inspects in a single pass, and re-encrypts. To make session one work, the POP re-signs the page with the Netskope CA certificate — which is why that CA must be installed and trusted on every endpoint (via MDM/GPO). Miss it, and every HTTPS site throws a certificate warning.

By default, all traffic steered to Netskope is decrypted, then analysed by Real-time Protection policies. You carve out exceptions with an SSL Decryption policy set to Do Not Decrypt (for example, banking or healthcare categories you must not read). Do-Not-Decrypt traffic still reaches Netskope and still matches Real-time Protection — but with limited context, since the payload stays sealed.

④ Certificate pinning, bypass vs Do-Not-Decrypt, and exceptions

Some apps refuse to be inspected. A certificate-pinned app ships with its own certificate baked in and trusts nothing else. When Netskope re-signs the session with the Netskope CA, the pinned app sees a cert it did not expect and breaks — connection failures, not security alerts. Common examples: Dropbox, iCloud, CrowdStrike, Microsoft Teams desktop, many native mobile apps.

Netskope auto-maintains a default bypass list of around 52 enterprise pinned apps (June 2025), so most “just work.” You control how new predefined ones are handled under Settings → Security Cloud Platform → Steering Configuration → Preferences, in the Certificate Pinned Application updates setting — Ask me (default; review each release), Skip (added to the Default config only), or Bypass (added as an exception to all configs). For an app Netskope does not know, you create it under Settings → Security Cloud Platform → App Definition → Certificate Pinned Apps → New Certificate Pinned App (give it a name, platform and the process name, e.g. myapp.exe), then add it as a Steering Configuration exception.

Here is the distinction L1s get wrong in interviews. A Steering Bypass means the traffic never leaves the device for Netskope — it goes direct, so there are no logs in Skope IT. An SSL Do-Not-Decrypt policy means the traffic still reaches Netskope but stays encrypted — you keep a log and a risk score. Netskope’s own guidance: prefer Do-Not-Decrypt over a hard bypass wherever the app tolerates it, so you do not go blind.

One more sharp edge: Enhanced Cert Pinning. Plain pinned-app bypass can over-match — a browser visiting the same domains as a pinned app may also get bypassed, leaving a hole. Enhanced Cert Pinning makes the Client verify the destination domain belongs to that app before bypassing, so only the real app traffic skips inspection.