How to Discover and Control Shadow IT SaaS in Cato CASB

Discover unsanctioned SaaS with Cato CASB — the monitoring rule that feeds discovery, the dashboards to read, and how to sanction, restrict or block what you find.

To find unsanctioned SaaS in Cato, enable TLS Inspection and create an Application Control rule that monitors all cloud activities — that pair is what populates discovery. Then read the results in Security > Applications, triage what appears using the risk scores in Resources > App Catalog, mark what you approve as sanctioned, and write Application Control rules to block or restrict the rest. Discovery is not a switch you turn on; it is a monitoring rule you leave running.

Applies to

Cato SASE Cloud, Cato Management Application (CMA), September 2026 navigation
CASB license — required for the Application Control policy and the app dashboards
DLP license — only if you also want the Data Protection sections
TLS Inspection enabled, for inline discovery of HTTPS traffic
Admin role with permission to edit Security policies and view Reports

Before you start

Enable TLS Inspection first. Cato's documentation is explicit that the CASB solution, and the Application Control policy in particular, relies on the ability to inspect traffic. Without it you will see domains, not applications and activities — see enabling TLS inspection in Cato.
Accept that discovery takes time to be useful. A day of data tells you what people used yesterday. Two to four weeks tells you what your organisation actually runs on.
Decide who owns the triage before you start collecting. An unreviewed app inventory is worse than none, because it creates the impression of control.

What Cato can and cannot see

Shadow IT discovery in Cato works two ways, and knowing which one you are relying on changes what the results mean.

Inline inspection covers users connected to the Cato Cloud with TLS Inspection enabled. This is the detailed view: application, activity, user, volume.

Out-of-band visibility covers SaaS applications through API integration, including usage by unmanaged users whose traffic is not tunnelled through the Cato Cloud. This is how the dashboard populates the Accessed Outside of Cato figure.

The gap between the two is the honest answer to "have we found everything." A device that never connects through Cato and uses a SaaS app with no API integration is invisible to both. Personal phones on mobile data are the usual example.

Step 1 — Enable the monitoring rule that feeds discovery

Discovery does not populate on its own. Cato's own prerequisite for the Cloud Activity dashboard is that Application Control is enabled with a rule that monitors all cloud activities.

Go to Security > App & Data Inline. On older tenants the path is Security > Security Configuration > App Control & Data Protection.
Create a rule named something like Monitor - all cloud activity (discovery).
Source: Any.
Application: leave broad — you are discovering, not restricting.
Activities: leave empty. An empty Activities field matches every activity for the application or category, which is exactly what you want here.
Action: the monitoring action, not Block.
Place it at the bottom of the policy so it observes traffic without pre-empting your enforcement rules.
Apply and Save.

Leave this rule in place permanently. It is the sensor, not a temporary audit step.

Step 2 — Confirm TLS Inspection is actually covering the traffic

Go to Monitoring > Events and filter to a known SaaS application.
Check the TLS Inspection field. It must show 1.
If it shows 0, discovery for that traffic will be limited to the domain level. Find the bypass rule catching it, or the OS bypass — Android, Linux and unidentified operating systems are bypassed by default.

The Applications dashboard has a TLS Inspection widget in its Overview section. Use it to see coverage across the estate rather than checking applications one at a time.

Step 3 — Read the discovery data

Two dashboards, different jobs.

Security > Applications is where you work. It has three tabs — Overview, Activities and Inventory.

Summary gives you the app count, the sanctioned versus unsanctioned classification, risky apps and users, and a Sankey diagram of usage flow.
Overview carries App Classification, App Risk, TLS Inspection coverage, App Categories, top users by network usage, Events by Action, Activities Over Time, Top Applications, and an Attack Surface section drawing on SaaS posture data.
Clicking any application opens the App Quick View drawer, with security and compliance information and throughput. You can change the security status of the app directly from that drawer.

Home > Reports > Catalog > Application Analytics is what you send to other people. It reports sanctioned versus unsanctioned counts and percentages, top applications by user count, and Cato's risk categorisation. It exports to PDF or CSV and can run daily, weekly or monthly to a mailing list that may include external recipients.

Set the Application Analytics report to monthly and send it to whoever owns software procurement. Shadow IT is usually a purchasing problem wearing a security costume, and the people who can actually fix it do not log into your SASE console.

Step 4 — Triage what you found

Go to Resources > App Catalog. Every application carries a Cato category, a risk score from 0 to 10, a sanctioned status and an app type.

Sort your discovered applications into four buckets:

Bucket	What it looks like	Action
Approve	Already in use, acceptable risk, has a business owner	Mark sanctioned
Replace	Duplicates something you already pay for	Block after the alternative is communicated
Restrict	Legitimate use, unacceptable activities	Allow, restrict specific activities
Block	High risk score, no business case	Block

To mark an app sanctioned, open it in the App Catalog and click Add to Sanctioned Apps. The remove icon reverses it. This is not merely a label — sanctioned status is a matchable object in policy, so you can write one rule covering every approved app and another covering everything else.

Do not block on risk score alone. A score of 8 on a tool that three finance staff have used daily for two years is a conversation, not a firewall rule. The score tells you where to look, not what to decide.

Step 5 — Enforce

Write rules in Security > App & Data Inline, ordered from most specific to most general:

Allow sanctioned apps. One rule matching the Sanctioned Apps category, at the top.
Restrict the middle ground. For apps you permit but do not trust, select the specific Activities to control — upload, file sharing, login by authentication type — and set the action accordingly. Leaving Activities empty matches everything, which is too blunt for this tier.
Block by category. Personal file sharing, unsanctioned AI tools, or whatever categories your policy excludes.
Keep the monitoring rule at the bottom. Discovery continues under enforcement, which is how you catch the next wave.

Category rules with a defined activity require TLS Inspection on the matching traffic, as do application rules. If an enforcement rule silently does nothing, check the TLS Inspection field on the event before rewriting the rule.

Caution: Blocking a shadow IT app that a team depends on will generate an incident, not a compliance win. Communicate before you enforce, and give people the sanctioned alternative first. The block is the last step of the process, not the first.

Verification

Confirm discovery is running. In Security > Applications, the Summary section should show a rising app count and a sanctioned versus unsanctioned split. A flat or empty inventory means the monitoring rule is not matching, or TLS Inspection is not covering the traffic.

Confirm classification is taking effect. After marking an app sanctioned, check that it moves in the App Classification widget and is matched by your sanctioned-apps allow rule.

Confirm enforcement works. Test one blocked application from a device in scope and check the corresponding event in Monitoring > Events, confirming both the rule name and a TLS Inspection value of 1.

Confirm coverage. Read the Accessed Outside of Cato figure on the Cloud Activity dashboard. It is the measure of how much of your SaaS usage your inline policy will never touch.

Notes and common pitfalls

Discovery without triage is theatre. The dashboard will happily list four hundred applications forever. Put a recurring calendar item against the Application Analytics report or it will not get read.
Android, Linux and unidentified OS are bypassed from TLS Inspection by default, so their traffic yields domain-level data at best.
Split-tunnelled traffic is never inspected. Apps excluded in your split tunnel policy will not appear in inline discovery at all.
Certificate-pinned desktop clients fall outside inspection the same way — see fixing Cato TLS inspection application failures.
AI tools are the fastest-growing shadow IT category and behave differently from ordinary SaaS, because the risk is what leaves rather than what is installed. Handle them with a DLP rule on AI uploads rather than an app block alone.
Sanctioned does not mean secure. It means approved. Sanctioned apps still need activity controls and DLP.
A single monitoring rule is not an audit trail. If you need evidence for a compliance review, schedule the Application Analytics report and retain the exports; dashboards are a live view, not a record.

Most organisations can stand up discovery in an afternoon. What takes longer is the operating rhythm around it — someone reviewing the monthly report, chasing owners, and keeping the sanctioned list current. Teams without that capacity in-house usually fold it into a managed CASB and cloud application control engagement, because the console work was never the hard part.

FAQs

1) Do I need the CASB license just to see shadow IT?

Yes for the useful version. Cato's documentation states that an additional CASB license is required for the Application Control policy and the Cloud Apps dashboard. Without it you can see traffic to domains in firewall events, but not the application-level inventory, risk scores, sanctioned classification or activity controls that make discovery actionable.

2) Why do some apps show up as domains rather than named applications?

The traffic is not being TLS inspected, so Cato cannot identify the application from the payload. Check the TLS Inspection field on the event — a value of 0 confirms it. The usual causes are a bypass rule, a bypassed operating system, a certificate-pinned client, or QUIC, which cannot be inspected at all.

3) How long should I run discovery before enforcing anything?

Two to four weeks. One week captures the routine but misses monthly cycles — payroll, board reporting, month-end close — which is exactly when finance and HR reach for unsanctioned tools under time pressure. Enforce after you have seen at least one full month-end.

4) What about SaaS used on personal devices that never touch Cato?

Inline inspection cannot see it. API-based integration gives out-of-band visibility for supported applications including unmanaged users, which is what the Accessed Outside of Cato metric reflects. Beyond that coverage, the controls are identity-side rather than network-side — SSO enforcement and conditional access decide whether that device can reach corporate data at all.

How to Discover and Control Shadow IT SaaS with Cato CASB