Netskope Security Configuration Guide: Admins, APIs, Client

A Netskope tenant sees and controls a large share of your organisation's web, SaaS and private application traffic, so a weak admin account, an over-privileged API token or a client that users can switch off undermines every policy it enforces. Netskope's security service edge platform combines a secure web gateway, CASB, ZTNA and DLP behind one admin console, one REST API and one endpoint client. This guide covers the security configuration of the platform itself rather than how to write web or DLP policy: admin roles under RBAC V3, service accounts and API tokens, the Netskope Client's tamperproof and steering settings, audit logging and log streaming, and the misconfigurations that most often weaken a deployment. It is written for security engineers and platform owners running or inheriting a Netskope tenant, and it is vendor-neutral: it explains features documented by Netskope, not whether to buy them. The peer page for another platform is the Zscaler Security Configuration Guide.

Key takeaways

Tenant Admin is the crown jewel. Under RBAC V3 only the predefined Tenant Admin role can manage other admins and roles, and an IP allowlist cannot be applied to it, so keep the number of Tenant Admins minimal and protect them through SSO with strong MFA.
Move API access to service accounts. With RBAC V3 enabled, the REST API v2 token page is deprecated; new access uses service accounts with a custom least-privilege role, an expiry and optionally a role IP allowlist.
Audit API source IPs before allowlisting. Netskope warns that enabling allowlists without a 90-day audit of API clients can block SIEM, SOAR and SCIM integrations, a self-inflicted denial of service.
Users must not be able to turn the client off. Disable client disabling for end users, set an uninstall password and remove local admin rights, because local administrators can bypass tamperproof controls.
Decide fail open or fail closed deliberately. Netskope can block traffic when the tunnel is not established; it is documented as beta and Windows-only in the steering settings, so pilot it before broad use.

How identity and access work in Netskope

Netskope's RBAC V3 model separates two kinds of administrator identity, and the difference drives most hardening decisions.

Identity type	Used for	Authentication	Key constraints from Netskope documentation
User account (local)	People signing in to the admin console	Email and password, optional MFA at invitation	Local account settings: idle timeout 5 to 60 minutes, failed login threshold minimum three, option to block concurrent logins, password expiry
User account (SSO or SCIM provisioned)	People signing in through the corporate identity provider	SAML through the IdP	Roles are assigned and managed by the IdP; if a local and SSO user share an email, the account shows as Local and the local role applies
Service account	Programmatic REST API access	Revocable API token	Cannot sign in to the UI, has no password or MFA, token shown once at creation, expiry set at creation
Legacy REST API v2 token	Older integrations	Token scoped to selected endpoints	Provisioning deprecated once RBAC V3 is enabled; existing tokens work until expiry and cannot be extended

Prefer SSO for people: use SAML through your IdP so joiner and leaver processes, conditional access and phishing-resistant MFA apply. See the Phishing-Resistant MFA Guide.
Watch the local-account override: because a local account wins over an SSO account with the same email, leftover local accounts can keep a stronger role than the IdP intends. Review the Provisioned By column and remove local accounts that duplicate SSO users.
Keep a break-glass local admin: one or two local Tenant Admin accounts with MFA, stored credentials and alerting cover IdP outages. See the Break-Glass Account Guide.

Admin roles and privileged access

Netskope documents that only the Tenant Admin role holds the Administration > Admins > Manage permission, and that this permission cannot be granted to custom roles, which prevents privilege escalation through role editing. Roles must exist before you invite an admin or create a service account.

Admin function	Suggested role design	Why
Tenant and admin management	Tenant Admin, two to four named people plus break-glass	Only role that can manage admins and roles
Policy authoring (SWG, CASB inline, DLP)	Custom role with manage rights on policy areas only	Policy staff do not need admin management
Client and steering configuration	Custom role for endpoint team	Client settings control whether traffic is inspected at all; keep separate from policy authors
SOC and incident response	Read-only role for events, alerts and audit log	Investigation without the ability to change policy
Help desk	Narrow role, for example viewing user and device status	Help desk accounts are a common social engineering target

Session limits: set idle timeout towards the lower end of the 5 to 60 minute range for local accounts, lock after the minimum number of failed logins your operations tolerate, and block concurrent logins.
Review regularly: list admins quarterly with Last Login and Auth method columns, remove dormant accounts and confirm every admin's email domain is one of the tenant's configured domains.
Vendor access: the audit log can filter on whether activity was by Netskope personnel; review that filter as part of the quarterly review.

See the Privileged Access Management Guide for the wider model.

Integrations, API tokens and service accounts

A Netskope tenant typically has integrations for SCIM provisioning from the IdP, SIEM and SOAR collection, event streaming, ticketing and custom reporting scripts. Each one is a non-human identity with access to sensitive telemetry or the ability to change configuration.

Audit current API clients: Netskope recommends auditing API client source IPs over at least 90 days (matching its default log retention) using the datasearch endpoints and the srcip field, then mapping each IP to an owner and purpose.
Create a least-privilege role first: under Administration > Roles, create a role per integration. Netskope's SCIM example selects only the Administration category, removes UI function permissions and sets Users and Group APIs to Manage. Event streaming needs only the Administration > Event Streaming permission.
Add a role IP allowlist: on the role's IP Allowlist tab, list the integration's source IPv4 addresses. A role allowlist supersedes the global allowlist for that role.
Create the service account: under Administration > Administrators & Roles > Service Account, assign the role and set an expiry (Netskope's example is 12 months). Copy the token immediately into your secrets manager: it is displayed once and cannot be retrieved.
Cut over and test: replace the old v2 token in the consuming system, for SCIM also updating the base URL to the tenant's /api/v2/scim path, and test. If the test fails, check whether the role allowlist excludes the client's current IPs.
Retire v2 tokens: legacy tokens cannot be extended, so record their expiry dates and plan migration before they lapse.

Integration	Minimum permission	Risk if over-privileged
SCIM from IdP	Users and Group APIs: Manage	Token could also change policy or admins
SIEM or data lake pull	Read access to required event and alert data sets	Read token often becomes a write token by convenience
Event streaming client	Administration > Event Streaming	Broader roles expose unrelated configuration
SOAR response actions	Only the specific actions automated, for example adding to a block list	Automation could disable policies tenant-wide

Stolen tokens are a known path to cloud control planes (ATT&CK T1528 Steal Application Access Token). Store tokens in a vault, never in scripts or repositories, and rotate before expiry. See the API Key Management Guide and the SCIM Provisioning Guide.

Netskope Client and steering hardening

Tamperproofing

Allow client disabling: turn off for end users. Netskope recommends a separate client configuration profile for IT staff who need to disable the client for troubleshooting.
Uninstall password: enable password protection for uninstalling the client and stopping its service, and keep the password in your PAM vault.
Protect Client configuration and resources: prevents users with elevated privileges from modifying, renaming or deleting client files, folders, processes and registry keys.
Client configuration encryption: encrypt the configuration files the client downloads.
Local admin rights: Netskope notes that local administrators can bypass tamperproof controls; remove them from managed devices where possible. Disabling security agents is tracked in ATT&CK v20 as T1685 Disable or Modify Tools.
Upgrades: Netskope recommends automatic upgrades to the Golden Release, which is more thoroughly tested and supported longer than the newest release. Keep client logging below Debug unless support asks for it.

Steering

Traffic mode	What is steered	Licence noted by Netskope	Use when
Cloud Apps Only	Specific cloud apps; custom apps can be added	Not stated on the steering page	Initial CASB-only deployments
Web Traffic	All HTTP and HTTPS	SWG or Next Gen SWG	Web gateway replacing an on-premises proxy
All Traffic	HTTP(S) and non-HTTP(S)	Cloud Firewall	Full egress control for remote users
None	No tunnel; client monitors on-premises status	Not applicable	Specific device groups only

Exceptions: keep bypass lists short, documented and reviewed. Every domain, IP or certificate exception is traffic you are not inspecting. See the TLS Inspection Guide.
Fail closed: the tamperproof option to block all traffic if the client tunnel is not established prevents silent bypass. In steering, Fail Close is documented as beta and Windows-only (macOS and iOS through client configuration); domain, IP and certificate exceptions still apply but category-based exceptions are blocked, and the Local IP address range destination exception must be removed. Pilot with a small group and confirm help desk procedures first.
Dynamic steering: lets the client apply different settings on and off premises with up to three on-premises detection profiles. Netskope advises not toggling dynamic steering off and on repeatedly, because exceptions can be lost.
Safe change process: Netskope recommends keeping a new steering configuration disabled until its steered items and exceptions are complete. Clone the production configuration, test it on a pilot group, then switch groups over; rollback is moving the group back to the previous configuration.
Before enrolment: Enforce Enrollment allowed destinations lets named destinations pass direct on TCP 80 and 443 before the user enrols; keep this list to what enrolment needs.

Logging and detection

Audit Log: under Settings > Administration > Audit Log, Netskope records admin logins (successful, failed, SSO and logouts), access denials, password changes, admin account creation, deletion, disabling and unlocking, and configuration changes including inline policies, tunnel groups and API protection settings. Filters include severity and Netskope personnel. The console defaults to showing the last seven days; export or stream it rather than relying on the console view.
API activity: Netskope's migration guidance treats REST API data as the most reliable source for API administrative activity. Collect source IPs of API calls and compare them with the expected integration IPs.
Log Streaming: streams Netskope logs to cloud storage and SIEM tools without extra infrastructure. It requires an additional licence, and Netskope notes up to 0.1 per cent duplicate events at the destination because of retransmission, so deduplicate in the SIEM.
Client health: track devices whose client is disabled, not connected or on an old version, from client status data, and correlate with EDR telemetry.

Detection	Signal
Admin account created or role changed outside change window	Audit log admin account events
Failed admin logins followed by success from a new location	Audit log login events
Steering or client configuration changed	Audit log configuration changes
API call from an unexpected source IP	API activity srcip not in integration inventory
Spike in devices with client disabled	Client status, correlated with tamperproof settings

Metrics: number of Tenant Admins (target small and stable); percentage of human admins on SSO with MFA; service accounts with owner, expiry and IP allowlist (target 100 per cent); legacy v2 tokens remaining; managed devices with the client connected and steering active (target above 98 per cent); bypass exceptions reviewed in the last quarter.

Hardening baseline

Enable SSO for all human admins and require phishing-resistant MFA at the IdP.
Limit Tenant Admin to a few named people plus break-glass local accounts with MFA.
Build custom roles per function; do not use Tenant Admin for day-to-day policy work.
Set local account idle timeout, failed login lock and concurrent login blocking.
Migrate every integration to an RBAC V3 service account with least privilege, expiry and role IP allowlist, after a 90-day IP audit.
Turn off client disabling for users, set the uninstall password, protect client resources and remove local admin rights.
Use Golden Release automatic upgrades.
Decide and document fail open or fail closed per device group, and pilot fail closed.
Stream audit and event logs to the SIEM and alert on admin, role, steering and client configuration changes.
Review admins, service accounts and steering exceptions quarterly.

Small versus large tenants: a small team may have only two or three admins, all Tenant Admin; even then, use SSO, MFA and a separate break-glass account, and give integrations their own service accounts. Large tenants should add separate roles for policy, endpoint and SOC teams, change approval for steering and client profiles, and automated reporting of the metrics above.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	IA-2, IA-2(1), IA-5	Admin authentication, MFA for privileged accounts, token and password management
NIST SP 800-53 Rev 5	AC-2(1), AC-17, SC-7	Automated account management (SCIM), remote access and boundary protection through the SSE
NIST CSF 2.0	PR.AA-01, PR.IR-01, DE.CM-01	Identity and credential management, protecting environments, monitoring network services
MITRE ATT&CK v20	T1078.004 Cloud Accounts; T1528 Steal Application Access Token; T1685 Disable or Modify Tools	Admin account takeover, token theft and client tampering

Common misconfigurations

Everyone is Tenant Admin: policy authors, help desk and contractors all hold the one role that can manage admins.
Local accounts shadowing SSO: a local account with the same email as an SSO user keeps its local role after the IdP role is reduced.
Broad, non-expiring tokens: one legacy token with many endpoints shared across scripts, stored in plain text, with no owner.
Allowlist without audit: enabling an IP allowlist before inventorying API clients breaks SCIM or SIEM collection, and teams then remove allowlists entirely.
Users can disable the client: client disabling left on, or local admin rights in place, so inspection is bypassed whenever it is inconvenient.
Exception creep: steering bypasses added for troubleshooting and never removed, until large parts of traffic are uninspected.
Audit log left in the console: no streaming or export, so admin changes are not visible to the SOC.

Practitioner checklist

List all admins and service accounts with role, provisioning source, last login and owner.
Reduce Tenant Admin holders and protect them with SSO, MFA and break-glass procedures.
Create custom least-privilege roles for policy, endpoint, SOC and help desk functions.
Audit API source IPs over 90 days, then move integrations to RBAC V3 service accounts with expiry and role IP allowlists.
Store every token in a secrets manager and record its expiry.
Disable user client disabling, set the uninstall password and protect client resources.
Pilot fail closed on a small Windows group before wider rollout.
Stream the audit log and alert on admin, role, steering and client configuration changes.
Review steering exceptions and admin access every quarter.

Standards and references

Related NHI Mgmt Group resources: Zscaler Security Configuration Guide · SASE and SSE Guide · CASB Guide · API Key Management Guide

Netskope Security Configuration Guide: Harden Admin Roles, Service Accounts, Steering and Client