Private App Segment Policy Management - Netskope Technical Documentation

Private App Segments are not steered by default, which means by default private apps are never accessible to end-users, and they also will not receive a user notification about this. The end-user’s steering profile needs to be updated to include the private apps required for the User (Group/OU), and a matching real-time policy must exist if no discovery is configured for the user. Policies are required to log events and enable access to Users, Groups, or OUs.

Important

Beginning in R142, NPA DLP and Threat Protection policies only perform inspection — they no longer grant access to the private application. Because NPA does not allow traffic by default, each private app you inspect now also needs a dedicated Real-time Protection (Private App Access) policy that allows access. Create both policies before R142 reaches your tenant to avoid a temporary loss of connectivity. If you are not entitled to NPA DLP/Threat Protection, remove those policies instead of adding an allow policy.

Important

Beta — User Confidence: User Confidence Index (UCI) is available as a source criterion for approved commercial tenants using Netskope Client access and an Advanced UEBA license. FedRAMP, PBMM, Browser Access, and Enterprise Browser are outside this beta. Contact your Netskope account team for enablement. See Configure User Confidence Policies.

Use Real-time Protection policies to

Define access to a Private App Segment leveraging Source Policy criteria:
- Access Method: Browser Access and/or Client (Optional)
- Specific User(s), User Group(s) or Organization Unit(s) (Optional)
- Source IP (Egress) (Optional)
- User Confidence Index (UCI) (Optional; Beta, Client only)
- Operating System (Optional)
- Device Classification (Optional)
Define access to a Private App Segment leveraging Destination Policy criteria:
- Using an individual Private App Segment
- Or leveraging Private App Segment Tags
- And optionally with a browsing activity when applying a Data Loss Prevention or Threat Protection profile:
  - Download, Upload or FormPost (Optional)
  - File Constraints: File Name or Extension, File Type or File Size
Define Profiles and Action:
- Standard Actions for Client Based Policies
  - Allow
  - Block
  - Periodic Authentication
- Profiles available for Client and Browser Access
  - DLP Profile
- Profiles available for Client Access
  - Threat Protection Profile

For a specific private app, you may want to have one policy that grants access for a defined set of users, and then use a second policy that blocks and notifies users who don’t have access.

Before You Begin

Before creating a policy:

Enable Netskope Private Access for your tenant.
Configure a Publisher and the private app segments you want to protect.
Make the required users, groups, or organizational units available in the tenant.
Configure traffic steering and deploy the Netskope Client for Client access. For Browser Access, configure the private application and identity provider for that access method.
Review the requirements for any optional inspection profile or authentication action.

Policy Documentation

Page	Content
Source Policy Criteria	Identity, access method, egress IP, country, OS, device classification, and the permanent User Confidence reference.
Configure User Confidence	Beta prerequisites, configuration, examples, validation, and limitations.
Destination Policy Criteria	App segments, tags, activities, file constraints, and destination matching.
Profiles and Actions	Access-versus-inspection behavior and links to each action/profile page.
End-User Notifications	Complete notification fields, branding, localization, and authentication templates.

Policy-order scope

Instructions below to place an inspection policy before an access policy apply to releases before R142. In R142, that relative order is no longer required to combine access and inspection. Continue to review the order of competing access rules.

Configure Private App Access Policies

When configuration Private App Access Policies for Applications that also require Threat Protection or Data Loss Prevention Profiles you must ensure the placement of the Access Rule is after the DLP or Threat Protection rule on Netskope version before R142.

Go to Policies > Real-time Protection.
Click New policy and select Private App Access.
For Source you can configure the following options:
- Specify the Users, OU, or Groups for which the Private App Access Policy is applied. (If not specified it’s applied to all Users.)
- Specify whether the Access Method is Browser Access or Client (Threat Protection profiles are only available for Client Access)
- Restrict access based on Source IP (Egress) which allows administrators to restrict access to Private App Segments based on the Egress IP of the end-users.
- For eligible beta tenants, click Add Criteria > User Confidence to restrict access according to the user’s UCI score. Select Client as the access method. See Configure User Confidence Policies for requirements and configuration.
- The Operating System for which the Private App Access Policy is applied to (Client only).
- Which Custom Device Classification profile must be active for the user for the rule to apply (Client only; Browser Access will always be marked as a Unmanaged Device).
For Destination:
- Select Private App Segment and add Private App Segments underneath.
- For an inspection policy, select the Activities supported by the selected profile and access method. NPA DLP supports Client and Browser Access within the documented HTTP/HTTPS scope.
For Action, select Allow to grant access. To deny access, select Block, select a policy notification template from the dropdown list, or create one. To enforce Periodic Authentication ensure the Source OS criteria is set to Windows and/or MacOS and select a customer end-user notification template for the rule.
Give the policy a name, and then click Save.
In the Status section, confirm the policy is Enabled. Optionally, click + Policy Schedule to restrict when this policy is active based on day, date, and time of day. For full configuration details, see Time-Based Policies.
Click Apply Changes.
If this Private App Access Policy is intended for an application with a DLP or Threat Protection Policy, then ensure the placement of the access policy is after the DLP/Threat Protection Rule in your policy order, to ensure your DLP and Threat Protection profiles are applied.

Per-App Periodic Authentication for Private App Segment policies: Periodic Authentication is available on policies with a Threat Protection or Data Loss Prevention profile starting from Netskope release R142.

Policy Schedule caveats for Private App Segment policies: Browser Access/Enterprise Browser: Although a Policy Schedule can be configured on Browser Access and Enterprise Browser policies, enforcement is not yet supported for these access methods. Support is planned for a future release. Local Brokers: Policy Schedule will only be enforced when user traffic is egressing from a public IP address (non RFC-1918) to the Local Broker. Traffic originating from private/internal IP ranges will bypass the time-based enforcement.

You can select a policy group and optionally add a policy description or email notification in the editor before saving.

Validate the Policy

Connect as a user included in the policy and access a selected private application. Verify the expected allow, block, or authentication result.
Test with a user or device that does not meet the policy criteria. Verify that another policy does not grant unintended access.
If the policy uses a network, country, or user-confidence condition, test a matching and a nonmatching condition.
Review the resulting network events and applicable alerts. For inspection policies, also test the content and activity that should trigger the selected profile.

If the result differs from the policy, verify the selected access method, user identity, application definition, policy status, policy order, and whether changes have been applied.

Detailed Configuration Topics

See Configure user confidence policies.

See Uci prerequisites.

See Select a uci threshold.

See Configure a uci access policy.

See Validate the uci policy.

See Uci beta behavior and limitations.

See Configure per app periodic authentication policies.

See Prerequisites.

See Configure a periodic authentication real time policy.

See How the authentication timer works.

See Use case example.

See Configure threat protection policies.

See Create a file hash list.

See Configure threat protection for real time private app access policies.

See Configure data loss prevention policies.

See Prerequisites 1.

See Configure a dlp policy for private apps.

See Additional notes.

See Validation.

See Related links.

See User notification configuration.

Configure User Confidence Policies

Use User Confidence as a source criterion to control access to private applications according to user risk. Netskope Advanced UEBA provides a User Confidence Index (UCI) score from 0 to 1000. Lower scores indicate greater user risk.

For example, an allow policy can require a UCI score greater than 650 before a user can access a sensitive private application. The user must also satisfy the policy’s other source and destination criteria.

Beta availability: User Confidence for Private App Access is available in beta for approved commercial tenants using the Netskope Client. An Advanced UEBA license is required. FedRAMP, PBMM, Browser Access, and Enterprise Browser are outside the scope of this beta. Contact your Netskope account team to confirm eligibility and enable the feature.

UCI Prerequisites

Before configuring the policy:

Have Netskope Private Access and an active Advanced UEBA license.
Use a Netskope Client version and operating system approved for the beta. Confirm the supported versions with your Netskope account team before including devices in the pilot.
Configure the private app segments, Publisher, user identities, and traffic steering required for Client access.
Verify that UCI information is available in Advanced UEBA for the identities used in the pilot.
Confirm eligibility with your account team if the pilot uses Local Broker, China connectivity, or Saudi Arabia infrastructure.

Select a UCI Threshold

The User Confidence control provides the following comparisons and thresholds:

Comparison	Threshold	Matching UCI scores
Less Than	351 (Poor rating)	0–350
Less Than	651 (Poor and Moderate rating)	0–650
More Than	350 (Good and Moderate rating)	351–1000
More Than	650 (Good rating)	651–1000

The comparison determines whether the policy matches. The policy action determines whether matching access is allowed or blocked.

Note: If no UCI record is available for a user, the documented default score is 1000. Verify the user’s identity and UCI information in Advanced UEBA. A score of 1000 alone does not establish that the user’s activity has been evaluated.

Configure a UCI Access Policy

Go to Policies > Real-time Protection.
Click New Policy > Private App Segment Access. Some releases label this option Private App Access.
For Source, select the pilot users or user group and set Access Method to Client.
Click Add Criteria > User Confidence.
Select Less Than or More Than, then select a threshold. For this example, select More Than and 650 (Good rating).
Add any other required source conditions, such as OS or Device Classification.
For Destination, select the private app segments to protect.
For Profile & Action, select Allow for this example.
Enter a policy name, such as Finance App – UCI Above 650, select a policy group, verify that the policy is enabled, and click Save.
Review other policies that can grant the same users access to these applications. A broader allow policy must not bypass the intended UCI restriction.
Click Apply Changes.

In this example, a score of 800 matches the UCI condition, while a score of 650 or 300 does not. Access is allowed only when the remaining criteria match. A nonmatching UCI condition does not by itself block access if another applicable policy permits the connection.

If User Confidence is disabled in the editor, verify that Client is the only selected access method and ask your Netskope account team to check the entitlement and beta enablement.

Validate the UCI Policy

Record the test user’s identity and current UCI score in Advanced UEBA.
Access the selected private application through the Netskope Client and verify the expected result.
Coordinate with your account team to test users on both sides of the threshold, including the boundary value. Verify that other policies do not grant unintended access.
Allow time for score propagation and policy refresh before retesting a changed score. Record the score, access result, and time of the test.
Test score recovery and verify the expected access after the updated score is evaluated.
Review the applicable network events and alerts. Use Advanced UEBA to check the score; this beta does not add a new UCI field to NPA network events.

UCI Beta Behavior and Limitations

A UCI-only score change does not trigger an immediate policy refresh. Allow for score propagation and periodic policy refresh when evaluating access changes.
User Confidence is a policy criterion. It does not configure risk-triggered MFA or reauthentication. For interval-based authentication, see Configure Per-App Periodic Authentication Policies.
Review the remaining policy conditions before removing UCI criteria or disabling the beta. Removing a condition can broaden the access granted by the policy.

Configure Per-App Periodic Authentication Policies

Periodic Per-App Authentication introduces an additional layer of security by requiring users to periodically authenticate when accessing specific Private App Segments. This feature is available for desktop devices only (Windows and macOS).

Prerequisites

SAML Forward Proxy must be configured and deployed to enable client enrollment and user identification.
Users must use the same identity (Email) as during client enrollment in order for authentication to succeed.
Source OS criteria needs to be set to Windows and/or MacOS in order to select the new Periodic Authentication action.
Netskope Client needs to be at version R133 or higher.

Configure a Periodic Authentication Real-Time Policy

To enforce periodic authentication:

Go to Policies > Real-Time Protection Policies.
Click New Policy > Private App Access.
For Source Criteria, include Operating System = Windows and/or macOS.
Select Client for the Access Method.
Select the Private App Segment(s) for the Destination.
Select Periodic Authentication for the Action, and define the authentication interval (like every 30 minutes).
Select a User Notification template.
When finished, click Save.

After a user’s authentication expires, existing sessions remain valid. However, new sessions will require authentication after the interval expires.

Note: Periodic Authentication is only available on Windows and MacOS.

How the Authentication Timer Works

The system’s timer logic is simple yet powerful. It relies on a single timestamp that marks the user’s most recent successful authentication for any private application.

Think of it as a universal hall pass that gets a new timestamp every time you’re asked to re-authenticate. When you try to access an app, the system simply checks if the time elapsed since you got your last timestamp is greater than the specific authentication interval required for that app.

Use Case Example

Periodic Per-App Authentication works very different from the NPA periodic re-authentication mechanism that existed already. Periodic Reauthentication brings the entire NPA tunnel down after a set timer if authentication does not happen; per-app authentication works before a user accesses an application and does not interact with the NPA tunnel.

Here’s a real-world scenario to show how this works in practice.

Imagine we have two policies configured for a user, Alice:

App A (GitLab): Requires authentication every 90 minutes.
App B (Jira): Requires authentication every 60 minutes.

Here is a timeline of Alice’s activity:

9:00 AM: Alice accesses GitLab (App A) for the first time.
- Action: She is prompted to authenticate. Upon success, access is granted.
- Result: The system’s Last Authentication Time for Alice is now set to 9:00 AM. ⏰
9:50 AM: Alice opens Jira (App B).
- Check: The system calculates the time since her last authentication: 9:50 AM - 9:00 AM = 50 minutes.
- Action: Since 50 minutes is less than Jira’s 60-minute interval, no new authentication is needed. Access is granted seamlessly.
- Result: The Last Authentication Time remains 9:00 AM.
10:10 AM: Alice tries to access Jira (App B) again.
- Check: The system calculates the time elapsed: 10:10 AM - 9:00 AM = 70 minutes.
- Action: Since 70 minutes is greater than Jira’s 60-minute interval, Alice is prompted to re-authenticate.
- Result: Upon success, the Last Authentication Time is updated to 10:10 AM. 🔄
10:30 AM: Alice navigates back to GitLab (App A).
- Check: The system uses the newest timestamp: 10:30 AM - 10:10 AM = 20 minutes.
- Action: Since 20 minutes is less than GitLab’s 90-minute interval, no authentication is required.
- Result: The Last Authentication Time remains 10:10 AM.

This single, rolling timestamp ensures that authentication happens based on the policy of the app being accessed, relative to the user’s last system-wide authentication event.

Configure Threat Protection Policies

Netskope Private Access (NPA) allows organizations to apply Threat Protection to web traffic (ports 80 and 443) for private apps, ensuring files are scanned for malware in real-time. When using Threat Protection with NPA, note that this feature:

Requires Client as the Access Method.
Scans all web traffic on HTTP (80) and HTTPS (443).
Applies real-time scanning to protect private app access from malware and other advanced threats.

Netskope Private Access now also supports Client to Server IPS protections based on HTTP (80) and HTTPS (443). More information can be found here: About IPS Settings.

Create a File Hash List

Define hash values (MD5/SHA-256) for files to be detected.
Use these lists to allowlist (safe) or blocklist (malicious) known file hashes.

Configure Threat Protection for Real-Time Private App Access Policies

Go to Policies > Real-time Protection.
Click New Policy and then Private App Access.
On the Real-time Protection policy page, enter the settings for Source (Users, Access Method and other Source Criteria) and Destination (Private App/Private App Tag) first.
In the Profile & Action section, select Add Profile and choose Threat Protection Profile. Netskope recommends selecting Default Malware Scan (predefined), because it automatically scans across all Threat Protection engines your platform is licensed for.
Select the Action for each severity level. The recommended action for every severity level is Block. This ensures the best protection for users. To apply a remediation profile for each severity level, select a remediation profile from the dropdown list.
Optionally, if you selected File Type constraints, and choose a Block action for a severity level, you can see the Block till benign verdict by dynamic threat analysis option. Select to block users from uploading or downloading a file until Netskope dynamic threat analysis provides a benign verdict. The analysis can take up to 10 minutes. For more details, go to Creating a Threat Protection Policy for Patient Zero.
Enter a name for the policy and click Save.
This Threat Protection Policy only inspects traffic; it does not grant access to the private app. Create a separate Private App Access Policy with an Allow action for the same app and users, and place it after this Threat Protection rule in your policy order so the Threat Protection Profile is applied. (From R142 this order is no longer important.)

When the Fallback Action for Advanced File Scanning is set to Alert or Block, some events might not have policy name if there’s a TSS or DLP fail reason. There’s no rule hit because you excluded the Threat Protection rule. You don’t have a catch-all rule at the end of the policy.

Configure Data Loss Prevention Policies

Netskope Private Access supports applying Data Loss Prevention (DLP) to private apps by using Private App Access real-time policies. Use this configuration to inspect and protect sensitive data for both Browser Access and Client access to private apps. For Browser Access, you can also scope the policy to specific browser activities. For information about creating DLP profiles, rules, and identifiers, see Data Loss Prevention.

Prerequisites

Ensure a Publisher is already configured.
For Browser Access, confirm a SAML reverse proxy IdP for Private Apps is configured.
For Browser Access, verify the private app is configured for Browser Access.
Create the DLP profile you want to apply before creating the policy.

Configure a DLP policy for Private Apps

Go to Policies > Real-time Protection and create or edit a Private App Access policy. The broader real-time policy framework supports DLP and Threat Protection and includes Private App Segment Access as a policy type.
For Source, select the users or groups to which the policy applies, and set the Access Method to Browser Access, Client, or both, depending on the use case.
For Destination, select the Private App Segment(s). Ensure the specific Activities are configured in order to be able to define a Data Loss Prevention Profile.
For Profile & Action, select Add Profile and choose the required DLP Profile(s).
Choose the enforcement action, name the policy, and click Save.
This DLP Policy only inspects traffic; it does not grant access to the private app. Create a separate Private App Access Policy with an Allow action for the same app and users, and place it after this DLP rule in your policy order so the DLP profile is applied. (From R142 this order is no longer important.)

Additional Notes

For NPA Browser Access DLP, only HTTP and HTTPS private apps are supported. AnyApp Browser Access apps such as RDP/SSH are not supported for DLP.
For NPA Client Access DLP, only HTTP and HTTPS over port 80 and 443 are supported.
Transaction events are not generated for DLP traffic, even when transaction events are enabled for web traffic.
Review the Supported File Types for Content Inspection for file-format coverage.
OCR is an Advanced DLP capability in Netskope generally, but OCR is not supported for NPA.

Validation

After saving the policy, test access to the private app with representative content that should trigger the selected DLP profile. Confirm the expected enforcement result and review the resulting DLP alerts or incidents.

User Notification Configuration

This feature uses a new User Notification type to alert users when authentication is required. Follow these steps:

Go to Policies > User Notification (Template Section)
Click Add Template > Private App Segments
Customize the notification with the following in mind:
- Set the Action to Periodic Authentication
- Provide clear context in the message, like the example shown below, or something more specific, like Authentication is required to continue using [App Name]. Please reload after completing authentication.)
When finished, click Save.