Skip to main content

Glossary

Device compliance

Device compliance is the continuous evaluation of an enrolled device against the rules an IT team has defined, producing a compliant or non-compliant verdict and, in most cases, an automatic consequence. That verdict is the device signal conditional access relies on, so its accuracy decides whether access decisions mean anything.

How it works

You write rules. The common ones are short: a passcode of at least six characters, disk encryption on, an OS version at or above a floor you set, no jailbreak or root detected, the management profile still installed, a required security app present, a check-in no older than a few days.

The device reports facts, the server evaluates them, and a verdict is produced. What happens next is configurable, and grace periods are where real deployments live. Mark a device non-compliant the instant Apple ships a new iOS build and you will block half the fleet for something they cannot fix until they reach Wi-Fi. Most teams give a warning window, typically 7 to 14 days, with a notification to the user, then enforce. Keep the grace period for cosmetic drift and skip it for the serious states: a removed management profile or a detected root should count immediately.

Two limits deserve honesty.

Drift between check-ins. A verdict is only as fresh as the last report. Apple's MDM protocol relies on push notifications to wake the device, and a phone that is off, in airplane mode, or sitting in a drawer simply stops reporting while its last verdict stays on the dashboard looking green. Treat check-in age as a compliance rule in its own right, not as a column you glance at.

Jailbreak and root detection. It is heuristic and it is a cat and mouse game. Checks look for known binaries, writable system paths, suspicious entitlements. Modern hiding tools defeat naive checks, and on the other side an unusual but legitimate configuration occasionally trips a false positive. Hardware-backed attestation gives a stronger answer: the Play Integrity API on Android returns a verdict signed by Google, and Samsung's Knox warranty bit flips permanently on unofficial firmware.

Why it matters for a fleet

Without compliance, an MDM is an inventory tool. With it, policy has teeth: the device that fell behind loses the mailbox instead of staying on the list of things someone means to fix.

It also converts an audit question into a report. Asked how many devices are encrypted and current, you answer with a number and a timestamp rather than a promise.

How Appaloosa handles it

Compliance policies in Appaloosa are evaluated continuously across iOS, iPadOS, Android, Windows and macOS: passcode, encryption including BitLocker on PCs, minimum OS version, required apps, jailbreak and root indicators, last check-in. Non-compliance can notify the user, revoke access to managed apps, or trigger a selective wipe that removes work data and leaves personal content intact, and the resulting state can be handed to your identity provider. The rule sets per platform are documented with the rest of Appaloosa's device management policies.

Explore

See the full platform

Enrollment, apps, security, remote support: all in one place.

Explore Appaloosa →

See Appaloosa run on your fleet Book a demo

Frequently asked questions

How long should a compliance grace period be?
Between 7 and 14 days works for most fleets on things the user can fix themselves, such as an OS update or a weak passcode. Pair it with a notification that says what to do and when access ends. Skip the grace period entirely for a removed management profile or a detected root, because those are not accidents.
A device shows as compliant but has not checked in for a week. Is it safe?
No, it is unknown, which is not the same thing. The verdict you are looking at describes the device as it was at the last report. Add a maximum check-in age to your rules so stale devices fall out of compliance automatically instead of sitting on the dashboard in green.
Can an MDM reliably detect a jailbroken iPhone?
It detects most cases, not all. Checks rely on indicators such as known files and writable system paths, and tools exist specifically to hide them. Combine detection with attestation where the platform offers it, and treat a device that stops reporting as suspicious rather than assuming it is fine.