Using the Same Private App Domain in Enterprise Browser and Any Browser Apps

This document explains the expected behavior when using Netskope Private Access (NPA) with both Enterprise Browser Private Apps and Any-Browser Private Apps that share the same domain (for example, https://example.com).

When both app types use the same hostname, users who are already signed in to one app type may encounter an error when accessing the other.

What you might see

A typical scenario:

The user signs in to a Private App via Enterprise Browser at https://private.example.com.
Later, the same user visits https://internal-app.example.com (an Any Browser Private App) in Enterprise Browser.
Instead of an SSO prompt, the user sees an error page and cannot access the app.

The reverse order (Any-Browser first, then Enterprise Browser) can cause similar behavior.

Why this happens (high level)

Enterprise Browser and Any Browser Private Apps use different authentication cookies/tokens.
When they share the same hostname, the browser may send a cookie that is valid only for one app type.
Netskope cannot match the request to the correct policy and does not start a new SSO flow.
As a result, users see an error page instead of a sign-in prompt.

When you are likely to run into this

You are more likely to see this behavior if:

You reuse the same domain or custom hostname (for example, https://private.example.com) for both Enterprise Browser and Any Browser Private Apps.
You migrated users from Any Browser to Enterprise Browser but kept the same hostname.
You use the same hostname for different network locations (for example, on-premises vs. remote) relying on DNS or topology, and both flows can occur on that hostname.

Impact

Users see error pages when switching between Enterprise Browser and Any Browser on the same domain.
Access remains blocked until a new SSO flow starts (for example, by clearing cookies, using a different browser profile, or using a different hostname).

Recommended Workarounds

Try one or more of the following:

Use different hostnames for Enterprise Browser and Any Browser Private Apps.
Use DNS or topology to separate the flows.
Use separate browser profiles or different browsers.

Summary

This behavior can occur when Enterprise Browser and Any Browser Private Apps share the same domain.
Different authentication cookies/tokens can cause errors instead of SSO prompts when users switch app types on the same hostname.
Mitigate the issue by separating hostnames or flows (via DNS/topology or browser separation) to avoid cookie collisions.

What you might see

A typical scenario:

The user signs in to a Private App via Enterprise Browser at https://private.example.com.

Later, the same user visits https://internal-app.example.com (an Any Browser Private App) in Enterprise Browser.

Instead of an SSO prompt, the user sees an error page and cannot access the app.

The reverse order (Any-Browser first, then Enterprise Browser) can cause similar behavior.

Why this happens (high level)

Enterprise Browser and Any Browser Private Apps use different authentication cookies/tokens.

When they share the same hostname, the browser may send a cookie that is valid only for one app type.

Netskope cannot match the request to the correct policy and does not start a new SSO flow.

As a result, users see an error page instead of a sign-in prompt.

When you are likely to run into this

You are more likely to see this behavior if:

You reuse the same domain or custom hostname (for example, https://private.example.com) for both Enterprise Browser and Any Browser Private Apps.

You migrated users from Any Browser to Enterprise Browser but kept the same hostname.

You use the same hostname for different network locations (for example, on-premises vs. remote) relying on DNS or topology, and both flows can occur on that hostname.

Summary

This behavior can occur when Enterprise Browser and Any Browser Private Apps share the same domain.

Different authentication cookies/tokens can cause errors instead of SSO prompts when users switch app types on the same hostname.

Mitigate the issue by separating hostnames or flows (via DNS/topology or browser separation) to avoid cookie collisions.