Per-User Enrollment Tokens for IdP Mode on Non-MDM Devices

Generated with the assistance of Claude Opus 4.6 (Anthropic) -- but any slop is my fault for not managing context.

Summary
 

We need a per-user, one-time enrollment token mechanism for IdP-mode enrollments on devices that cannot receive tokens via MDM (mostly Chrome or Linux laptops, unmanaged or “lightly managed” endpoints). The current Secure Enrollment model provides tenant-wide shared tokens distributed via MDM. We have specific questions about how Enforced/Not Enforced status interacts with IdP vs UPN enrollment, and whether per-user scoped tokens are available or planned.
 

Environment

• Tenant: XXXX.goskope.com
• Secure Enrollment Service: Enabled
• Token set 1: Created Jan 2026, Status: Enforced (auth + encryption), Expiry: roughly 1 yr
• Token set 2: Created Mar 2026, Status: Not Enforced (auth + encryption), Expiry: roughly1yr
• Secure Configuration Service: Enabled
• IdP: Okta (SAML Forward Proxy configured with Client Enrollment access method)
• Deployment modes: UPN via Intune/Jamf (Windows/macOS), IdP mode (Linux/Chrome/other)
• SCIM provisioning: Active via Okta

What we observed
 

A Linux user (Ubuntu 22.04) installed the Netskope client with -installmode=IDP and no enrollment tokens. The Okta SAML authentication completed successfully (user saw “Authentication successful, Configuration will automatically be downloaded, You are being redirected”), but the client never received configuration. stAgentCli show-config continued to report “IdP enrollment is required by admin.” Zero Netskope events appeared for the user in datasearch.

We believe this is because the encryption token is enforced on Token Set 1, and per the Enrollment Token Management documentation, the encryption token — when enabled and enforced — is required on end user machines in both UPN and IdP mode. The authentication token, by contrast, is only mandatory for UPN and NPA Prelogon.

 

Documentation reviewed

• Enrollment Token Management — states authentication token is mandatory for UPN/Prelogon only; encryption token (if enforced) applies to both UPN and IdP
• Secure Tenant Configuration and Hardening — recommends enabling Secure Enrollment with Authentication Token for strict enforcement
• Client Deployment Options — confirms Linux supports Email deployment only (no MDM)
• GTS Case Insights - Secure Enrollment (Wilfredo Marchena Luzon, Cloud Version 126) — documents the R120.1 behavior change where “Not Enforced” tokens are genuinely ignored on R120.1+; on R120 and earlier, enrollment failed even with Not Enforced status
• Understanding and Actioning Notification Related to Secure Enrollment (Saniya Murtuza, Cloud Version 123) — confirms email invite enrollments are not affected by Secure Enrollment enablement
• Identify mode of enrollment (UPN vs IdP) — confirms no tenant-level visibility into which enrollment mode was used per device
• MDM Distribution UI tooltip for Status column: “Enforce or Not Enforced options leverage or ignore tokens. You cannot enroll without the tokens even in the Not Enforced status. Ensure to enforce tokens if you want to use UPN enrollment method.”

What we could not determine

1. The Enrollment Token Management page states the encryption token applies to both UPN and IdP if enforced. Our Token Set 1 has the encryption token enforced. We have a second Token Set (Not Enforced). Per the GTS Case Insights article, “Not Enforced” tokens are ignored on R120.1+. Does this mean an IdP-mode client on a current version can enroll without any tokens if a Not Enforced token set exists, even though an Enforced token set also exists on the same tenant? Or does the presence of any Enforced token set gate all enrollments regardless?
2. The tooltip text (“You cannot enroll without the tokens even in the Not Enforced status”) appears to contradict the GTS Case Insights finding that R120.1+ clients can enroll with Not Enforced tokens. We were unable to reconcile these.
3. We could not determine whether Netskope logs which token set was used during enrollment, or whether a token was presented at all

Questions

1. Can IdP-mode enrollment succeed without tokens if the encryption token is enforced on one token set but a second token set exists with Not Enforced status? We need to understand whether enforcement is evaluated per-token-set or globally across all token sets.
2. If we remove the encryption token from our Enforced token set (leaving only the authentication token enforced), does IdP enrollment proceed without any tokens? The documentation says the authentication token is only mandatory for UPN/Prelogon, and the encryption token is optional. This seems like it should work.
3. Does Netskope log which token set was used during enrollment, or whether a token was presented at all? We want to distinguish MDM-enrolled devices (with tokens) from IdP-enrolled devices (without tokens) for audit purposes.
4. Is there a per-user, one-time enrollment token mechanism accessible via API? Email invite provides this (user-scoped, single-use, expires after enrollment), but sending invitations appears to require browser session cookies rather than a REST API token. The community mentions /api/v2/enrollment/tokenset — is there a corresponding API for user-scoped invitations?
5. What is Netskope’s recommended enrollment architecture for mixed fleets? We want MDM-managed devices (Windows/macOS) to continue using UPN with Enforced authentication tokens, while non-MDM devices (Linux) use IdP enrollment without shared secrets. Is this a tested and supported configuration?

Desired outcome

Ideally we could do per-user, one-time enrollment tokens that can be generated and distributed programmatically for non-MDM devices, without exposing the tenant-wide shared enrollauthtoken outside MDM channels. Alternatively, confirmation that IdP-mode enrollment works without any tokens when only the authentication token (not the encryption token) is enforced — which would let us use Okta SAML as the sole enrollment gate for unmanaged devices.