FileVault key escrow on ADE-enrolled Macs requires user logout or reboot

[kc9wwh]

Fleet versions

• Discovered: 4.84.2
• Reproduced: Not yet reproduced

Web browser and operating system: N/A (host-side macOS behavior, observed on Macs enrolled via ADE)

---

💥 Actual behavior

When a new Mac is enrolled via Automated Device Enrollment (ADE) on a team with enable_disk_encryption: true configured via GitOps, the FileVault recovery key is not escrowed to Fleet after the user finishes Setup Assistant and lands on the desktop. The key only escrows after the user explicitly logs out and back in (or restarts).

During this interim window, Fleet reports the host as:

• Disk encryption policy: failing
• Host disk encryption status: unencrypted (when in reality, FileVault is enabled — just the key hasn't been escrowed yet)

The admin has no signal that this is a transient state; it looks like a real disk-encryption failure.

🛠️ Expected behavior

The user should not need to log out, log back in, or reboot for Fleet to escrow the FileVault key after ADE enrollment. Either:

1. Fleet uses ForceEnableInSetupAssistant in the FileVault MDM payload so the recovery key is generated and escrowed during Setup Assistant with no user interaction needed (matches Apple's documented behavior and other MDMs' default flow), or
2. Fleet's background refetch picks up the key automatically once the user reaches the desktop, without requiring a session event.

Additionally, the disk-encryption policy and host page should suppress the "unencrypted" / failing state during the brief window between ADE completion and key escrow — matching the suppression that already exists on the My device page.

🧑‍💻 Steps to reproduce

These steps:

• Have been confirmed to consistently lead to reproduction in multiple Fleet instances.
• Describe the workflow that led to the error, but have not yet been reproduced in multiple Fleet instances.

1. Configure a Fleet team (or global) with enable_disk_encryption: true via GitOps.
2. Enroll a fresh Mac via ADE and complete Setup Assistant on the device.
3. Once the user lands on the desktop, observe the host in Fleet.
4. Observe that the disk-encryption policy reports failing and the host shows as unencrypted, even after the standard refetch interval has elapsed.
5. Observe that the FileVault recovery key is not present in Fleet (no key to view in the host details).
6. Have the user log out and log back in (or restart the Mac).
7. Observe that the key is now escrowed, the policy passes, and the host reports as encrypted.

🕯️ More info (optional)

• Apple documents ForceEnableInSetupAssistant as the supported MDM mechanism for forcing FileVault enablement during Setup Assistant with automatic key escrow: https://support.apple.com/guide/deployment/manage-filevault-with-device-management-dep0a2cb7686/web
• A Fleet code path named EnforceFileVaultSetupAssistant already exists (migration 20240725152735_EnforceFileVaultSetupAssistant.go), suggesting this flow is partially in place but not behaving as expected end-to-end for new ADE enrollments.
• Per internal discussion, a suppression was previously added so the disk-encryption banner does not appear for a window after ADE enrollment, allowing Fleet's background refetch to pick up the key without user interaction. That suppression may have only been applied to the My device page and not the Hosts page / policy results.
• Other MDMs (e.g., Jamf) do not require a logout/login for key escrow after ADE — this is a regression in expected experience vs. the customer's prior MDM.
• The customer's explicit ask: "the user should not be seeing a policy fail and show unencrypted when in reality it's 'in progress'."