# Security Info

> Check the security state of an Apple device in Applivery — encryption, passcode presence and compliance — and understand what each value means.

Source: https://docs.applivery.com/en/device-management/apple/security-info/  •  Last updated: 2026-08-08

**Key topics:** iOS Data Protection, Passcode compliance, FileVault reporting, Device security verification, Applivery, Apple, iOS, macOS, FileVault

---

**TL;DR:** Check an Apple Device's encryption and passcode state in Details > Security info. On iOS, encryption is verified, not enabled — Apple requires hardware capabilities of 3 plus a passcode for data to be protected.

"Is this iPhone encrypted?" is a question that comes up in every security audit, and on Apple Devices it has an unusual answer: **encryption isn't something you turn on**. On iOS and iPadOS, Data Protection is a capability of the hardware, and it's always there. There is no policy setting to enable it, because there's nothing to enable.

What there is, is a way to **verify** it — and that's what the Security info panel is for.

## Where to find it

Open a Device from the device list in the [**Applivery Dashboard**](https://dashboard.applivery.io) and go to **Details** → **Security info**.

![security info](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c03ec296-aa2b-4d95-ab51-bc931d8fc1c2.png)

## Verifying encryption on iPhone and iPad

Encryption on iOS depends on two things at once, and Apple states the criterion explicitly:

:::info
**For a Device to have Data Protection, the hardware encryption capabilities must be** `3` **, and a passcode must be present.** Both conditions, not one or the other.
:::

<table style="min-width: 50px;"><colgroup><col style="min-width: 25px;"><col style="min-width: 25px;"></colgroup><tbody><tr><th colspan="1" rowspan="1"><p>Value</p></th><th colspan="1" rowspan="1"><p>What it means</p></th></tr><tr><td colspan="1" rowspan="1"><p><strong>Hardware encryption capabilities</strong></p></td><td colspan="1" rowspan="1"><p><code>1</code> — block-level encryption only · <code>2</code> — file-level encryption only · <code>3</code> — both</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Passcode present</strong></p></td><td colspan="1" rowspan="1"><p>Whether the Device has a passcode set at all</p></td></tr></tbody></table>

This is why the [Passcode configuration](https://docs.applivery.com/en/device-management/apple/apple-policies/passcode/) matters so much on Apple Devices. The hardware does the encryption, but **the passcode is the key**. A Device with full hardware capabilities and no passcode is, in practice, an unprotected Device — and it will report exactly that here.

If you're filling in a compliance checklist that asks _"is the Device encrypted?"_, this pair of values is your evidence.

## Passcode compliance

Two values report whether the passcode is good enough, and the difference between them matters:

<table style="min-width: 50px;"><colgroup><col style="min-width: 25px;"><col style="min-width: 25px;"></colgroup><tbody><tr><th colspan="1" rowspan="1"><p>Value</p></th><th colspan="1" rowspan="1"><p>What it checks</p></th></tr><tr><td colspan="1" rowspan="1"><p><strong>Passcode compliant</strong></p></td><td colspan="1" rowspan="1"><p>The passcode meets <strong>all</strong> requirements on the Device, including those coming from Exchange and other accounts.</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Passcode compliant with profiles</strong></p></td><td colspan="1" rowspan="1"><p>The passcode meets the requirements coming from <strong>MDM profiles</strong> only.</p></td></tr></tbody></table>

When you're troubleshooting _"why is this Device flagged?"_, the second one is usually the one you want: it tells you whether **your** Policy is satisfied, without the noise of requirements set by a mail account you don't manage.

:::warning
**Neither value applies to Devices enrolled through User Enrollment.** Apple doesn't report passcode presence or profile compliance for personal Devices, so an empty value on a BYOD Device isn't a fault — it's the expected behaviour. Combined with the fact that [Apple ignores most passcode settings in User Enrollment](https://docs.applivery.com/en/device-management/apple/apple-policies/passcode/), personal Devices simply can't be verified this way.
:::

## Encryption on Mac

macOS works the other way around: encryption **is** a real setting, and it's FileVault.

<table style="min-width: 50px;"><colgroup><col style="min-width: 25px;"><col style="min-width: 25px;"></colgroup><tbody><tr><th colspan="1" rowspan="1"><p>Value</p></th><th colspan="1" rowspan="1"><p>What it reports</p></th></tr><tr><td colspan="1" rowspan="1"><p><strong>FileVault enabled</strong></p></td><td colspan="1" rowspan="1"><p>Whether full disk encryption is on.</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Has institutional recovery key</strong></p></td><td colspan="1" rowspan="1"><p>Whether an organizational recovery key exists.</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Has personal recovery key</strong></p></td><td colspan="1" rowspan="1"><p>Whether a personal recovery key exists.</p></td></tr></tbody></table>

Recovery keys are worth checking alongside the encryption state itself. An encrypted Mac with no escrowed recovery key is a Mac you can't help when the user forgets their password.

FileVault is covered in [its own article](https://docs.applivery.com/en/device-management/apple/macos/policies/filevault/).

## iPhone and iPad work the opposite way to Mac

Both report here, but the question you're answering is different on each:

<table style="min-width: 75px;"><colgroup><col style="min-width: 25px;"><col style="min-width: 25px;"><col style="min-width: 25px;"></colgroup><tbody><tr><th colspan="1" rowspan="1"><p></p></th><th colspan="1" rowspan="1"><p>iPhone / iPad</p></th><th colspan="1" rowspan="1"><p>Mac</p></th></tr><tr><td colspan="1" rowspan="1"><p>Is encryption a setting?</p></td><td colspan="1" rowspan="1"><p>No — it's always in the hardware</p></td><td colspan="1" rowspan="1"><p>Yes — FileVault</p></td></tr><tr><td colspan="1" rowspan="1"><p>What you do about it</p></td><td colspan="1" rowspan="1"><p><strong>Verify</strong> it</p></td><td colspan="1" rowspan="1"><p>Enable it, then verify it</p></td></tr><tr><td colspan="1" rowspan="1"><p>What makes it effective</p></td><td colspan="1" rowspan="1"><p>The passcode</p></td><td colspan="1" rowspan="1"><p>FileVault being on</p></td></tr><tr><td colspan="1" rowspan="1"><p>What to check</p></td><td colspan="1" rowspan="1"><p>Hardware capabilities <code>3</code> + passcode present</p></td><td colspan="1" rowspan="1"><p>FileVault enabled + a recovery key exists</p></td></tr></tbody></table>

The practical consequence: on an iPhone, "not encrypted" is really "no passcode", and you fix it with a [Passcode configuration](https://docs.applivery.com/en/device-management/apple/apple-policies/passcode/). On a Mac, it's a FileVault problem and you fix it there.

## What Security info does not tell you

**There is no jailbreak or integrity status for iOS.** Apple's MDM protocol simply doesn't expose one — no MDM in the market can report it, Applivery included. The two integrity-related values that exist in this response, Secure Boot and System Integrity Protection, are **macOS-only** and return nothing on an iPhone or iPad.

If your requirements include detecting compromised Apple Devices, that has to come from a third-party **Mobile Threat Defense** solution.