Bring Your Own Device (BYOD) lets employees use personally owned devices for work. Swif’s available policies, device information, and remote actions depend on the operating system, enrollment method, and installed management components.

Before assigning policies, check both the device’s ownership classification in Swif and how it was enrolled. A BYOD label alone does not describe every permission granted to an agent or management profile.

This article covers iPhone and iPad, Mac, Windows, and Android devices.

The following sections explain these differences and link to the corresponding enrollment guides.

Swif recommends Enrollment SSO for personally owned iPhones and iPads. Configure the BYOD enrollment flow and provide the user with their organization’s Managed Apple Account.

On the device, go to Settings > General > VPN & Device Management > Sign In to Work or School Account, then follow the organization’s enrollment instructions. The exact wording can vary by OS version.

Use the BYOD configuration when setting up Enrollment SSO. Swif also supports a separate account-driven Device Enrollment configuration, which provides broader management permissions. See Set up Enrollment SSO for Apple devices.

Learn more about iOS/iPadOS's User Enrollment, Device Enrollment, and Automated Device Enrollment.

Apple User Enrollment is designed for personally owned devices. It allows management of the organization’s accounts, settings, and information while keeping the user’s personal account outside that management scope. Only a limited set of policies and restrictions is available. See Apple: User Enrollment and device management.

For this enrollment type:

These limits apply to User Enrollment (set up as BYOD via Enrollment SSO). A personally owned iPhone or iPad enrolled through Device Enrollment (via QR code or Enrollment SSO) has different management permissions, including support for remote erasure. Verify the enrollment method before describing the device’s privacy protections. See Apple: Device Enrollment and device management.

When a BYOD iPhone or iPad is unenrolled and enrolled again, it can appear as a new device in Swif because Apple supplies a new enrollment identifier. Review the previous record and confirm that policies are assigned to the active enrollment.

For setup and troubleshooting, see How iOS and iPadOS Enrollment Works.

Swif’s macOS BYOD installer workflow includes a Swif Agent Profile and a Swif Admin user. Their permissions support compliance checks and administrative operations.

The profile can grant access to applications, removable or network volumes, and folders such as Desktop, Documents, and Downloads. Review these permissions with the device owner before enrollment.

See Managing BYOD Enrollment for macOS in Swif for component details and the effects of disabling them which you can:

Swif’s BYOD Enrollment SSO flow does not install the Swif desktop agent. Features that depend on that agent therefore cannot be assumed to work after SSO enrollment alone.

When a deployment requires agent-based functions, follow Swif’s application or silent-installer guidance and review the resulting permissions. See Set up Enrollment SSO for Apple devices.

Swif lists device lock and unlock as unsupported for macOS BYOD. Treat this as a Swif compatibility restriction for the BYOD workflow.

The following actions are listed as incompatible with macOS BYOD:

Apple’s supervision rules depend on enrollment method. On macOS 11 or later, a Mac enrolled through Device Enrollment is supervised even when enrollment was completed manually. Therefore, “personally owned” and “unsupervised” are not interchangeable descriptions. See Apple: About device supervision.

For Mac policy‑level limitations (which policies are or aren’t BYOD compatible), see: List of Apple policies.

If your organization requires remote device lock capability, the device must be enrolled as a fully managed corporate device instead of BYOD.

This typically requires:

Swif does not create a Swif Admin account on Windows BYOD devices. Commands that require that specific account cannot rely on it being available.

This account limitation does not, by itself, establish the execution permissions of every installed service or policy. Check each feature’s BYOD compatibility and execution requirements.

Implication:

The following actions are listed as incompatible with Windows BYOD:

Swif may display an inline compatibility warning when these actions target a Windows BYOD device. Do not rely on them for an offboarding or recovery workflow. Policy compatibility must also be checked individually.

What this means for admins

For Windows policy‑level limitations (which policies are or aren’t BYOD compatible), see: List of Windows policies.

Android BYOD uses a work profile added to the employee’s existing device. This enrollment does not require a factory reset.

The work profile separates managed work apps and data from personal apps and data. Swif’s management applies to the work profile, subject to the capabilities Android permits for personally owned devices.

COPE and BYOD both use work profiles, but their available controls differ. Swif’s COPE setup requires enrollment after a factory wipe; BYOD adds a work profile to an existing personal device.

For BYOD, a management wipe removes the work profile and its work data. It cannot factory-reset the entire personal device. See Understanding Android Device Management Modes.

Android permits work-profile management of apps, certificates, app permissions, and sharing between work and personal profiles. Supported passcode requirements can apply to the work profile and device.

Personal apps, data, and usage details are outside work-profile management visibility. However, work apps may provide network activity or location information subject to their permissions. A work-profile VPN routes work-profile traffic; it does not automatically route personal-app traffic.

Do not assume company-owned controls, such as device-wide camera restrictions or system-update scheduling, are available for BYOD. Check the ownership and OS requirements for each policy. See Google: What policies is my organization enforcing on my device?.

For Android policy‑level limitations (which policies are or aren’t BYOD compatible), see: List of Android policies.

If a policy or action is unavailable, first check compatibility. A successful enrollment does not mean every feature is supported.

For an unexpected result, provide Swif Support with the device’s OS version, enrollment method, policy or action name, and reported error. Do not include passwords or recovery keys.