Compliance alert reference

This reference explains every alert status you can encounter on the MDM > Compliance Alerts page: what the device is actually reporting, the causes behind it on macOS and Windows, and how to resolve it. To choose which statuses raise alerts, see Configure compliance alert rules; for the triage workflow itself, see Monitor compliance alerts. Mobile platforms (iOS, iPadOS, Android) and Linux are covered by a subset of these rules — see Supported platforms for what applies where.

​

How Primo decides a device is non-compliant

• Every time a device syncs, Primo re-runs each compliance rule and computes a status per rule — there is no separate scan.
• A device alerts only if its current status is one you toggled on in Manage rules. A rule with no statuses toggled never alerts.
• Alerts clear automatically on the next sync once the status improves. There is no manual acknowledge or close.

See Compliance overview for the full evaluation model.

​

Rule out stale data first

A compliance status is a snapshot from the device’s last sync. Before treating an alert 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 synchronization.
• 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. See Network requirements.

​

Resolve enrollment alerts

• 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 Primo 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.

Allow up to 30 minutes for the status to update after the fix. Full detail: Resolve enrollment issues.

​

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 alert for the same device.

​

Resolve online alerts

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, alert 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 alert 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 alerts

• 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. Control details: Disk encryption.

​

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 alert, 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 alerts 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 alerts

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.

Setup and remediation: SentinelOne, ThreatDown.

​

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 Primo-managed admin account itself holds a SecureToken — the token FileVault depends on. Primo 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 dashboard 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 alerting on. Control details: Admin management.

​

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. ENABLED (lock on, code escrowed) and DISABLED (lock off) are both compliant. The rule produces no status while the device is not fully enrolled or its lock state is still unknown.

​

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).

Scenario-by-scenario analysis and remediation: Activation Lock bypass code escrow.

​

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. Control details: recoveryOS protection.

​

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

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 alert.

​

Resolve any alert: the general loop

​

Permissions

​

Next steps