Denied access to the apps, by default

To enable zero-trust-based access to the apps, apps are denied access, by default. Access to the apps is enabled only if an access policy is associated with the application.

  • Access to published apps:
    • When an end user accesses an FQDN associated with a published app, the access is allowed only if an access policy is configured explicitly with the action Allow access.


      If there are multiple apps that match the app FQDN, the policies of the matching apps are evaluated based on the policy priority.

    • If an access policy does not match with the published app or if an app isn’t associated with an access policy, then access to the app is denied, by default.

      For details on access policies, see Access policies.

  • Access to unpublished or internal apps. Access to the unpublished or internal apps is enabled based on the routing type defined while configuring the app.

    • If the routing type is defined as External, then the traffic flows directly to the internet. The access is enabled for such applications.
    • If the routing type is defined as Internal or External via Connector, then access is denied for such applications.
    • If the routing type isn’t defined for an unpublished FQDN, then the app is considered as external. Access to such apps is based on the rules configured for unsanctioned apps, if enabled. For details, see Configure rules for unsanctioned websites.

    The routing type is defined in the Secure Private Access user interface. Click Settings > Application Domain. For details, see Route tables.

Conflicting configuration that might result in app access issues

If multiple apps are configured with the same FQDN or some variation of the wildcard FQDN, then you might encounter the following issues.

  • The websites stop loading or might display a blank page.
  • The “Blocked Access” page might appear when you access a URL.
  • The login page might not load.


To address the preceding issues, we recommend the following:

  1. Configure all common FQDNs and their related domains in a single app.

    For example, if you have a few apps that use Azure AD as an IdP and you need to configure and other related domains (*, then create a single common app with as the FQDN and * and * as the related domains.

    If the common app is to be hidden in Citrix Workspace app, then select the Do not display application icon to users option while configuring the app. For details, see Configure a web app.

  2. Create an access policy for the common app and enable access to all users. For details, see Configure an access policy.
  3. Verify the diagnostic logs to confirm if the FQDN matches the app and if the policy is enforced as expected.
Denied access to the apps, by default