FileVault on Apple Silicon: Encryption, Keys and Boot Security

FileVault is the first control on every macOS hardening checklist, and it is also one of the most misunderstood. On modern Macs the storage is encrypted whether or not you ever touch the FileVault switch, so the real question is not "is the disk encrypted?" but "who holds the key that unlocks it?". This guide explains what FileVault actually does on Apple silicon and T2 Macs running macOS 15 Sequoia and macOS 26 Tahoe, how to enable it and manage recovery keys with fdesetup and MDM, and how the surrounding boot protections (Startup Security Utility, Activation Lock and, on Intel, the firmware password) complete the picture.

How encryption works on Apple silicon and T2 Macs

On Macs with Apple silicon or the Apple T2 Security Chip, the internal SSD is connected to a dedicated AES engine managed by the Secure Enclave. Data on the internal volumes is always encrypted with keys that are bound to that specific hardware, which is why pulling the NAND chips out of a Mac is not a useful attack.

Without FileVault, however, the volume encryption key is only protected by the hardware. The Mac can unlock the data volume at boot on its own, so anyone who can power it on and reach a login window (or boot a different OS where allowed) is working against an already-unlocked data volume.

Turning FileVault on adds a user secret to the key hierarchy. The volume key is then wrapped by keys derived from the passwords of FileVault-enabled users, and the Secure Enclave enforces rate limiting on guesses. Because the data is already encrypted, enabling FileVault on these Macs is effectively instant: there is no lengthy background conversion like on older Intel Macs without a T2.

Enabling FileVault

Interactively

Individual users can enable FileVault in System Settings > Privacy & Security > FileVault. During setup, macOS asks how the user wants to be able to unlock the disk if the password is forgotten: either through their Apple Account (iCloud) or with a locally generated recovery key.

From the command line

fdesetup is the supported command-line tool. It must run as root and will prompt for the credentials of a user who will be enabled for FileVault:

sudo fdesetup enable

When it finishes, it prints a personal recovery key in the form of six groups of four characters. Treat that output as a secret: record it in your password manager or escrow system, and do not leave it in shell history or ticket logs.

Deferred enablement

In a managed environment you usually do not have the user's password at deployment time. Deferred enablement solves this: FileVault is turned on the next time the user logs out or logs in, and macOS prompts for the password at that moment.

sudo fdesetup enable -defer /var/root/fdesetup_output.plist -forceatlogin 0 -dontaskatlogout

Deferral is more commonly configured through an MDM profile (below), which is the recommended approach for fleets because it pairs enablement with recovery key escrow.

Recovery keys and escrow

Every FileVault-protected Mac needs a recovery path. The options are:

For organizations, the recommended pattern is a personal recovery key escrowed to MDM. Apple no longer recommends institutional recovery keys, and they are not supported for unlocking on Apple silicon. A single shared IRK is also a large blast radius: if it leaks, every Mac enrolled with it is exposed.

Apple Account unlock is convenient for individuals, but in a corporate context it moves the recovery path to an account IT does not control. Decide deliberately, and disable that option for managed Macs.

Rotating the personal recovery key

If a recovery key has been displayed to a helpdesk technician or used to unlock a Mac, rotate it:

sudo fdesetup changerecovery -personal

With an escrow profile installed, the new key is sent to MDM at the next check-in. Many MDM products can also trigger rotation automatically after a key is viewed.

MDM configuration

Two payloads cover enablement and escrow:

• com.apple.MCX.FileVault2 enables FileVault (typically deferred) and controls whether a personal recovery key is created and shown to the user.
• com.apple.security.FDERecoveryKeyEscrow escrows the personal recovery key to the MDM server, encrypted to a certificate included in the same profile.

A minimal FileVault payload looks like this:

<dict>
    <key>PayloadType</key>
    <string>com.apple.MCX.FileVault2</string>
    <key>Enable</key>
    <string>On</string>
    <key>Defer</key>
    <true/>
    <key>UseRecoveryKey</key>
    <true/>
    <key>ShowRecoveryKey</key>
    <false/>
    <key>DeferForceAtUserLoginMaxBypassAttempts</key>
    <integer>0</integer>
</dict>

Setting ShowRecoveryKey to false keeps the key out of the user's hands, and a bypass count of 0 means the user cannot postpone enablement at login. Most MDM consoles expose these as checkboxes, so you rarely need to hand-write the XML; see the MDM and configuration profiles guide for how payloads are packaged and delivered. You can additionally prevent users from turning FileVault off with the dontAllowFDEDisable key in a com.apple.MCX payload.

Startup Security Utility and boot policy

FileVault protects data at rest; startup security decides what the Mac is allowed to boot. On Apple silicon, Startup Security Utility is reached from recoveryOS (hold the power button until startup options appear, choose Options, then Utilities > Startup Security Utility). Each installed macOS volume has its own policy.

Keep production Macs on Full Security. Reduced Security is sometimes needed for legacy kernel extensions, but each such exception should be documented and time-limited. The relationship between boot policy, SIP and kernel extensions is covered in the System Integrity Protection guide.

On Intel Macs with a T2 chip, the equivalent options are Full, Medium and No Security, plus a separate setting that controls booting from external media. Leave external boot disallowed unless there is a specific operational need.

Intel firmware password

Intel Macs support a firmware password that prevents booting from other volumes or into recovery without the password. It is managed with firmwarepasswd (or in recoveryOS on T2 Macs). Apple silicon Macs do not have a firmware password; their equivalent protection comes from the requirement to authenticate as an administrator in recoveryOS, from per-OS boot policies, and from Activation Lock.

Activation Lock and Find My

Activation Lock ties a Mac with Apple silicon or a T2 chip to an Apple Account, so a stolen and erased Mac cannot be reactivated without that account's credentials. For personally owned Macs this is a strong theft deterrent. For organization-owned Macs it can become a problem: if an employee leaves with Activation Lock tied to a personal Apple Account, the device may be unusable.

Supervised Macs enrolled through Automated Device Enrollment let the MDM manage Activation Lock and hold a bypass code, which avoids that trap. If your fleet is not supervised, make sure your offboarding process includes signing out of Find My before the device is returned.

Verify it

Check FileVault state:

fdesetup status
sudo fdesetup list
sudo fdesetup haspersonalrecoverykey
sudo fdesetup hasinstitutionalrecoverykey

Expected output on a protected Mac:

FileVault is On.

Check the APFS volume view, which reports FileVault state per volume:

diskutil apfs list | grep -i filevault

Check Activation Lock status and, on Apple silicon, the current boot policy:

system_profiler SPHardwareDataType | grep -i "activation lock"
sudo bputil -d

On Intel Macs, confirm the firmware password is set:

sudo firmwarepasswd -check

Finally, confirm in your MDM console that a recovery key has actually been escrowed for each device. A Mac reporting "FileVault is On" with no escrowed key is a support incident waiting to happen.

Common pitfalls

• Assuming hardware encryption is enough. Without FileVault, the data volume unlocks without any user secret.
• Deploying the escrow payload after enablement. If the key was generated before the escrow profile arrived, it will not be in MDM. Rotate it with fdesetup changerecovery -personal once the profile is in place.
• Relying on institutional recovery keys on Apple silicon, where they are not supported for unlocking.
• Leaving Apple Account recovery on for corporate Macs, which moves recovery outside IT's control.
• Service accounts without a secure token. Only users with a secure token can be enabled for FileVault; accounts created by scripts may lack one and will not be able to unlock the disk.
• Downgrading startup security to Reduced for a single legacy driver and never reverting it.

Checklist

• FileVault on, verified with fdesetup status
• Personal recovery key escrowed to MDM, IRKs retired
• Enablement enforced at login, FileVault disable blocked by profile
• Full Security boot policy on Apple silicon; external boot disallowed on T2
• Firmware password set on remaining Intel Macs
• Activation Lock managed via supervision or covered in offboarding

Once the disk and boot chain are covered, continue with System Integrity Protection and Gatekeeper, XProtect and notarization to control what runs on the Mac after it boots.