Cisco Secure Access Help

Traffic Steering for Zero Trust Access Client-Based Connections

Updated: September 15, 2026

Want to summarize with AI?

Describes Traffic Steering for Zero Trust Access Client-Based Connections in Cisco Secure Access. DNS Steering selectively directs matching DNS requests based on configured domains to a customer-defined private resolution path where you can resolve matching queries by using one or more specified internal DNS servers.

DNS Steering selectively directs matching DNS requests based on configured domains to a customer-defined private resolution path where you can resolve matching queries by using one or more specified internal DNS servers.

Note

Successful application connectivity still depends on follow-up hostname resolution, policy coverage, and reachability of the returned endpoints through the intended ZTA path. DNS Steering affects how queries are routed, not the DNS records themselves or their authoritative source.

We strongly encourage you to utilize DNS Steering when an applications depends on DNS records to resolve interal services like the following:

When the client must discover a service endpoint before connecting.
When the service records exist only in internal DNS.
When DNS responses return target hostnames that require additional A, AAAA, or CNAME lookups and subsequent connections.
When the same user population is already using ZTA and you want to reduce VPN dependence for discovery-based workflows.

In Cisco Secure Access, Zero Trust traffic steering rules apply only for Client-based Zero Trust Access (ZTA) connections to internal destinations that are configured as private resources. When you configure a Private Resource, Secure Access automatically adds an entry for each configured resource address for Client-based ZTA to the Zero Trust Traffic Steering page, in order to direct end-user traffic to the resource.

View the traffic steering rules, but in most cases you should not edit the rules on the End User Connectivity > Zero Trust page. For more information, see Best Practices.

Use Cases for DNS Steering

If you edit entries that were automatically added to this page when you configured a Private Resource, the traffic steering rules for the resource are not updated when you make future edits to the Private Resource configuration page.

If you change the destination address on the Zero Trust Traffic Steering page, the original Private Resource will not have a traffic steering rule and Client-based ZTA connections to that resource will not occur even if configured in the resource.

AD Controller Discovery

Discover an appropriate domain controller over ZTA without requiring a full VPN connection solely for private DNS resolution. The client sends the service discovery request to the private resolution path, receives domain controller hostnames from internal DNS, and then proceeds with normal identity traffic to the returned hosts.

There may be other enterprise applications that rely on internal discovery records can find the correct service endpoint without requiring users to know the final hostname in advance. Internal discovery records are resolved through the intended private DNS path, allowing the application to continue with its normal connection logic after discovery completes.

Kerberos Dependent Authentication

dentity workflows that depend on Kerberos service discovery while working remotely through ZTA after sign-in. DNS steering preserves that discovery path for supported post-login workflows prior to authentication.

LDAP Directory Lookups

Enterprise applications that use LDAP often rely on DNS service records to locate directory services without hardcoding individual server names. By locating the internal DNS and then connecting to the returned directory server, you can steer the relevant discovery namespace allows this pattern to work over ZTA.

Best Practices

We recommend the following as best practices and further explanations on how to configure a Zero Trust Access profile.

Private Resources in ZTA

In general, you should not add destinations directly to the Zero Trust traffic steering page. Instead, add a Private Resource. For more information, see Add a Private Resource.

The private resource address to edit must be configured as a wildcard fully-qualified domain name (FQDN).
You should not edit entries on the zero-trust traffic steering page, except for the following purpose:

Edit entries on the Zero Trust traffic steering page if you have configured the access address for a Private Resource as a wildcard FQDN of the format *.example.com and you want to exclude specified subdomains from Client-based ZTA. For example, you might want to exclude your company's public URL, www.example.com, from Zero Trust Access.

For instructions, see Using Wildcards to Configure Traffic Steering for Private Destinations.

Pause ZTA with Cisco Secure Client

You can configure a ZTA profile to either permenantly or temporarily pause ZTA enforcement and still utlize the traffic steering configured for a specific profile with the Enable Cisco Secure Client end user pause function. This allows you to independently configure pause settings for both secure internet access and secure private access; each of these options are available when editing or creating a ZTA profile. This allows you to investigate access concerns more effectively and allows you to control when and how the ZTA enforcement is active or not.

Note
You can enable the pause functionality for both Secure Private Access and Secure Internet Access indepently of each other; both of these configruable settings are available in their repsective steps when editing or creating a profile.

Once enabled in the profile and added to the access policy you can monitor and confirmed the enrolled or un-enrolled state of the pause function from the Cisco Secure Client application on your desktop.

Based on the different combinations of configurations available between pausing ZTA and enabling, or not enabling, Secure Internet Access within your profile then the messaging in your Client window may differ depending on the configuration you created. To view the specifics of the profile being enforced, open the Secure Client window on your desktop and click the connection icon for the Zero Trust Access module to view the advanced settings.

Screenshot of the Cisco Secure Client's Zero Trust Access tab with both Secure Private Access and Secure Internet Access enabled.

If traffic is paused by Trusted Network Detection, this action overrides the Enable Cisco Secure Client end user pause setting in your ZTA profile.

Note
If you update the Client version or restart the agent application on your laptop, the Pause function restarts as well.

Limits: Zero Trust Traffic Steering Rules

Secure Access allows a maximum number of Zero Trust traffic steering rules. For more information, see Limitations and Range Limits.

Note
Custom Zero Trust Access profiles created with the process described below contain traffic steering configurations that only impact the users or groups of users included in the custom profile and its impact on processing traffic is dependent on its priority amongst other profiles.

Windows or macOS

For Zero Trust connectivity on Windows or macOS, Secure Access recommends at most 25K traffic steering rules for the organization.

The organization can reduce the number of Zero Trust steering rules by using wildcards. For more information, see Using Wildcards to Configure Traffic Steering for Private Destinations.

If the organization has 100K Zero Trust traffic steering rules, Secure Access displays a notification.

iOS

For Zero Trust connectivity on iOS, Secure Access recommends at most 1K traffic steering rules for the organization.

If the organization has 5K Zero Trust steering rules, Secure Access displays a notification.

Android: Samsung, Chrome and Generic

For Zero Trust connectivity on Android, Secure Access recommends at most 1K traffic steering rules for the organization.

If the organization has 10K Zero Trust steering rules, Secure Access displays a notification and prevents the addition of more traffic steering rules.

Manage the DNS Steering Rule in a Zero Trust Access Profile

DNS Steering is derived from destination lists and steering rules that determine where DNS queries are sent. These destinations can be private or public DNS servers or specific IP addresses or domain names that the DNS queries should be directed to. The steering destination is the endpoint for these DNS queries dictated by the steering policy. This is particularly useful in scenarios configured for secure private access where or private DNS resolution over ZTA and allows for the secure handling of private DNS resolution over Zero Trust Access (ZTA) by using established resolution paths such as internal DNS servers and RCGs. It supports all DNS record types, with particular emphasis on the common use case of SRV and discovery records.

You must create a DNS Steering Destination and then attach the destination to a ZTA profile; you cannot add or created a destination within the ZTA profile procedure. This enables effective control and monitoring of DNS-based traffic flows within the network environment. How these rules are configured affect the action made against traffic based on what traffic matches the rule and how the rules within the profile are ordered.

Note
Wildcard matching in DNS traffic steering destinations does not include exact-domain matching; it can represent only one token and cannot represent multiple tokens. When you add a domain like google.com to an allow list, it implicitly allows all subdomains like *.google.com, but if you want to block only a specific subdomain such as news.google.com, you must add the entire FQDN.

Use the following procedure to add, edit, or delete a DNS destination in the DNS settings tab of the ZTA profile.

Before you begin

Beware of the following requirements or limitations:

You must run Secure Client version 5.1.16 or newer to utilize this function. Check the About icon inside your Cisco Secure Client module to view the Secure Client UI verison.
You must have the complete FQDN of the DNS destination set ready prior to creating a rule. This includes domain name, DNS Server 1 IP address, and an optional DNS Server 2 for failover purposes. If you opt to use a Resource Connector Group (RCG), enter that information in place of the the domain servers.
By adding a DNS destination and attaching it to a ZTA profile, the profile intercepts all DNS types that match the value you enter. If matching values are intercepted, the associated traffic is forwarded to the designated proxy.

Procedure

Navigate to Connect > End User Connectivity.
In the Zero Trust Access tab of the window, click ZTA Settings.
In the ZTA Settings page, switch to the DNS Steering tab and click + DNS Steering Destination to add a new destination.

Note

To edit an existing DNS steering destination, click the edit icon for the destination you want to edit.

To delete an existing DNS steering destination, click the delete icon for the destination. This completely removes the destination as a configurable destination from your organization.
Manually enter the domain you want as the Destination. This field specifies the FQDN that DNS queries are directed to.
Select one of the following options as your Resolution Path:
- DNS Server: This option is ideal if you want to confirm the earliest possible checkpoint in a connection event without compromising aspects of your device that might not support ZTA or cannot guarantee security, such as laptop cameras or legacy systems. Expand the drop-down menu to select a DNS Server. If there are none available, click + Add to add one. You must provide a domain name, DNS Server 1 IP address, and an optional DNS Server 2 for failover purposes.
- Resource Connection groups: This option is preferable for secure, high-performance access to private applications with built in high availability, load balancing across multiple connectors, and a simplified network configuration. Expand the drop-down menu and select one of the connector groups available. To remove a connector group from the list once you've added one, simply click the remove icon next to the connector name.
Note

Resource connectors do not support some special characters such as "_"; we strongly recommend using an established DNS Server as the resolution path in your end target includes the special character.
(Optional) Assign the destination to a ZTA profile. Expand the ZTA Profiles drop-down menu and select a pre-existing profile.
Click Save.

What to do next

If you opt to not attach the DNS Steering Destination to a ZTA profile in step 7 of this procedure, create you ZTA profile and attach the steering destination. For more information see Add a Zero Trust Access Profile.

If you are implementing Kerberos authentication wit Active Directory (AD), we strongly recommend adding the AD DNS SRV recorcd names to the DNS Steering you just created. For more information from Microsoft, see How to verify that SRV DNS records have been created for a domain controller for more information. Microsoft documents specific SRV DNS records for you, see 6.3.2.3 SRV Records sepcifically for more information.

Add a Zero Trust Access Profile

Zero Trust Access profiles provides distinct access experiences for different users and groups. You can view, edit, and delete the profiles for private and internet access.

Wildcard matching in ZTA profiles does not include exact-domain matchinng; it can represent only one token and cannot represent multiple tokens. When you add a domain like google.com to an allow list, it implicitly allows all subdomains like *.google.com, but if you want to block only a specific subdomain such as news.google.com, you must add the entire FQDN as your DNS steering destination.

Be aware of the ZTA limitations when creating a profile. See Limitations and Range Limits for more information. You must be a Full Admin to proceed with this procedure. See Manage Accounts for more information.

Zero Trust Access profiles are an ordered list where the order of profiles determines their priority. The last profile in the list is always the Default ZTA Profile. A user’s Zero Trust Access client receives settings from the first matching Zero Trust Access profile in profile order. The profile must match both the user’s membership and the endpoint operating system. Default profile includes all users in the org and all client Zero Trust Access enabled private and internet resources. Use the following procedure to modify the user's access:

Procedure

Navigate to Connect > End User Connectivity.
Click the Zero Trust tab.
To create a new profile, click + ZTA profile.
Enter a unique ZTA profile name and select the rule priority that this profile will execute in. Note that this profile may not get triggered with incoming traffic if a rule with a higher priority is executed.
In the Sources section, configure both endpoint and user matching criteria:
- Operating Systems – Select the endpoint operating systems that this Zero Trust Access profile applies to.
  
  Note
  To use specific operating systems in combination with DNS Steering and Use ZTA to secure all internet destinations , the user must run Cisco Secure Client 5.1.18 or later. For older clients, you must select all operating systems or remove these steering options.
- Users & Groups – Click +Users and groups to add the users or groups that this Zero Trust Access profile applies to.
Click Next.
In the Secure Private Access window, click through the following tabs:
- Traffic Steering – Click +Destinations to map in a destination for your rule. You can opt to add either a Destination or a Private Resource; you can also upload or download a CSV file to managed your exclusions. You must create the DNS destination outside of this ZTA profile. See Manage the DNS Steering Rule in a Zero Trust Access Profile for more information. There is no character-limit for destinations manually entered.
  
  Note
  Destinations in Zero Trust Access profiles are specifically used for traffic steering. For end user connectivity and access policy enforcement, use a corresponding private resource. You must create a private resource before you can add it to a Zero Trust Access profile. See Add a Private Resourcefor more information.
- DNS Steering – Click +DNS Steering Destination to map in a destination for your DNS trafficrule. Select the destination from the drop-down list and then click Save.
- Options – Configure whether the profile pauses ZTA enforcement and the network mode for traffic steering.
  - Check the Enable Cisco Secure Client end user pause action to pause Secure Private Access enforcement. You can check the type of enrollment you have in the Cisco Secure Client window. See Pause ZTA with Cisco Secure Client for more information. If you opt to enable this feature, choose between one of the following modes:
    - Pause indefinitely - Forever pause Cisco Secure Client from enforcing private access of the ZTA profile.
    - Pause a time period - Temporarily pause Cisco Secure Client from enforcing private access of the ZTA profile. The default value is fifteen minutes. Select the desired time period and click OK to save.
  - Trusted network mode - Select either don't use trusted networks to secure internet destinations or Use trusted networks to secure internet destinations; this impacts how traffic is authenticated and steered to private destinations for this particular ZTA profile. The steering in this configuration does not affect or impact other profile configuration.
    
    To use trusted networks, click + Trusted Network, select the required trusted networkfrom the drop-down list, and then click Save.
Click Next.
In the Secure Internet Access section, click through the following tabs and configure your traffic steering and pause settings for Secure Internet Access:
- Traffic Steering- select one of the following traffic steering modes you want Zero Trust Access to implement
  - Don’t Use ZTA to secure internet destinations – Zero Trust does not intercept or examine any traffic with an internet destination.
  - Use ZTA to secure all internet destinations – Zero Trust Access intercepts all traffic with an internet destination for examination.
  - Use ZTA to secure specific internet destinations – Zero Trust Access only intercepts traffic for certain internet destination, as specified with an exception.
  - Exception – Click + Exception to include an IP address or IP address range that isexempted from the traffic steering method if you use ZTA. ◦
- Options – Check the Enable Cisco Secure Client end user pause action to pause Secure Private Access enforcement. This is independent of the pause setting for Secure Internet Access. If you opt to enable this feature, choose between one of the following modes:
  - Pause indefinitely – Forever pause Cisco Secure Client from enforcing private access of the ZTA profile.
  - Pause a time period – Temporarily pause Cisco Secure Client from enforcing private access of the ZTA profile. The default value is fifteen minutes. Select the desired time period and click OK to save.
- Trusted network mode – Select either don't use trusted networks to secure internet destinations or Use trusted networks to secure internet destinations; this impacts how traffic is authenticated and steered to private destinations for this particular ZTA profile. The steering in this configuration does not affect or impact other profile configuration.
  
  To use trusted networks, click + Trusted Network, select the required trusted networkfrom the drop-down list, and then click Save.
Click Close.
Optionally, if you want to delete an existing profile, navigate to a traffic steering rule, click the ellipsis ... at the end of the table row, and then choose Delete.

Edit a Zero Trust Traffic Rule

You can edit a destination associated with the Zero Trust traffic rule. For more information, see Best Practices.

Procedure

Navigate to Connect > End User Connectivity.
Click the Zero Trust tab, and then navigate to Traffic Steering.
Navigate to a traffic steering rule, click the ellipsis (...) at the end of the table row, and then choose Edit.
For Edit Destination, enter a fully-qualified domain name (FQDN), IP address, or CIDR block for the Zero Trust traffic steering rule.
Click Save.

Delete a Zero Trust Traffic Rule

You can remove a destination associated with the Zero Trust traffic rule.

Procedure

Navigate to Connect > End User Connectivity.
Click on the Zero Trust tab, and then navigate to Traffic Steering.
Navigate to a traffic steering rule, click the ellipsis (...) at the end of the table row, and then choose Delete.
Click Delete steering to confirm the removal of the Zero Trust traffic steering rule.

Enable Client-Based Zero Trust Access to Destinations

Use the following procedure to enable and allow client-based Zero Trust Access to both internet and SaaS destinations:

Procedure

Ensure that each destination site allows access from the egress IP addresses that your users' connections will use, as discussed in the Web Traffic and NATaaS section of Secure Access NAT as a Service.
Add the applicable destinations to one or more destination lists. See Manage Destination Lists and subtopics. URLs are treated as domains. Do not include addresses that are not publicly routable.
Install the latest version of Cisco Secure Client on user endpoint devices. Ensure that the client is enrolled in Zero Trust Access. See the applicable subtopics under Get Started with Cisco Secure Client on Windows, macOS, and Linux Devices. Windows, macOS, iOS, and Android clients support this feature.
Navigate to Connect > End User Connectivity > Zero Trust Access. In the Default Profile section, click the Edit icon for the Default ZTA Profile. Go to the Internet and SaaS Destinations page of the wizard, and select one or more destination lists. Optionally, add any exceptions.
Define internet access rules for the destinations. You can specify the same destination lists that are specified in the ZTA profile.

What to do next

Keep the following points in mind:

URLs in destination lists are treated as domains for traffic steering purposes.
When you configure the traffic steering profile, you can specify destinations on the list that you do not want to be handled using Zero Trust Access. For example, if the destination list includes *.example.com, and you want to exclude ExcludedDestination.example.com, add that exclusion to the traffic steering rule.

Enter destinations to exclude as a comma-separated list.
Removing a destination list from a Zero Trust Access profile does NOT remove the destination list from Secure Access.
Future deletions, changes, additions to selected destination lists will affect Zero Trust Access traffic steering to those destinations.
User authentication interval settings configured on the rule defaults page for access rules do NOT apply to internet traffic.
An FQDN-based steering rule can be configured to bypass Zero Trust Access proxy to a remote access VPN. CIDR block IPs and NetWitness IP ranges are supported.

Using Wildcards to Configure Traffic Steering for Private Destinations

For more granular control over zero trust access to private resources and to reduce the number of individual private destinations for both ZTA profiles and DNS steering destinations, consider using wildcards to configure these destinations.

Wildcard matching does not include exact-domain matchinng; it can represent only one token and cannot represent multiple tokens. When you add a domain like google.com to an allow list, it implicitly allows all subdomains like *.google.com, but if you want to block only a specific subdomain such as news.google.com, you must add the entire FQDN.

Important note about editing traffic steering entries:
When you configure a Private Resource, Secure Access automatically adds an entry for each configured resource address for client-based zero-trust access to the Traffic Steering page, in order to direct end-user traffic to the resource.

If you edit entries that were automatically added to the Zero Trust Traffic Steering page when you configured a Private Resource, the traffic steering rules for the resource are NOT updated when you make future edits to the Private Resource configuration page.

Exception

If you have deployed the zero trust client on iOS devices, see unique matching information in the "Guidelines and Limitations" section of the Set up the Zero Trust Access App for iOS Devices.

Procedure for Configuring Traffic Steering for Private Destinations Using Wildcards

To exclude traffic from a configured Private Resource address:

Before you begin

Full Admin user role. For more information, see Manage Accounts.
Before using this procedure, see important caveats at Traffic Steering for Zero Trust Client-Based Connections.
The private resource address to edit must be configured as a wildcard FQDN.

Procedure

Navigate to Connect > End User Connectivity .
Click on the Zero Trust tab.
For the resource to modify, click the ellipsis (...) button at the end of the table row and choose Edit.
Provide subdomains to exclude from traffic steering for Zero Trust connections. For example, if your domain is *.example.com, and you want to exclude traffic to hr.example.com and boo.finance.example.com, enter hr as an exclusion, then click Add and enter boo.finance.

Note
You can enable access to subdomains when you enter a parent FQDN. For example, you configure ccc.com. You can gain access to subdomains such as aaa.ccc.com and bbb.ccc.com.
Click Save.

Addresses That Never Use Zero Trust Access

Traffic to destinations on this page will never be handled using Zero Trust Access. These addresses are in addition to any system-provided exceptions and exclusions that appear in a ZTA Profile, and they cannot be modified or removed.

IPv6

::1/128 Loopback Address [RFC4291]

::/128 Unspecified Address [RFC4291]

64:ff9b::/96 IPv4-IPv6 Translat. [RFC6052]

64:ff9b:1::/48 IPv4-IPv6 Translat. [RFC8215]

100::/64 Discard-Only Address Block [RFC6666]

2001::/23 IETF Protocol Assignments [RFC2928]

2001::/32 TEREDO [RFC4380] [RFC8190]

2001:1::1/128 Port Control Protocol Anycast [RFC7723]

2001:1::2/128 Traversal Using Relays around NAT Anycast [RFC8155]

2001:1::3/128 DNS-SD Service Registration Protocol Anycast [RFC-ietf-dnssd-srp-25]

2001:2::/48 Benchmarking [RFC5180][RFC Errata 1752]

2001:3::/32 AMT [RFC7450]

2001:4:112::/48 AS112-v6 [RFC7535]

2001:10::/28 Deprecated (previously ORCHID) [RFC4843]

2001:20::/28 ORCHIDv2 [RFC7343]

2001:30::/28 Drone Remote ID Protocol Entity Tags (DETs) Prefix [RFC9374]

2001:db8::/32 Documentation [RFC3849]

2002::/16 [3] 6to4 [RFC3056]

2620:4f:8000::/48 Direct Delegation AS112 Service [RFC7534]

3fff::/20 Documentation [RFC9637]

5f00::/16 Segment Routing (SRv6) SIDs [RFC9602]

fc00::/7 Unique-Local [RFC4193] [RFC8190]

fe80::/10 Link-Local Unicast [RFC4291]

ff00::/8 Multicast Address Block

IPv4

127.0.0.0/8 Loopback Address Block

169.254.0.0/16 Link-local Address Block

224.0.0.0/4 Multicast Address Block

255.255.255.255 Broadcast Address

7.128.0.0/9 Synthetic range

Zero Trust Access to Internet Destinations

Some internet destinations outside your organization's network, such as YourCompany.OtherCompany.com, allow access only to traffic that originates from IP addresses that are within your organization's IP address space. Users who are in the office or using VPN will have the required IP address. Remote users who are not using VPN, including those using mobile devices, would not have access to the internet resource.

To allow these users to access the resource, use the solution described on this page to ensure that the egress IP address associated with their devices is within your organization's IP address space.

This solution also provides the ability to source traffic from local regions that do not currently have a Secure Access data center.

The solution on this page can be used only for individual SaaS applications that match the description above. It cannot be used for zero trust access to internet destinations in general, such as those defined by content category.

Note

Mobile platforms currently do not support secure internet access steering that uses "all" as a wildcard for internet destinations.

Zero Trust Access to Internet Destinations Overview

Install the Cisco Secure Client, including the Zero Trust Access module if applicable for the device, on managed devices, including mobile devices. Enroll each device in Zero Trust Access.

For details, see Zero Trust Access links in Get Started with Cisco Secure Client on Windows, macOS, and Linux Devices.
Configure a resource connector group and connectors in the region near the location from which the internet destination is hosted. For details, see Manage Resource Connectors and Connector Groups.
- Ensure that you have deployed enough connectors to handle potential capacity.
Configure a private resource:

Tip
Configure a private resource with the address of an actual private resource, ensure that all other requirements on this page are met, then test. After you verify that your configuration works as expected for the internal resource, change the Internally reachable address in the Private Resource configuration to the internet address and test again.
- The following settings are required:
  - Specify the specific internet destination in the Internally reachable address field.
  - Enable client-based zero trust access connections.
  - Do not enable decryption.
  - Associate the resource with a resource connector group.
    
    Network tunnels will not work for this purpose.
- For details, see Add a Private Resource.
Configure client-based endpoint requirements.

For details, see Add a Client-Based Zero Trust Access Posture Profile.
Ensure that all requirements are met for connecting traffic to a private resource using client-based Zero Trust Access and resource connectors.

For example, see Requirements for Zero Trust Access.
Network authentication requirements apply to this traffic. See Network Authentication for Zero Trust Access.
Create a private access rule (NOT an internet access rule) and choose the private resource, configured above with the internet address, as a destination. For details, see Add a Private Access Rule.

Note
Intrusion prevention (IPS) may not be fully effective because decryption is disabled.
Ensure that your network (such as routes, ACLs, and NAT requirements) allows this traffic to be routed to the internet. (This step is performed outside of Cisco Secure Access.)
Ensure that the destination site allows access from the egress IP addresses that your users' connections will use, as discussed in the Web Traffic and NATaaS section of Secure Access NAT as a Service.

Trusted Networks for Zero Trust Access Connections

A trusted network is one that is secure, reliable, and well-protected against unauthorized access, data breaches, and other cyber threats. Trusted networks are typically present within your larger corporate network, or in a trusted partner's network that has all the necessary security measures in place. Trusted Network Detection (TND) enables the recognition of a predefined trusted network. When connected to a trusted network, Secure Access can bypass ZTA enforcement, and start ZTA enforcement when the user is outside the trusted network (corporate network).

Secure Access allows you to define trusted networks using a set of criteria that Cisco Secure Client uses to detect whether an endpoint device is connected to a defined trusted network and route the user's traffic as intended. For instance, if certain destinations are configured to use Zero Trust Access, you can disable them for in-office users and utilize on-network security mechanisms. Trusted networks are used in universal Zero Trust Network Access configuration where the threat defense devices can enforce rules for the private resources associated with them, based on the assigned trusted network.

Caution: When using Secure Access to define a network as trusted, exercise extreme care in your selection. If you designate a network as trusted without thoroughly verifying that all required security and connectivity mechanisms are in place, you risk leaving user data unprotected and vulnerable to potential threats. Failure to choose a properly secured network can compromise the safety and confidentiality of sensitive information.

Add a Trusted Network

Add a trusted network for Zero Trust end-user connectivity.

Before you begin

Zero Trust Access profiles provides distinct access experiences for different users and groups. You can view, edit, and delete the profiles for private and internet access.

For users implementing Kerberos authentication with AD, we recommend reviewing the appropriate Microsoft documentation about configuring the correct ports and private resources to plan for for AD communication. to understand how to optimize the location of a domain controller, see this documentation.

Be aware of the ZTA limitations when creating a profile. See Limitations and Range Limits for more information. You must be a Full Admin to proceed with this procedure. See Manage Accounts for more information.

Procedure

Navigate to Connect > End User Connectivity > Zero Trust Access.
Click Manage Trusted Networks and then click +Trusted Network.
For Trusted Network Name, enter a name for the trusted network.
For Inspect, choose Physical adapters or Physical and virtual adapters.
- Physical adapters—The Trusted Network Domain (TND) inspects only physical network interfaces in an endpoint.
- Physical and virtual adapters—The Trusted Network Domain (TND) inspects both physical and virtual network interfaces in an endpoint.
Note
The Physical and virtual adapters option is a beta feature intended for limited testing and not for production environments.
Navigate to Criterion and then choose your criterion.
1. Choose DNS Servers.
  
  If you choose this option, enter all the DNS server addresses (comma separated) for the trusted network in the adjacent DNS Servers field. Cisco Secure Client detects a trusted network only if it matches any of the specified DNS servers.
  
  Add up to a maximum of 100 DNS servers.
2. Choose DNS Domains and then enter the list of comma-separated DNS domain suffixes for the trusted network.
  
  Cisco Secure Client detects a trusted network only if it matches any of the specified DNS domain suffixes.
  
  You can add up to 100 DNS domains.
3. Choose Trusted Servers and then for Trusted Servers enter a trusted server address. (Optional) For Certificate Hash field, enter the hash of the public key of this certificate.
  
  A DNS server specified must translate the domain name of this server to its corresponding IP address and provide a TLS certificate.
  
  You can add up to 10 Trusted Servers. Only one of the trusted servers is required to pass validation.
  
  Note
  The Certificate Hash option is not applicable for iOS devices.
(Optional) Click +Add Criterion to add more criteria.

Note
You can add a criteria only once.
Click Save.

Manage Threat Defense Devices for Universal Zero Trust Network Access

A Cisco Secure Firewall Threat Defense device can act as an on-premises proxy to Secure Access cloud for private resource access traffic. To utilize universal Zero Trust Network Access (ZTNA), Threat Defense devices are configured in Secure Access as on-premises proxies. This enables you to manage the connections that allow user traffic to reach private resources in your network efficiently without compromising on security. This improves end-user experience and ensures consistent security controls for users, independent of where they are connected from.

Threat Defense devices that are enabled for universal ZTNA in Security Cloud Control, become available in Secure Access for further configuration. To know more about the configuration of Threat Defense devices for universal ZTNA, refer to Universal Zero Trust Network Access Configuration Guide.

Once the Threat Defense devices are available in Secure Access, you can perform the following tasks:

The following workflow displays the tasks to be performed in Secure Access to configure universal ZTNA.

The Uztna Workflow Overview Chart interface.

View Threat Defense devices configured for Universal Zero Trust Network Access

Once the Threat Defense devices are available in Secure Access, you can view the configuration attributes of these devices. You can also edit the attributes of a Threat Defense device and view information about the private resources, trusted network, and policies associated with each Threat Defense device.

Secure Access lists all the available Threat Defense devices along with their details and displays the status of synchronization for universal ZTNA configuration, associated resources, and enforced rules in Connect > Network Connections > FTDs.

Procedure

To view the details of a Threat Defense device (configured for universal ZTNA) in Secure Access, perform the following steps:

Before you begin

To view the Threat Defense devices configured for universal ZTNA, you must have at least read-only access in Secure Access. For more information, see Manage Accounts.

Procedure

Navigate to Connect > Network Connections > FTDs.
The list displays the following details:
- FTD Name – Displays the Threat Defense device name along with the device FQDN and the associated trusted network.
- Version – Displays the Firewall Management Center version.
- FMC – Displays the Firewall Management Center name.
- UTNA Configuration status – Displays the status of the universal ZTNA configuration synchronization with the Firewall Management Center. The possible statuses are:
  - Synced – The configuration is synchronized with the Firewall Management Center.
  - Syncing – The configuration is synchronizing with the Firewall Management Center.
  - Out of sync – The configuration synchronization is not initiated with the Firewall Management Center. This can happen when auto deployment is not enabled.
  - Failed to sync – The configuration synchronization with the Firewall Management Center has failed. For more information, see Troubleshooting Universal ZTNA guide.
- Associated Resources – Displays the number of resources associated with the Threat Defense device.
- Rules Enforced – Displays the number of rules enforced by the Threat Defense device.
Click the corresponding FTD Name. .

Alternatively, click the ellipsis (…) adjacent to the corresponding FTD Name, and choose View FTD Details.
Review the Firewall Details, UZTNA Configuration Status, Assigned Trusted Network, Associated Resources, and Rule Enforced sections for the selected Threat Defense device.
Note
- The Firewall Details section displays the auto deployment state.
- The UZTA configuration status section displays the reason if the status is Failed to sync or Out of sync.
In the Associated Resources section, click View resources associated to this FTD to view the list of associated private resources.

Alternatively, click the associated resource count.
Review the associated resources.

(Optional) Click Associate Resources to associate additional private resources with the Threat Defense device. For more information, see Associate Private Resources with Threat Defense devices.
In the Rule enforced section, click View rules enforced by this Firewall to view the list of enforced rules.

Alternatively, click the enforced rule count.
Review the enforced rules.

Associate Private Resources with Threat Defense Devices

To enforce the rules for a private resource using a firewall, you must associate private resources with a Threat Defense device. This ensures that the user traffic to the private resource is routed through the firewall instead of the Secure Access cloud when the user is connected to a trusted network.

Associate Private Resources with Firewall Threat Defense

Before you begin

You must have created the private resources on Secure Access.

Procedure

In Security Cloud Control, click Products > Secure Access.

Secure Access product menu displays in the left navigation bar.
Click Connect > Network Connections.
Click the FTDs tab.

The available Secure Firewall Threat Defense devices that are configured for universal zero trust network access are displayed.

Ensure that the device is associated with a trusted network to enforce policies on traffic originating from the trusted network before proceeding to the next step.

After a Threat Defense device is onboarded, it is automatically associated with a default trusted network if one exists. Otherwise, you must create a trusted network and associate it with the Threat Defense device.
Click the name of a Threat Defense device to configure.
In the right pane, click Associate Resources.
Note
- Only those resources that are enabled for zero trust access may associate with a Threat Defense device.
- A Threat Defense device must reach the associated private resources.
- Resources associated with a Threat Defense device are shared with other devices with the same FQDN.
In the Associate Private Resources dialog box, make the following selections to specify the access policy enforcement and traffic flow for a user:
- Use Threat Defense device to enforce policy only for on-premises users: From the Use this FTD to enforce policy drop-down list, select the private resources, which a user should be able to access only from an on-premises location.
- Use Threat Defense device to enforce policy for both on-premises and remote users: From the Always use this FTD to enforce policy drop-down list, select the private resources for which the selected Threat Defense device always enforces policy, regardless of whether the user is located on-premises or is remote.
The following figure shows an example of using a Threat Defense device to enforce access rules for the vftd-quic-app for on-premises users and vftd-amazon-app for all users, whether on-premises or remote.
Click Save.
The configurations are applied to the device, and the UZTA Configuration status column for the device displays Synced.

The following figure shows an example.

Configuration status can also be:
- Syncing—updates to the Threat Defense device are ongoing.
- Out of sync—modifications to Secure Access configurations are pending update to the Threat Defense device.
- Failed to sync—configurations were not updated on the Threat Defense device.
To view a detailed and granular status for each resource and rule associated with a Threat Defense device, perform the actions outlined:
1. Click the numeral in the Associated Resources column.
  
  In the slide-in pane, under the Associated Resources section, click View resources associated with this FTD.
  
  The configuration status of each resource is displayed.
2. Similarly, to check the configuration status of each rule that is enforced by the Threat Defense device, click the numeral in the Rules Enforced column.
  
  In the slide-in pane, under the Rules Enforced section, click View rules enforced by this Firewall.
  
  The configuration status of each rule that is enforced is displayed.
Universal ZTNA is now set up for your clients to securely access the private resources in your network.

Assign a Trusted Network to Threat Defense devices

Universal ZTNA allows Threat Defense devices to enforce rules for private resources when the user is connected to a trusted network. In Secure Access, you can define trusted networks to use for universal ZTNA. You can also define a network as a default trusted network. When Threat Defense devices are onboarded, Secure Access assigns the default trusted network to the Threat Defense devices automatically. You can modify this and assign a different trusted network to a Threat Defense device.

Procedure

To assign a trusted network to a Threat Defense device, perform the following steps:

Before you begin

You must have a full admin role in Secure Access. For more information, see Manage Accounts.
Trusted networks must be defined for universal ZTNA. For more information, see Trusted Networks for Zero Trust Access Connections.

Procedure

Navigate to Connect > Network Connections > FTDs.
Click the corresponding FTD Name.

Alternatively, click the ellipsis (…) adjacent to the corresponding FTD Name, and choose View FTD Details, or click the associated resources count.
In the Assigned Trusted Network section, click Edit assignment.
From the Trusted Networks drop-down list, select the corresponding trusted network.
Click Save.

The trusted network is displayed in the Assigned Trusted Network section.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.