This reference explains every issue status you can encounter on the Compliance > Compliance issues page: what the device is actually reporting, the causes behind it on macOS and Windows, and how to resolve it. 
Mobile platforms (iOS, iPadOS, Android) and Linux are covered by a subset of these rules — see Supported platforms for what applies where.

How Factorial IT decides a device is non-compliant

Every time a device syncs, Factorial IT re-runs each compliance rule and computes a status per rule — there is no separate scan.
A device raises an issue only if its current status is one you set to raise an issue in Compliance > Compliance issue settings. A status set to Off never raises anything.
Issues clear automatically on the next sync once the status improves. There is no manual acknowledge or close.

Rule out stale data first

A compliance status is a snapshot from the device’s last sync. Before treating an issue as a real violation, check whether the data is stale:

Enrollment Status

A global rule that applies to every managed device. It checks whether the device is fully enrolled and whether the MDM agent still communicates with the server.

Why devices drift out of enrollment

Causes that apply to both platforms:

• The employee did not complete all the enrollment steps, or did not stay connected long enough to finish synchronisation
• The agent was uninstalled manually, or a system update or configuration error corrupted the installation
• The osqueryd service used by the agent has stopped, or the agent fails to start due to permission issues
• The device sits on a network that blocks access to the MDM server — a proxy or firewall cuts the communication

macOS

1. An admin user can remove an unlocked MDM profile from System Settings. The device then reports MDM_OFF even though the agent may still respond.
2. An expired or revoked APNs token prevents the device from validating its profile — the profile becomes invalid without anyone touching the device.
3. A turn off mdm action executed from the MDM server side removes management.
4. The Fleet agent installation is incomplete — the most common cause of partial enrollment on macOS.
    

Resolve enrollment issues

• MISSING_AGENT — in the device panel, click the device status button to remotely trigger the agent installation. If that fails, ask the employee to open their Factorial IT enrollment page, click their assigned device, and download the agent.
• MDM_ON_IN_ANOTHER_MDM — migrate the device from the previous MDM first.
• MDM_OFF — ask the employee to re-enroll. You can automate this: in Settings > MDM, enable Auto-Unenrollment and the option to automatically resend MDM invitations to employees whose devices were purged.

Windows

• The device is still enrolled in a previous MDM and reports MDM_ON_IN_ANOTHER_MDM — migrate it out of the old MDM before re-enrolling.
• A proxy or corporate firewall blocking the server connection leaves an installed agent silent (MISSING_AGENT).
   

Resolve enrollment issues

• MISSING_AGENT — in the device panel, click the device status button to remotely trigger the agent installation. If that fails, ask the employee to open their Factorial IT enrollment page, click their assigned device, and download the agent.
• MDM_ON_IN_ANOTHER_MDM — migrate the device from the previous MDM first.
• MDM_OFF — ask the employee to re-enroll. You can automate this: in Settings > MDM, enable Auto-Unenrollment and the option to automatically resend MDM invitations to employees whose devices were purged.

Online Status

A global rule tracking whether the device checks in with the server.

Why devices go offline

• The device is powered off or asleep — an employee on leave, or a spare sitting in a drawer.
• The network blocks the agent’s connection to the server (VPN, proxy, firewall rules). See Network requirements.
• The agent is no longer running. A device that appears offline while actively used by an employee typically indicates a missing agent or a network issue, not a genuinely offline device — check the Enrollment Status issue for the same device.

Resolve online issues

Confirm with the employee whether the device is in use. If it is, treat it as a MISSING_AGENT case (see above). If the noise comes from short gaps, raise issues on Offline 7+ days only.

Platform support

A global rule that checks the device’s OS against the baseline Primo supports as an MDM signal source. A device below that baseline cannot reliably enroll, report telemetry, or honor policies — this issue is your upgrade list.

MEETS_REQUIREMENTS is the compliant status. The rule stays silent until the device has reported its OS information, so a freshly enrolled device is never flagged as unknown.
​
Resolve platform support issues

• BELOW_MINIMUM_VERSION — upgrade the OS. The current baselines per platform are listed in Supported platforms.
• UNSUPPORTED_OS_EDITION — upgrade the edition, not just the version: see Manage Windows Home devices and Upgrade to Windows 11.
  ​

Encryption

Checks full-disk encryption: FileVault on macOS, BitLocker on Windows. Encryption is not on by default — it starts when you enable the Disk Encryption control, which applies globally to enrolled devices once created.

ENCRYPTED is the compliant status. iOS and iPadOS devices always report ENCRYPTED — their storage is hardware-encrypted by design. A Windows Home device raises no encryption status at all: it cannot run BitLocker and surfaces under Platform support as UNSUPPORTED_OS_EDITION instead.

macOS

• FileVault turns on once the Disk Encryption control targets the device, but encryption only takes effect after the next restart. A Mac that never restarts stays NOT_ENCRYPTED — ask the employee to reboot.
• The recovery key is escrowed within 24 hours after that restart. A freshly encrypted Mac showing MISSING_RECOVERY_KEY in that window resolves on its own.
• A Mac encrypted before enrollment has a key Primo never saw — escrow is not retroactive. The employee must enter their password when prompted so a new key can be generated and escrowed (ACTION_REQUIRED).

Windows

• BitLocker starts encrypting as soon as the control reaches the device, with no restart required, and the key is stored as soon as encryption activates. A Windows device stuck on NOT_ENCRYPTED usually has a blocker, not a delay.
• BitLocker needs a working TPM. A missing or firmware-disabled TPM makes encryption fail to start.

OS Update

Checks that devices install required OS updates by the deadline you enforce.

UP_TO_DATE is the compliant status. Between an update’s release and its deadline, the device stays compliant — NOT_UP_TO_DATE only fires once the deadline has passed. A device whose OS is too old for Primo itself is a Platform support issue, not an OS Update one.

Why devices fall behind on updates

• The deadline counts from the update’s availability date, not from when you configured the policy. Enabling the policy on a fleet running older versions flags those devices immediately — expect a wave of issues on day one.
• Low disk space blocks the update on every platform, and none of them frees space automatically. On macOS 14+ the employee sees a system notification; on macOS 13 and earlier the Nudge window keeps reappearing while the download fails; on Windows the employee is told the update failed. An administrator may need to step in.
• The device was off when the deadline passed. On macOS 14+ the update is scheduled for 1 hour after it turns back on; on Windows the employee gets the configured grace period before the automatic restart.
• The employee keeps deferring within the allowed window — pressure increases as the deadline approaches (hourly notifications 24 hours before, more frequent in the final hour).

Resolve update issues

Have the employee free disk space if that is the blocker, then let the enforcement flow run — it escalates on its own. Details and the exact notification schedule per platform: Enforce OS updates.

Endpoint protection (SentinelOne, ThreatDown)

Available once the corresponding integration is connected. Checks that the endpoint protection agent is installed and reporting.
 

ACTIVE is the compliant status for both tools.
 

Why devices show as unprotected

• The control was just enabled — the agent installs on the device’s next sync.
• The agent was uninstalled locally or is not running.
• The integration itself is stale. SentinelOne service user tokens expire; once the token lapses, syncing stops and protection statuses go stale fleet-wide. Renew the token in Settings > Integrations > SentinelOne.
• The device is offline, so its real protection state is unknown.

Admin accounts (Admin User Management, Admin Password Rotation)

Checks that the managed local administrator account exists, holds the expected privileges, and rotates its password on schedule.

Why admin account actions stall

• CREATION_PENDING on an offline device resolves once it syncs.
• On macOS, demotion waits until the Factorial IT-managed admin account itself holds a SecureToken — the token FileVault depends on. Factorial IT deliberately demotes nobody before that, so the device is never left without a token-holding admin, and DEMOTION_PENDING persists (the device logs the event ADMIN_DEMOTION_BLOCKED_SECURE_TOKEN_NOT_GRANTED). The managed admin receives its token at its first login on the device — have someone log into that account once, or grant the token manually. See SecureToken rules.
• The cockpit can take up to 24 hours to refresh the local account status in the device’s Users tab — verify on the device before concluding a failure.

The Admin Password Rotation rule reports its own statuses: PENDING, SUCCESS, ERROR. SUCCESS is compliant; PENDING clears once the device applies the rotation, so ERROR is the status worth raising an issue on.

iCloud Lock (Activation Lock)

macOS only — Activation Lock also exists on iOS and iPadOS, but this compliance rule only evaluates Macs. It checks that when Activation Lock is on, Primo holds the bypass code, so the device can be recovered after a wipe without the employee’s Apple Account.

Why a bypass code is missing

Escrow happens at the moment Activation Lock activates — it is not retroactive. All of these must be true for the code to escrow:

• The device is supervised via MDM.
• The device was enrolled before Activation Lock was enabled. If the employee turned on Find My before enrollment, the code cannot be retrieved — the only recovery path is their Apple Account credentials.
• The device is company-owned (BYOD devices are not eligible).
• The MDM profile is installed at the system level (user-approved enrollment without ABM does not reliably escrow codes).

Recovery OS

macOS only. Checks that the recoveryOS protection configuration is applied. Only Apple Silicon Macs are evaluated — Intel Macs cannot support recoveryOS protection and produce no status at all.

PROTECTED is the compliant status. Full enforcement requires the device to be enrolled with the appropriate supervision level — an unsupervised Mac is the first thing to check on FAILED.ç

Profile-delivered controls

Firewall, Password Policy, Wi-Fi, USB Blocking, App Blocking, Screen Capture, Disable AirDrop, Lock Profiles Pane, Google Chrome, Device Naming, Custom Configuration File, Web Clip, AirPrint, Software Update (macOS), and the SSO controls (Entra SSO, Okta SSO, Primo SSO) all work the same way: Primo delivers a configuration to the device, and the device reports back. They share the same delivery statuses:

ENFORCED is the compliant status.

Why a configuration fails to apply

macOs

• An admin user removed the MDM profile carrying the configuration (unless Lock Profiles Pane prevents it).
• APNs issues stop the device from receiving or validating profiles — check the Enrollment Status issue for the same device.
• The control targets a capability the device lacks: Platform SSO controls require recent macOS versions (Primo SSO needs macOS 14+), and the employee must complete the identity provider registration prompt in their session.

PENDING that persists usually means the device is offline — fix connectivity first. For ERROR, open the device drawer, jump to the related MDM control to verify its configuration, and re-apply.

Windows

• Windows Home / Family only partially applies security policies — several configurations require Pro, Enterprise, or Education, and fail without an explicit error on Home. See Manage Windows Home devices.
• A conflicting setting from a previous MDM or a local group policy overrides the delivered value.

PENDING that persists usually means the device is offline — fix connectivity first. For ERROR, open the device drawer, jump to the related MDM control to verify its configuration, and re-apply.

Remote Access (RustDesk)

Unlike the profile-delivered controls, the Remote Access rule tracks a software installation, not a configuration profile.

INSTALLED is the compliant status. A persistent PENDING usually means the device is offline or the installation is still queued — check the software installation status from the device panel, then let the next sync clear the issue.

Resolve any issue: the general loop

1. Open the device drawer. Click the issue row on Compliance > Compliance issues. Review the device’s full status across every rule — several issues on one device often share a single root cause (offline, agent missing, profile removed).
2. Separate stale from real. Check when the device last synced. If it has been offline, resolve connectivity before anything else.
3. Fix the root cause. Use the sections above. Remediation actions (push profile, lock, wipe) are available from the device drawer — see Manage your devices.
4. Let the issue clear itself. Issues resolve automatically on the next device sync once the status improves. If an issue should never have fired, set that status to Off in Compliance > Compliance issue settings instead.

Permissions