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.
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)
- 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
- Standard Actions for Client Based Policies
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.
Configure Private App Access Policies
- 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.
- 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.
- Select the Activities that the destination rule is applied to (Only valid with Browser Access and applying a DLP Profile).
- 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.
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.
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.
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
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.
- Check: The system calculates the time since her last authentication:
- 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. 🔄
- Check: The system calculates the time elapsed:
- 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.
- Check: The system uses the newest timestamp:
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.)

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.
Related links
- Enforce DLP for NPA Browser Access Private Apps for Browser Access-specific prerequisites and legacy context.
- Data Loss Prevention / About DLP for profiles, rules, identifiers, and incidents.
- Supported File Types for Content Inspection for file-format coverage.
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.

