After ADE enrollment with enable_disk_encryption: true, hosts reported
as unencrypted with the disk-encryption policy failing and no recovery
key escrowed until the user logged out/in or restarted.
## Root cause
Fleet's shared macOS disk-encryption probe was:
```
SELECT 1 FROM disk_encryption
WHERE user_uuid IS NOT "" AND filevault_status = 'on' LIMIT 1
```
On the osquery disk_encryption table, filevault_status and user_uuid
are populated from independent sources: filevault_status from
`fdesetup status`, user_uuid from `diskutil apfs listCryptoUsers`
(the UUID of a user with SecureToken authority to unlock the volume).
In the post-ADE window, even with ForceEnableInSetupAssistant=true,
SecureToken propagation can lag — filevault_status='on' but
user_uuid='' for a brief period that resolves on a session event.
When the predicate failed, the query returned 0 rows and three
downstream behaviors broke in lockstep:
- host_disks.encrypted flipped to false ("unencrypted")
- the built-in "Full disk encryption enabled (macOS)" policy failed
- mdm_disk_encryption_key_file_*_darwin returned encrypted=0,
gating the PRK ingest and leaving the recovery key un-escrowed
The predicate originated in groob's standard query library entry
from 2021 as a strict compliance check ("is the host actually
protected, with a user able to unlock it?"). When the disk-encryption
status feature shipped in Nov 2022 (PR #8526, issue #3906), the
same string was reused verbatim and later extracted into
usesMacOSDiskEncryptionQuery — never revisited for whether the
SecureToken gate made sense outside the compliance-policy context.
**Related issue:** Resolves#45369
Dante Catalfamo
2c47cee122