Risky app categories
Risky app categories finds installed apps in categories that do not belong on a work device, for example crypto-mining apps, hacking and security-testing tools, file-sharing and pirated-content apps, or device-restriction removal tools. Each category is its own policy, so you turn on only the categories you care about. XFA maintains the catalog of which app belongs to which category, so you do not have to keep your own list.
Application checks are turned on per organization. If you do not see them under Policies, contact XFA to turn on application checks for your organization.
macOS, Windows, and Linux are supported.
Why this matters
A valid code signature does not make an app welcome. A crypto-mining app can be properly signed. So can a security-testing tool or a file-sharing app. Application safety does not flag any of them.
These policies close that gap: XFA matches installed apps against its catalog, and you decide which categories are acceptable on your devices.
Categories
Each category is a separate policy. The category names are the names the user sees in the XFA app. The examples are apps in the XFA catalog.
| Category | Examples | API name |
|---|---|---|
| Crypto-mining apps | XMRig, NiceHash Miner, NBMiner | no_cryptominers |
| Hacking & security-testing tools | Metasploit Framework, Hashcat, Aircrack-ng | no_hacking_pentest |
| Device-restriction removal tools | checkra1n, palera1n, Magisk | no_jailbreak_rooting |
| File-sharing & pirated-content apps | qBittorrent, Transmission, uTorrent | no_piracy_p2p |
| Virtual machine software | VMware Fusion, Parallels Desktop, VirtualBox, Docker Desktop | no_virtualization |
| Third-party AI coding assistants | Aider, GPT Engineer, PearAI | no_third_party_ai_coding |
| VPN apps | NordVPN, ExpressVPN, WireGuard | no_vpn_clients |
| Lesser-known web browsers | Pale Moon, Basilisk, SeaMonkey | no_experimental_browsers |
| Games & gaming apps | Steam, Epic Games Launcher, Battle.net | no_games |
| Apps requesting broad permissions | Apps that ask for far more access to the device than they likely need | no_permission_hungry |
How the check works
For each category, the XFA catalog lists the known apps with the places they install to and the names of their programs on each operating system. The XFA app looks for those on the device:
- It checks whether any of the app's known install paths exist.
- If none do, it looks up the program by name: in the command path on macOS and Linux, and in the App Paths registry key on Windows.
On macOS, the XFA app never looks inside the user's private folders, such as Desktop, Documents, Downloads, and cloud storage folders.
If the XFA app cannot reach the catalog, it uses the copy it downloaded before. Without one, the category waits until the catalog can be reached.
What leaves the device
Per-app data never leaves the device. The names, paths, and identifiers of installed apps stay on the device.
Only the number of apps per category is sent, together with whether the XFA app could reach the catalog and whether the check is supported on the device.
You can therefore see that a device has two VPN apps without learning which ones. Only the user sees the apps involved, in the XFA app on their own device.
What you can configure
You configure each category as its own policy under Policies in the XFA dashboard, the same way as other on or off checks:
- Warn. Devices with at least one app in the category get a warning in the XFA app and, if you configured it, an Awareness notification. Sign-in is not blocked.
- Block. Devices with at least one app in the category are blocked from signing in to applications protected by XFA.
Leave a category off to ignore it. You pick categories, and the catalog keeps track of which apps belong to them.
For how warning and blocking work across XFA, see Compliance goals.
What the user sees
The XFA app shows these checks under Risky app categories. It reads Apps from risky categories found when an app matches, and No apps from risky categories when none do. Each category has its own row, for example Piracy or file-sharing apps detected.
Each row lists the apps involved, on the user's own device only, with a short reason the category is risky. The user can remove an app from the XFA app. XFA first lists exactly what it will remove and asks the user to confirm. When part of it needs administrator rights, macOS asks for an administrator password, Windows asks for permission through User Account Control, and Linux asks for a password through PolicyKit. A removal cannot be undone.
XFA removes nothing unless the user confirms. When your policy covers a category, the user cannot ignore an app for it.
Games and virtual machine software are only flagged when your policy turns them on. They are a workplace choice, not a risk to the user on their own.
Frequently asked
Who maintains the catalog?
XFA does. You do not need to keep your own list of unwanted apps up to date.
Can we add our own entries?
Not yet. For now you turn on the categories XFA maintains.
Why is Linux supported here but not for application safety?
This check looks for known install paths and program names, which works the same on Linux. Application safety needs a signature on each program, which Linux does not have.
Does the dashboard see which apps are installed?
No. It sees the number of apps per category and the result of each policy.
Related
- Application safety, which checks the code signature of each app.
- Install protection, the operating system setting that checks apps before they run.
- Policies