Roll Out ITP in Your Org

How-to guide

Pilot ITP with a single user, then expand it across your organization in stages

  • Last validated: Oct 16, 2026
  • 12 minutes to read

Overview

Use this guide to roll out Internet Threat Protection (ITP) in stages. Start with one pilot user, so that you can find and fix configuration issues before the policy reaches the rest of your organization.

Note: This guide covers rollout for both SIA Basic and SIA Advanced scenarios.

The rollout has two parts:

  • The basic rollout. Assign a pilot policy to one user, and confirm that the policy blocks and allows the traffic you expect. The policy applies to every device the pilot user has registered. To test on only one of those devices, you can narrow the pilot to that device’s serial number. When the pilot works, extend the policy to the rest of your organization in waves.
  • TLS decryption (advanced). TLS decryption lets CSE see full web addresses and file contents, which URL blocking, Risk-based URL Filtering, File Analysis, and Require Approved Accounts for AI Apps need. It can also stop some apps from connecting, so turn it on as a secondary step, for the pilot user first, after you’ve confirmed that the basic rollout works. See Turn on TLS decryption.

By the end of the rollout, every user’s desktop devices will be protected by an ITP policy. Mobile devices are not, because the Excluded Devices policy always includes the Mobile Devices role. You will also know which apps need extra configuration to keep working with TLS decryption on, such as a bypass entry in your ITP policy or the CSE certificate in the app’s list of trusted certificate authorities.

Prerequisites

Licensing

  • ITP requires an SIA license. Geo-Blocking, Risk-based URL Filtering, Malware Download Protection, and Require Approved Accounts for AI Apps require an SIA Advanced license.

Minimum desktop app version by feature

Capability Platforms Minimum desktop app version
Risk-based URL Filtering Windows, macOS 3.26.0
Malware Download Protection Windows, macOS 4.2.0
Require a passcode to disable ITP Windows, macOS, Linux 4.4.0

Warning: On macOS Sequoia, certificates cannot be installed without action from the end user. Without them, ITP is not enforced. Deploy the certificates through your MDM system. See Known Issues.

Network and DNS

  • List your private domains. ITP’s DNS resolver cannot resolve private (internal) domains, so add each one to Domain and URL Bypass in every ITP policy, starting in Step 2. See Private domains failing to resolve.
  • Identify the traffic that goes through a Service Tunnel. ITP does not evaluate traffic to Private Resources or traffic routed through a Service Tunnel. Pick test sites outside the tunnel for Step 4, because tests through the tunnel show no ITP result.
  • Free DNS port 53 on the pilot device. If another service on the device listens on port 53, ITP does not start, and the ITP health check still reports that it is working. Stop that service before you start ITP. See Known Issues.
  • Allow DNS over TLS through your firewalls. The CSE desktop app sends DNS traffic to CSE over DNS over TLS (DoT). If your firewalls restrict outbound DNS, confirm that they allow this traffic.

Logging

The Command Center retains events for 14 days. To keep a record of the pilot and of later waves, set up an export before you start. See Retrieve Events with the API for Long-Term Retention.

Phase 1: Pilot with one user

Step 1: Create the pilot role

A role based only on the user’s email address applies to every device that user has registered. Add a device attribute if you want to test on only one of those devices.

1.1 In the Command Center, navigate from Directory > Roles, and then select + Add Role.

1.2 Name the role, for example ITP Pilot.

1.3 Select + Add Role Attribute, select By Email, and then select the pilot user’s email address.

1.4 Optional: Select + Add Role Attribute again, and add a device attribute with the serial number of the pilot device.

1.5 Save the role.

1.6 Open the role’s Devices tab, and confirm that it lists only the devices you intend to include in the pilot. If it lists other devices, adjust the role’s attributes before you continue.

For more about role attributes, see Manage Roles.

Step 2: Create the pilot policy

2.1 Navigate from Internet Access > Internet Threat Protection, and select + Create Policy.

2.2 Name the policy, for example ITP Pilot, and attach only the pilot role.

2.3 Enter the message for the block page. Include how users can reach your help desk, because the block page is the first thing a user sees when ITP blocks a site.

2.4 Leave Enable Advanced Configurations off. This toggle turns on TLS decryption. With it off, any problem you find in the pilot comes from the basic policy. You turn it on later, in Turn on TLS decryption.

2.5 Turn on Category Filtering, and select the categories that your acceptable use policy blocks.

2.6 Turn on Domain and URL Bypass, and add your private domains.

2.7 Review the Threat Protection categories. They are always on and cannot be turned off.

2.8 Save the policy.

For every setting in the policy, see Create an ITP Policy.

Step 3: Move the pilot policy to the top

Each device receives one ITP policy: the highest-priority policy whose roles match it. Moving the pilot policy to priority 1 applies it to the pilot user without changing what any other device receives. See Prioritizing ITP Policies.

3.1 In Internet Access > Internet Threat Protection, select the Reorder button (the button with an up and down arrow).

3.2 Drag the pilot policy to priority 1, and select Save.

3.3 Open the Excluded Devices policy, and confirm that none of its roles match the pilot user or device. Excluded Devices always takes precedence over the pilot policy, and a device that matches one of its roles receives no ITP policy. It cannot be reordered or deleted, and its Mobile Devices role cannot be removed.

3.4 Check the policy sync status. Changes to assignments and priority can take time to appear in the console, especially in larger environments.

Step 4: Verify the pilot

4.1 On the pilot device, confirm in the CSE desktop app that ITP is on.

4.2 In the pilot policy, use Lookup Domain to confirm the verdict you expect for each test domain.

4.3 Run the following tests on the pilot device, and check the results in Visibility & Logging > Events:

Test Expected result
Visit a domain in a category the policy blocks The block page appears with your message, and a Compliance event is recorded
Visit a domain in Domain and URL Blocking The domain is blocked, and a Compliance event is recorded
Visit a domain in Domain and URL Bypass The domain loads, and no event is recorded, because bypassed traffic is not logged
Open an internal site by its private domain The site resolves and loads
Use your critical business applications They work normally
Turn ITP off in the desktop app An ITPStatus event is recorded, and ITP turns back on after 1 hour

Note: If the pilot device uses a Service Tunnel, traffic routed through the tunnel is not evaluated by ITP. Test with sites that are not routed through the tunnel.

Step 5: Decide whether users can turn ITP off

By default, a user can turn ITP off in the desktop app, and ITP turns back on after 1 hour.

5.1 Optional: To require a one-time passcode from an admin before a user can turn ITP off, turn on Require a passcode to disable ITP.

5.2 On the pilot device, turn ITP off with a passcode, and confirm that ITP turns back on when you expect.

The setting applies to every device with an ITP policy. While the pilot policy is your only ITP policy, the setting affects only the pilot device, so this is the safest point in the rollout to test it. Disabling ITP with a passcode also disconnects the device’s Service Tunnel.

Phase 2: Expand in waves

Step 6: Create a wave policy

A device that matches no ITP policy is not affected by ITP, so users outside the pilot and the current wave see no change until their own wave.

6.1 Start with a small group that can report problems quickly, such as the IT team. Create a role for the group, for example from a directory group.

6.2 Create a wave policy with the same settings as the pilot policy, and attach the group’s role. Leave Enable Advanced Configurations off.

6.3 Place the wave policy below the pilot policy, so that the pilot user continues to receive every change first.

Note: Under editions-based licensing, a user consumes a license when a device with an ITP policy assigned to it has checked in within the last 90 days. This includes users who have since been archived or deleted. Every role you attach to a policy consumes a license for each matching user. See Editions-based Licenses.

Step 7: Verify each wave

7.1 Ask a member of the wave to run the tests in Step 4.

7.2 Resolve any problems before you start the next wave. Repeat Steps 6 and 7 for each group.

Step 8: Create the organization baseline policy

8.1 When every group is covered, create an organization baseline policy assigned to a role that covers all users.

8.2 Place the baseline policy at the lowest priority. Any more specific policy above it continues to take precedence.

When every wave is covered, the policy order looks like this:

Priority Policy Assigned role
Fixed Excluded Devices Mobile Devices, plus any roles you exclude
1 ITP Pilot The pilot user
2 and below Wave policies Groups onboarded in waves, such as the IT team
Lowest Organization baseline All users

Note: A role that covers all users consumes a license for every matching user, including archived and deleted users whose devices checked in within the last 90 days. Check your license count before you attach the role.

Step 9: Keep or delete the pilot policy

9.1 Keep the pilot policy at priority 1, so that you can test future changes on the pilot user before anyone else receives them. While it remains at priority 1, the pilot user receives the pilot policy instead of any other policy, so update it whenever you change the baseline.

9.2 Optional: If you do not need a test policy, delete the pilot policy. The pilot user then receives the next policy that matches their role.

Turn on TLS decryption (advanced)

TLS decryption is controlled by the Enable Advanced Configurations toggle in an ITP policy. When it is on, CSE decrypts HTTPS connections at the Secure Web Gateway (SWG), inspects them, and re-encrypts them with a certificate issued by CSE’s own certificate authority (CA). Without it, CSE sees only which site a user visits, such as example.com. With it, the SWG also sees the full web address, such as example.com/downloads/setup.exe, and the content of the page or file. For what that does to your traffic path, your certificates, and your public IP addresses, read TLS Decryption before you start this section.

TLS decryption is required for:

The CSE desktop app installs the SWG CA chain into the device’s certificate store, so browsers and most applications keep working. Some applications stop connecting. See Applications that reject the CSE certificate. Step 10 helps you find them before your users do.

Step 10: List the applications to test

10.1 List the native applications your users depend on. Include meeting and chat clients, remote access and remote management tools, password managers, security and MDM agents, update services, backup clients, and developer tools.

10.2 Check each application against Global TLS Decryption Exclusions. SonicWall maintains that list for every org, and listed applications need no action.

10.3 Keep the applications that are not listed. You test them in Step 12.

Step 11: Turn on TLS decryption for the pilot

11.1 Open the pilot policy, select the pencil icon, and turn on Enable Advanced Configurations.

11.2 Optional: Turn on Risk-based URL Filtering and File Analysis. Both require an SIA Advanced license and are available on Windows and macOS.

11.3 Save the policy.

Step 12: Test the pilot with TLS decryption on

12.1 Repeat the tests in Step 4. Also confirm that a URL entry in Domain and URL Blocking is now enforced.

12.2 Use every application on your list from Step 10. If an application fails to connect or sign in, follow When an app fails to connect.

12.3 On Windows devices that use Microsoft Edge, confirm that the sites you test open normally. Risk-based URL Filtering can cause Edge to open some sites in Internet Explorer mode, which returns a 403 error. See Blocked access to websites when using Microsoft Edge.

When an app fails to connect

The usual symptom is that a desktop application fails to connect or sign in while the same service works in a browser, and the application works again when TLS decryption is off.

Note: Some apps fail with TLS decryption on because they do not rely on the device’s certificate store alone:

  • Certificate pinning. The application checks the server’s certificate against a list built into the application. An inspected connection fails closed, and the application cannot reach its service.
  • Private trust lists. The application ships its own list of trusted CAs and ignores the device’s certificate store.
  • Mutual TLS. The application authenticates the client with its own certificate, which cannot be presented through decryption.

To fix the application, use the first option that applies:

  • If the application lets you add trusted certificates, add the CSE SWG CA chain to it. Some applications, such as the ChatGPT desktop app, require this to be delivered through your MDM system. See SWG CA Certificates for Certificate-Pinned Apps.
  • Otherwise, add the application’s domains to Domain and URL Bypass as domain entries. A URL entry cannot fix this problem, because CSE must decrypt the traffic to match a URL.

Contact SonicWall Support about every application that fails, so that its domains can be considered for the global exclusion list.

Warning: Domain and URL Bypass excludes the domain from every ITP rule, not only from TLS decryption. ITP no longer blocks the domain for any reason, including Threat Protection categories such as malware and phishing, and bypassed traffic does not appear in logging. Keep bypass entries as narrow as possible.

Step 13: Turn on TLS decryption for each wave

13.1 Turn on Enable Advanced Configurations in each wave policy, one wave at a time, in the same order as Phase 2.

13.2 Ask a member of the wave to repeat the tests in Step 12 before you move to the next wave.

13.3 Turn on Enable Advanced Configurations in the organization baseline policy last.

Roll back

  • Remove a user or device from ITP: attach its role to the Excluded Devices policy. Excluded Devices always takes precedence, so the device stops receiving any ITP policy.
  • Stop a wave: remove the wave’s role from its policy, or delete the policy.
  • Turn off TLS decryption: turn off Enable Advanced Configurations in the policy. URL entries are kept but not enforced, and Risk-based URL Filtering and File Analysis stop until you turn it back on.
  • Troubleshoot one device: have the user turn ITP off for 1 hour, using a passcode if you require one.

After any of these changes, check the policy sync status, because the console can take time to reflect them.

After the rollout

  • Monitor events. ITP records Threat, Compliance, Malware, and ITPStatus events. Export them to keep more than 14 days of history.
  • Handle sites that are blocked by mistake. Use Lookup Domain to see how the domain is categorized and which verdict the policy returns. If an exception is needed, add a narrow Domain and URL Bypass entry. See the ITP Troubleshooting Guide.

What’s next

Was this page helpful?