Skip to main content

Accounts Swif Creates on Managed Devices

Overview

When you enroll devices in Swif and turn on certain features, Swif may create local accounts on those devices. This article lists every account Swif creates, what it's for, whether it has administrator privileges, and how to control it.


Summary

Account

Platforms

Created by

Admin privileges

Can someone log in?

Visible on the login screen

Swif Admin (swifteam)

macOS, Windows, Linux

Enrollment, by default

Yes

Only IT, for support

macOS and Linux: hidden. Windows: visible.

wazuh (service account)

macOS, Linux

Device CVE Report Policy

No

No

No

Accounts you list

macOS, Linux

Apple, Linux SSH User Policy

Not granted by Swif

Yes, over SSH with the user's key

Depends on the distribution

Swif doesn't create local accounts on iPhones, iPads, or Android devices.


Swif Admin account

What it is

A local administrator account named swifteam that Swif creates when a device enrolls. Swif uses it for tasks that need administrator rights, such as:

  • enforcing security policies

  • managing local user accounts and resetting passwords

  • managing the Secure Token on Macs, for account recovery

  • running commands as an administrator, using Run as Swif admin user

  • remote management and troubleshooting

Swif manages the account's password. On Linux, Swif also monitors the password and resets it if it no longer matches the value stored in Swif.

By platform

Platform

Created

Visibility

macOS

By default on company-owned Macs. On BYOD Macs, it can be turned off.

Hidden from the login screen

Windows

By default on company-owned devices. Not created on BYOD or Microsoft Entra ID–joined (Azure) setups.

Visible in the user list

Linux

By default on company-owned and BYOD devices. On BYOD devices, it can be turned off.

Hidden

Turn it off on BYOD devices

To stop Swif from creating the Swif Admin account on BYOD devices, turn off the Swif Admin User setting in the Swif console's Settings. See Managing BYOD Enrollment for macOS in Swif and Managing the Swif Admin User on Linux.

  • Devices that already enrolled keep the account. Turning the setting off affects only devices that enroll afterward.

  • Some features stop working without it. For example, Run as Swif admin user returns an error, and on Macs, Secure Token management for account recovery isn't available.

Other policies don't change it

Policies that set every local account to standard permissions, such as User Account Permission Sync, leave the Swif Admin account as an administrator.


Wazuh service account

What it is

A local service account named wazuh, plus a group with the same name. It's created by the Swif Security agent when you turn on a Device CVE Report Policy for Macs or Linux devices. The account comes from the standard Wazuh agent installer, which the Swif Security agent is built on. It isn't created on Windows.

What it's for

The part of the agent that communicates with Swif runs as this account, instead of with administrator (root) rights. If that part were ever compromised, an attacker wouldn't get administrator access to the device. This is a common security practice called privilege separation.

Privileges and login

  • No administrator privileges. It's a limited service account.

  • No one can log in with it. It has no password and no login shell.

  • Hidden on macOS. It doesn't appear on the login screen.

Removing it

Turning off the Device CVE Report Policy, or removing it from a device, uninstalls the Swif Security agent.

  • Macs and RPM-based Linux distributions, such as Fedora: uninstalling the agent removes the wazuh user and group.

  • Debian, Ubuntu, and Arch: the account can remain after the agent is uninstalled. It has no privileges and can't be used to log in. To remove it, run sudo userdel wazuh, then sudo groupdel wazuh if the group is still there.

Wazuh's documentation confirms this behavior:


Accounts from the SSH User Policies

The Apple SSH User Policy and the Linux SSH User Policy create the accounts you list in them, so users can sign in over SSH with their public keys. Swif creates an account only if it doesn't already exist on the device.

  • Standard users: accounts Swif creates are never administrators. On Macs, they aren't in the admin group. On Linux, they don't get sudo or other groups. An account that already existed keeps the rights it has.

  • macOS: accounts Swif creates are hidden from the login window, and have no password, so they can only sign in over SSH with a key.

  • When you remove a user from the policy: Swif removes the keys it added. An account Swif created is disabled on macOS, or locked on Linux, not deleted, so its files stay on the device. If you add the user back, the same account is enabled again.

  • Accounts Swif didn't create: they keep working with their own password and keys, and are never removed.


Check which accounts are on a device

In Swif: open the device, and go to the Accounts tab. It lists the device's local accounts and their privileges.

On a Mac: run this in Terminal to list local accounts, including hidden ones:

dscl . -list /Users | grep -v '^_'

On Linux: run this to check for the Swif accounts:

getent passwd swifteam wazuh

Troubleshooting

A user found an account named swifteam

This is the Swif Admin account. Swif uses it for administrator tasks, such as enforcing policies and resetting passwords. It's expected on managed devices. On macOS and Linux, it's hidden from the login screen.

A user found an account named wazuh

This is the limited service account the Swif Security agent uses for vulnerability detection. It has no administrator privileges, and no one can log in with it.

The Swif Admin account is still on a BYOD device after I turned off the setting

This is expected. Turning off the Swif Admin User setting affects only devices that enroll afterward. Accounts on devices that already enrolled stay.

The wazuh account is still on a device after I turned off the Device CVE Report Policy

On Debian, Ubuntu, and Arch, this is expected. The account can remain after the agent is uninstalled. Remove it with sudo userdel wazuh, then sudo groupdel wazuh if the group is still there.

On Macs and RPM-based distributions, check that the policy change reached the device and the agent was uninstalled. The account is removed together with the agent.


Related resources

Did this answer your question?