Use User Confidence Index (UCI) scores in a Private App Access policy to control access according to user risk. UCI is a user score provided by Netskope Advanced UEBA. Lower scores indicate greater risk.
For example, allow a pilot group to access a sensitive private application only when its users have a UCI score greater than 650. Users must also satisfy the policy’s other source and destination conditions.
Prerequisites
Before configuring a UCI policy:
- Have Netskope Private Access and an active Advanced UEBA license.
- Have the User Confidence for Private App Access beta enabled for the tenant.
- Confirm with your Netskope account team that the participating devices meet the Client version and platform requirements for the beta.
- Configure the private app segment, Publisher, user access, and traffic steering needed for the pilot.
- Verify that Advanced UEBA provides UCI information for the intended test identities.
- Confirm eligibility with your account team if the pilot uses Local Broker, China connectivity, or Saudi Arabia infrastructure.
Select a Confidence Threshold
For supported comparisons, threshold values, and missing-score behavior, see User Confidence in Source Policy Criteria. The following pilot uses More Than with 650 (Good rating) and an Allow action.
Create 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.
- In Source, select the pilot users or user group.
- Set Access Method to Client.
- Click Add Criteria > User Confidence.
- Select the comparison and confidence threshold. For the example in this article, select More Than, then 650 (Good rating).
- Add any other required source criteria, such as an operating system or device classification.
- In Destination, select Private App Segment, and select the application or applications to protect.
- In Profile & Action, select Allow for the example policy.
- Enter a descriptive policy name, such as Finance App – UCI Above 650, select a policy group, and verify that the policy is enabled.
- Click Save.
- Review other policies that can grant the same users access to the same applications. Remove or narrow any unintended alternate allow path as part of your planned policy change.
- Click Apply Changes.
If User Confidence is unavailable or disabled, check that Client is the only selected access method and ask your Netskope account team to verify the tenant’s entitlement and beta enablement.
Example: Restrict Access to a Sensitive Application
The following example grants access only when the user meets the confidence threshold and the other policy conditions.
| Setting | Example value |
|---|---|
| User | Finance pilot group |
| Access Method | Client |
| User Confidence | More Than: 650 (Good rating) |
| Private App Segment | Finance application |
| Action | Allow |

Assuming no other applicable policy grants access:
| Test user’s UCI | Expected result |
|---|---|
| 800 | The UCI condition matches. Access is allowed if the remaining conditions match. |
| 650 | The UCI condition does not match. Access is not granted by this policy. |
| 300 | The UCI condition does not match. Access is not granted by this policy. |
If you use a separate low-confidence block policy, place it appropriately relative to other applicable access policies and test both sides of the threshold. Avoid using a broad allow policy that defeats the intended restriction.
Validate the Policy
- Record the pilot user’s identity and UCI score in Advanced UEBA.
- Access the selected private application through the Netskope Client. Verify the result against the threshold and the user’s other policy conditions.
- With your account team’s assistance, test a user whose score falls on the opposite side of the threshold. Do not introduce malicious files or unsafe activity to change the score.
- Allow time for score propagation and policy refresh before retesting. Record the score, access result, and test time.
- Test score recovery and confirm that the expected access returns after the updated score is evaluated.
- Review the applicable network events and alerts. Use Advanced UEBA to verify the score; this beta does not add a new UCI field to NPA network events.
Feature Behavior and Limitations
- A UCI score change is evaluated through policy refresh. The beta does not provide an immediate policy refresh solely because a score changes.
- UCI-based access criteria do not configure risk-triggered MFA or reauthentication. Per-app periodic authentication is a separate control.
- A missing UCI record uses the default score described in Source Policy Criteria. Treat missing score information as a validation issue rather than proof that a user is low risk.
- Review the policy set before removing UCI conditions or having the beta disabled. Removing a condition can broaden the access granted by the remaining policy.
Troubleshoot Unexpected Results
| Symptom | Check |
|---|---|
| User Confidence is disabled in the editor. | Confirm Client-only access, Advanced UEBA entitlement, and beta enablement with your account team. |
| A user below the threshold can still connect. | Check the user identity, score freshness, other allow policies, and overlapping private app segments. |
| A user above the threshold cannot connect. | Check other source conditions, policy status and order, steering, Publisher connectivity, and whether changes were applied. |
| Access has not changed after a score update. | Allow for score propagation and policy refresh. Record timestamps and contact your account team if the result remains unexpected. |

