An access action determines whether a matching user can connect to a private application. Configure the action after selecting the Source and Destination criteria in the policy editor. NPA does not allow private app traffic by default.
Access Actions
| Action | Result | Requirements |
|---|---|---|
| Allow | Permits access when the policy criteria match. | A configured private app segment and the appropriate source criteria. |
| Block | Denies matching access. | Select the required user notification template. |
| Periodic Authentication | Requires authentication for new application sessions after the configured interval expires. | Client access on Windows or macOS and the authentication prerequisites described in the dedicated procedure. |
For authentication configuration and timer behavior, see Configure Per-App Periodic Authentication.
Configure an Access Action
- Go to Policies > Real-time Protection and create or edit a Private App Segment Access policy. Some releases label this option Private App Access.
- Select the required users, groups, or organizational units and access method.
- Add any network, country, device, or User Confidence conditions required for the application.
- Select the private app segments or supported segment tags.
- In Profile & Action, select the required access action.
- For Block, select the notification template. For Periodic Authentication, configure the supported OS criteria, interval, and authentication notification as described in the dedicated procedure.
- Enter the policy name, select its group, verify that it is enabled, and click Save.
- Review the policy order and click Apply Changes.
For the complete workflow and schedule restrictions, see Private App Segment Policy Management.
Allow
Select Allow to grant access when the policy’s source and destination conditions match. Limit the rule to the intended users and applications. Review broader allow policies when introducing restrictive country, device, or UCI conditions so that another rule does not grant unintended access.
An allow policy grants application access. Inspection requires the appropriate DLP or Threat Protection policy and entitlement.
Block
Select Block to deny matching access and select the required notification template. An explicit block policy can inform users why access is denied; the default absence of an allow policy does not provide the same configured notification.
For block policies, the notification is shown on the first attempt rather than on every attempt. Creating a new policy or reconnecting the Client causes the notification to appear again. This restriction does not apply to periodic-authentication notifications. See End-User Notifications.
Periodic Authentication
Select Periodic Authentication for supported Client access on Windows or macOS. Configure the OS criteria before selecting the action. New sessions require authentication after the interval expires; an existing application session is not terminated solely because that interval expires.
Follow Configure Per-App Periodic Authentication for the Client requirement, identity-provider prerequisites, interval configuration, and timer example.
Access Actions and Inspection
Beginning in R142, DLP and Threat Protection policies perform inspection only. Configure a separate matching access policy for the protected private application. Before R142, place the inspection policy above the access policy. See Access and Inspection in R142.
User Confidence is a source condition, not an additional access action. The condition determines whether the rule matches; Allow or Block determines the access result.
Validate the Action
- Test an included user and an excluded user against the same application.
- Test matching and nonmatching source conditions, and check other applicable policies when the outcome is unexpected.
- For Block, verify the first-attempt notification and the selected template.
- For Periodic Authentication, test a new session before and after the configured interval.
- Review the policy status, ordering, and whether changes were applied.