Skip to main content

Android User Authorization Policy

Updated today

Overview

The Android User Authorization Policy lets IT keep Android device PINs aligned with the PIN stored in Swif. When enabled, Swif automatically re-applies the server PIN to the device three times a day (8:00 AM, 2:00 PM, 8:00 PM) through a background service.

This ensures the device PIN does not “drift” from the centrally managed PIN in Swif, even if the user changes it locally. The sync is performed silently by the background service and does not trigger a lock-now command.

Note: This policy is designed to support the same goal as User Authorization policies on other platforms (Linux, macOS, Windows): IT/IdP controls the credential, and the device remains aligned with the centrally-defined value.


How it works

When the Android User Authorization Policy is enabled:

  1. Swif stores the device PIN that was configured from the portal / backend.

  2. A cron-based background job is created for the enrolled Android device.

  3. The job runs automatically three times per day at:

    • 08:00

    • 14:00

    • 20:00 (device local time)

  4. On each run, Swif:

    • Issues a SET / RESET PIN command to the device using the latest successfully stored PIN in the database.

    • This operation is visible in the device Command tab as a password/PIN change command.

  5. The device PIN is overwritten with the server PIN on each scheduled run, ensuring the local PIN stays consistent with the centrally managed PIN.

The policy is enforced via background service only. It does not:

  • Call a user-facing API flow when it runs.

  • Force an immediate lock screen via LOCK_NOW when the sync executes.

  • Check or read the existing local PIN from the device (Android does not expose this capability).

Instead, it unconditionally re-applies the server PIN on the configured schedule.


Requirements and limitations

Minimum requirements

  • Platform: Android

  • Minimum OS version: Android 9+

  • Enrollment: Device must be:

    • Enrolled in Swif MDM, and

    • Have a PIN already set and stored in Swif’s database (e.g., from a previous lock / PIN command).

If there is no PIN stored in the database for the device, the sync job has nothing to apply, and the policy will not change the device PIN.

Management modes and scope

  • The policy is designed for managed Android devices under Android Enterprise (e.g., fully managed or corporate-owned modes).

  • There is no user-based structure on Android comparable to desktop OS user accounts. The sync applies at the device level, not to a specific named user account on the device.

Any device-level limitations or specific OEM restrictions may affect enforcement behavior.

Security and behavior constraints

Due to Android platform limitations:

  • Swif cannot read or verify the existing local PIN on the device.

  • Swif cannot directly detect when a user changes the PIN locally.

  • Instead, the system guarantees that, if a device is enrolled and has a stored PIN in Swif, the server PIN will be re-applied periodically (3× daily) to keep the device aligned.


Policy fields

pinSyncEnabled (Enable PIN Sync)

  • Display name: Enable PIN Sync

  • Type: Boolean

  • Default: "false"

  • Supported OS: Android 9+

  • Description:

    When enabled (true):

    • Swif:

      • Creates or updates a background PIN sync cron job for the Android device.

      • Automatically synchronizes the device PIN three times per day (8 AM, 2 PM, 8 PM).

    • The sync uses the latest successful PIN stored in Swif’s database for that device.

    • The operation is executed via the background service cycle, not through an on-demand UI/API action.

    • No LOCK_NOW is triggered by these scheduled syncs. Users will not be abruptly redirected to the lock screen as part of the sync cycle.

    • Each PIN set operation appears in the Command tab of the device, providing visibility into when the PIN was reapplied.

    • PIN changes are tracked in the database for audit and telemetry purposes.

    When disabled (false):

    • No background PIN sync cron job is created/maintained for that device.

    • The device PIN will not be automatically re-applied from Swif.

    • Any local PIN changes by the user will not be overwritten by this policy.


Typical use cases

  • You want to ensure that Android device PINs remain in sync with the PIN defined centrally in Swif/IdP.

  • You accept that Android cannot expose the current local PIN, but you still want a best-effort alignment by reapplying the known server PIN on a schedule.

  • You are mirroring controls similar to User Authorization policies on Linux/macOS/Windows, focusing on:

    • Central control of credentials.

    • Reducing the chance that a user-modified PIN persists indefinitely.


Behavior summary

  • Enforcement method: Scheduled SET/RESET PIN operations from Swif to the device.

  • Schedule: 3× daily at 08:00, 14:00, 20:00 (local time).

  • Visibility: Each operation will be logged and visible in the device’s Command tab.

  • User experience:

    • No surprise lock prompted by the sync itself (no LOCK_NOW from this policy).

    • The PIN on the device will be re-aligned to the value stored on the server on each scheduled run.

  • Audit/telemetry:

    • PIN updates are recorded in the database.

    • These records can be used for troubleshooting and compliance audits.


Notes for admins

  • Ensure the device has a valid PIN configured and stored from the Swif portal before relying on this policy.

  • Expect to see three SET PIN / RESET PASSWORD commands per day in the device’s Command tab when the policy is enabled.

  • This policy does not prevent a user from changing the PIN at a given moment, but it ensures that at the next scheduled run, the PIN is reset back to the value controlled by Swif.

Did this answer your question?