Introduction
Alert when the local user accounts on a device differ from the list you expect. The User monitor compares the accounts present on each covered device against your known users list and fires when something doesn't match: an account you didn't authorize, or an account that should exist but doesn't.
This is one of the fastest ways to catch unauthorized admin accounts, a common persistence technique after a compromise, and to detect when a required service account gets deleted.
How the User Monitor Works
The agent inventories the local user accounts on covered devices and compares them against your Known users list. The check runs about every 60 seconds, and the interval isn't configurable.
The alert fires on the first check that sees a discrepancy, so detection latency is up to about a minute. The condition clears on the next check after the discrepancy goes away, subject to the auto-resolve setting.
The alert text names the offending accounts: "Unknown users detected: guest, hacker" or "Missing users detected: svc_backup". With admin scope enabled, it reads "admin users" instead.
What Counts as a User
The monitor compares regular local accounts, not every account the OS knows about. The agent filters out system and service accounts automatically, so you don't need to add those to your known users list.
🖥️ PLATFORM NOTE:
Windows: Local accounts only. Machine accounts (ending in $) and built-in system accounts (WDAGUtilityAccount, DefaultAccount, ASPNET, Network/Local Service, krbtgt, IUSR_/IWAM_) are excluded. Domain users are not enumerated, even on domain-joined machines.
macOS: Service accounts starting with _ and accounts with UIDs below 501 are excluded. root is always included.
Linux: Accounts outside the UID_MIN to UID_MAX range defined in /etc/login.defs are excluded. root is always included.
⚠️ WARNING: The agent doesn't enumerate users on Windows Domain Controllers, so this monitor has no effect on a DC. Keep DCs out of the policy's target tags rather than assuming they're covered.
Configuring the User Monitor
Open the target monitor policy, then click + Add new monitor. The Add new monitor panel opens.
Name and Type
Enter a name in the Name field. Name it for what it catches: "Unexpected Admin Detected" reads instantly in an alert list; "User Monitor" doesn't.
Set Type to User.
Severity
Set Severity based on the impact of unexpected account changes in this context:
Information
Warning
Critical
Emergency
💡 TIP: For admin-scoped monitors, Critical or Emergency is usually the right call. An unauthorized admin account is a serious security signal, and it's worth treating it that way from the start.
Known Users
Enter the user accounts you expect on covered devices in the Known users field. Each account appears as a removable chip. Hit tab or add a comma to add additional users, and click the × on a chip to remove it.
Matching is case-insensitive, and whitespace around names is ignored. Jacob and jacob match the same account.
💡 TIP: Not sure what accounts exist on a device right now? Open the device and check the Users tab under device details. That's your ground truth for building the list.
ℹ️ NOTE: Click the {x} button at the right of the field to insert a variable, such as a custom field (for example, {{cf_known_users}}). The variable resolves per device, and its value is split on commas and newlines. This lets you drive the list from a custom field instead of hardcoding names per monitor. Useful when expected accounts vary per device or per client.
Scope
Scope controls which accounts the monitor compares against your list:
All users — every local user account on the device is checked
Admin users only — only accounts with administrative privileges are checked
💡 TIP: Admin users only is the lower-noise starting point. Standard user accounts come and go on shared workstations, but the admin list on a healthy device should be short and stable.
🖥️ PLATFORM NOTE:
Windows: Admin means a member of the built-in Administrators group.
macOS: Admin means a member of the admin or wheel group.
Linux: Admin means a member of the sudo, wheel, or root group.
Alert When
Alert when sets the condition that fires the alert:
An unknown user appears — fires when an account exists on the device that isn't in your known users list. Catches rogue or unauthorized accounts.
An expected user is missing — fires when an account in your known users list isn't found on the device. Catches deletion of required service accounts.
Either way, the known users list is the reference set. In unknown mode it works as an allow-list; in missing mode it works as a required list.
ℹ️ NOTE: Each monitor watches one condition. To catch both unknown accounts and missing accounts, create two User monitors in the same policy, one for each condition. They can share the same known users list.
Remediation
Attach one or more automations to run when this monitor fires. For an unexpected admin account, that might mean locking the device, disabling the account via script, or paging your security contact.
Click in the Remediation field and select an automation.
To add more, click + Add another remediation.
To remove one, click the × next to it.
Once an automation is attached, open it from the link icon to review it, and assign the monitor's payload to an automation variable if you want to pass alert data into the automation's logic.
⚠️ WARNING: Aggressive remediations like Lock Device act immediately when the alert fires. Test your known users list against real devices before attaching a disruptive remediation, or a missing entry in your list will lock out a legitimate machine.
Notifications
The Notify recipients checkboxes control whether the policy's recipients get emailed:
On alert creation — recipients get an email when the alert fires
On alert resolution — recipients get an email when the alert resolves
Recipients are managed at the monitor policy level, in the Recipients section.
Auto-Resolve
Auto-resolve alert when conditions clear closes the alert automatically when the account state returns to matching your known users list, for example when the rogue account is removed or the missing account is restored.
For a security-focused monitor, you usually want this disabled for manual review. An unauthorized account appearing and then disappearing is exactly the kind of event a human should review, even after the condition clears.
FAQ
Who can create and edit monitors? Technicians with access to the relevant monitor policy. Permission settings are managed in Workspace → Permissions.
Does this monitor cover domain accounts, or just local accounts? Local accounts only. Domain users aren't enumerated, even on domain-joined machines. To watch domain account membership, use a Run Script monitor with a custom check.
Why isn't this monitor doing anything on my Domain Controller? The agent doesn't enumerate users on Windows Domain Controllers, so the monitor has no effect there. Keep DCs out of the policy's target tags.
Do I need to add built-in accounts like Administrator or root to my known users list? Sometimes. System and service accounts are filtered out automatically, but standard built-ins that survive the filter (Administrator and Guest on Windows, root everywhere) count as users. If one exists on the device and falls within your scope, add it to the list or it'll trigger an unknown user alert.
Is the known users list case-sensitive? No. Matching is case-insensitive and ignores surrounding whitespace.
Can one monitor alert on both unknown and missing users? No. Each monitor fires on one condition. Create two monitors in the same policy, one set to An unknown user appears and one set to An expected user is missing.
My devices have different expected accounts per client. Do I need a monitor per client? Not necessarily. Use the {x} variable picker in the Known users field to reference a custom field, then store each device's expected accounts in that field (comma or newline separated). One monitor, per-device lists.
Why didn't my alert fire when I created a test account? A few things to check: the device must be online and covered by the policy's target tags, the check runs about every 60 seconds (so give it a minute), and a standard test account won't trigger a monitor scoped to Admin users only.
What happens to open user alerts if I delete the monitor? Existing alerts remain in place. Deleting a monitor doesn't close alerts it already created. Resolve those manually.