Netskope Private Access (NPA): — ZTNA Without the VPN

① Why the VPN has to go — what ZTNA really changes

Picture the VPN you already know. Karthik works from home, fires up the VPN client, types his password, and a tunnel drops his laptop inside the office network. From that moment he can ping the file share, the finance server, the HR app — everything on that subnet — whether his job needs it or not. The VPN authenticated him onto the network, then stopped asking questions.

That is the flaw. One stolen VPN credential, or one piece of malware on Karthik’s laptop, now has a flat runway across the whole LAN — what attackers call lateral movement. The VPN’s trust model is binary: in or out.

ZTNA rewrites the rule to per-app least privilege. Netskope delivers it as NPA: Karthik is brokered to exactly the one app his policy allows — say Jira — and the network underneath stays invisible. No subnet, no lateral runway, and (the part that surprises people) no inbound firewall port at all.

Four ideas that separate ZTNA from a VPN

Tap each card — these are the mental models the rest of the lesson builds on.

② The Publisher and the broker — outbound dial-out

The piece that makes NPA work is the Publisher — a lightweight VM or container you drop next to your private apps. It never listens for inbound connections. Instead it dials outbound to the Private Access Broker over the Netskope cloud and keeps that channel ready.

When Karthik requests Jira, the Netskope Client steers the request to the broker. The broker checks identity and device posture against policy, then stitches the user’s session to the Publisher that already dialled out. The Publisher forwards to the app over TLS 1.2. Every connection across the company edge points outward.

You register a Publisher under Settings → Security Cloud Platform → Publishers: click New Publisher, give it a name, pick an Auto-Update profile, then Save & Generate Token and Copy the registration token the connector uses to dial home. Publishers also need care over their lifecycle. Netskope’s own guidance is "do not recover, redeploy" — for a dead Publisher you do not try to revive the image, you deploy a new Publisher image and re-register it under the same Publisher definition (open it, generate a fresh token, register the new VM). The status in the console reads Connected or Disconnected, and a Disconnected Publisher is the first thing to check when one app group goes dark.

③ Defining the private app — Host, Port, Publisher

A Private App Segment is where you tell Netskope what the app is. You build it under Settings → Security Cloud Platform → App Definition → Private App Segments → New Application Segment. Four fields carry the weight: Application Name, Host, Port, and Publisher.

Host accepts an FQDN or PQDN, a wildcard (minimum 3 labels, e.g. *.corp.com), an IPv4 address, or an IPv4 CIDR (minimum /8). A client app can list up to 500 hosts; a browser app takes exactly one. Bare TLDs (.com, .net), 0.0.0.0/0 and CIDRs smaller than /8 are rejected — those would be far too broad to steer safely. Port takes a single value (443), a range (1024-2048), or a combo (22,80,443,1024-2048). Up to 16 Publishers can serve one app by default, and a tenant supports up to 6,000 Application Segments.

Now the trap that burns most engineers: Use Publisher DNS. Turn it on and the Publisher resolves the internal name — handy when the app’s real IP only makes sense inside the data centre. But because the real IP is what comes back, the Client no longer knows what to intercept unless you ALSO give the segment an explicit CIDR or IP. Best practice: pair each host with a tight /32 CIDR so you steer precisely that host and nothing else.

④ Access policy, client vs clientless, and retiring the VPN

Defining the app is half the job; the other half is who may reach it and on what device. That lives in Real-time Protection. You add the rule via Policies → Real-time Protection → New Policy and pick the Private App Segment Access template. It names a Source (Users / User Groups / OUs), a Destination set to the Private App Segment (or a Private App Tag), the Access Method (set to Client for client-based — iOS always requires the Client), a Device Classification (Managed vs Unmanaged), and an action (Allow / Block).

Before any of that tunnels, one switch must be on: Steer all Private Apps under Settings → Security Cloud Platform → Steering Configuration. Forget it and your perfectly-defined app and policy do nothing — the Client never tunnels private traffic. It is the single most common NSK101 trap.

For people who cannot install the agent — contractors, BYOD, third parties — use Browser Access. It reverse-proxies internal web apps over a browser on 80/443, and via NPA AnyApp it can even publish RDP and SSH through the browser. The catch: apps with hard-coded internal redirect URLs (or an internal proxy not published externally) break clientless — fix them with the custom-hostname method plus an external-DNS CNAME so redirects land on the published name.

Replacing a VPN is then a phased cutover: stand up Publishers, discover the apps people actually use (NPA can surface private-app traffic), define a segment per app, write least-privilege policies, pilot one team, then turn the VPN off team by team. For the awkward apps a basic ZTNA could never do — server-initiated flows, VoIP, peer-to-peer, thick-client, latency-sensitive — ZTNA Next brings NPA together with SWG/firewall in one client so you can hit true 100% VPN retirement.

One thing to know for interviews and 2026 deployments: Netskope’s Universal ZTNA push (Oct 2025) added Netskope Device Intelligence and One Copilot for Private Access — an AI that auto-creates granular policy for discovered apps and continuously audits configs — plus IoT/OT coverage for agentless devices via the 5G Netskope One Gateway, which can host a Publisher right at the branch. The same DLP and threat engines also inspect this private-app traffic.