What is FileVault disk encryption?

Most IT security conversations start with the network perimeter. With firewalls, MFA, and endpoint detection, the assumption is that the threat is coming from outside, over the wire. The problem is that a strong login password doesn’t help when someone pulls the drive and reads it on another machine and a stolen laptop bypasses all of it. Around 76% of organizations have been impacted by incidents of device theft in the past two years, leading to data breaches and legal consequences.

FileVault is Apple’s answer to that specific problem. It encrypts the entire startup disk so that the data is unreadable without proper authentication at boot, regardless of how the drive is accessed. This post covers what FileVault actually does under the hood, how it differs across Mac hardware, how to enable and manage it correctly, and what recovery looks like when things go wrong.

The problem FileVault solves

A login password is designed to stop someone from using your Mac, but it’s not designed to stop someone from reading your data. Those are two different threat models, and many Mac users treat them as the same thing, but account-level authentication only protects the macOS interface. If an attacker sits down at a running Mac and doesn’t know the password, they can’t log in through the normal boot process. That is the extent of the protection, but it says nothing about what happens when the device leaves the building.

A determined attacker with physical access to an unencrypted Mac has options that bypass the login screen entirely, such as:

• Target Disk Mode lets them mount the drive on another machine and browse it like an external hard drive.
• Booting from an external volume lets them access the filesystem without ever touching the user’s credentials.
• Removing the drive and connecting it directly to another system works the same way.

None of these require knowing the password since the login screen is simply not in the path. This is the problem FileVault was built to address. By encrypting the entire startup disk with XTS-AES-128, FileVault extends the protection boundary from the macOS interface down to the physical storage itself.

Which environments actually need it?

FileVault is not equally critical for every Mac in every environment. A device’s risk depends on two variables: the sensitivity of the data on the device, and the probability that the device ends up in the wrong hands.

These are the environments where FileVault is non-negotiable:

• Remote and hybrid workers whose laptops travel regularly to client sites, airports, hotels, co-working spaces, and vehicles. These are the scenarios where device theft is most likely, and where the data on the machine could include credentials, client files, or access to company systems.
• Regulated industries like healthcare, finance, and government where full-disk encryption is frequently a compliance requirement, not just a best practice. HIPAA, PCI-DSS, and various government frameworks either mandate or strongly imply encryption at rest for devices handling sensitive data.
• Any device carrying PII, financial records, or credentials regardless of role. The sensitivity of the data matters more than the job title of the person carrying it.
• Corporate laptops issued to field staff or executives since higher mobility means higher exposure and executives tend to carry devices with broad system access.

How FileVault works

Enabling FileVault doesn’t just put a password on your files. It rewrites the entire security model for data at rest on the device. Understanding what’s actually happening is crucial for IT teams making deployment decisions, troubleshooting encryption issues, and explaining to stakeholders why full-disk encryption is meaningfully different from account-level access control.

The encryption architecture

Through XTS-AES-128 encryption, every sector on the disk is encrypted. Nothing at rest is left in plaintext, covering:

• User documents
• System files
• Application data
• Swap memory
• Temporary caches

The key architecture has two layers. When FileVault is enabled, macOS generates a volume encryption key (VEK) that is responsible for encrypting and decrypting disk data during operation. That VEK is itself encrypted by a key encryption key (KEK), which is derived from the user’s login password.

On Macs with a T2 chip or Apple Silicon, the KEK lives inside the Secure Enclave, a dedicated security processor that is physically separate from the main CPU and can’t be accessed by software alone. The keys never leave the hardware in usable form.

At boot, the sequence works like this: The user enters their password > macOS uses it to unlock the KEK inside the Secure Enclave > the KEK decrypts the VEK > the kernel uses the VEK to transparently decrypt disk reads and encrypt disk writes for the rest of the session.

Intel vs. Apple Silicon: why the hardware difference matters

FileVault’s core encryption logic is consistent across Mac hardware, but the key storage and unlock mechanisms differ in ways that have practical implications for IT:

• On Intel Macs without a T2 chip (pre-2018 models), FileVault relies on software-based key management. The encryption still works, but key material is more exposed to physical extraction attacks, including cold-boot attacks that read memory contents before they clear.
• Intel Macs with a T2 chip improved on this significantly by moving key storage into the Secure Enclave, bringing them much closer to Apple Silicon behavior.
• Apple Silicon Macs (M1 and later) integrate the Secure Enclave directly into the SoC. The result is tighter hardware-software integration, faster unlock at boot, and stronger resistance to physical key-extraction attacks. Cold-boot attacks and direct memory extraction techniques that would probably work on older Intel hardware have no equivalent path on Apple Silicon.

How to enable, manage, and recover FileVault

Understanding what FileVault does is the easy part. Enabling it and managing potential issues is where most IT teams run into problems.

Here are the things you need to keep in mind and the steps you need to follow.

Multi-user environments, remote management, and backups

FileVault’s interaction with macOS features has important nuances that catch teams off guard in practice:

• Multiple user accounts: Each account must be explicitly authorized to unlock the disk. A user with valid macOS credentials who was not added during FileVault setup or added afterward via System Settings will not appear at the pre-boot login screen and cannot unlock the volume. This is a common misconfiguration in environments where accounts are created via command line, because command-line-created accounts may not receive a Secure Token automatically, and without a Secure Token an account cannot be authorized for FileVault. Run fdesetup list in Terminal to verify which accounts are currently authorized.
• MDM and Apple Business Manager: In managed environments, FileVault should be enforced via MDM policy rather than enabled manually. MDM allows organizations to enforce encryption, escrow institutional recovery keys centrally, and verify FileVault status across the fleet without touching individual devices. This is the correct approach for any organization managing more than a handful of Macs since it removes the dependency on individual users making the right choice and ensures keys are retrievable if a user forgets their password or leaves the organization.
• Backups: Time Machine works with FileVault without any special configuration. The backup captures decrypted file data during the backup process, so the backup itself may or may not be encrypted depending on your Time Machine destination settings. During device migration via Migration Assistant, FileVault status is preserved or re-enabled on the target Mac, maintaining encryption continuity across hardware transitions.

» Make sure you know how to enable RMM on Mac

Step-by-step guide to enabling FileVault

Before enabling FileVault, a few prerequisites need to be in place. The account enabling FileVault must have administrator privileges and the Mac should be connected to power since initial encryption is a background process that can run for hours on large drives. An interrupted encryption on a failing battery creates problems and could brick your system. If you plan to store the recovery key in iCloud, you’ll need a stable network connection.

Then, follow these steps:

1. Open System Settings: Navigate to Privacy & Security, then scroll to the FileVault section.

2. Click Turn On: macOS will prompt you to select which users are authorized to unlock the disk. This step matters since any user account not explicitly authorized here will be unable to unlock the volume, even with valid credentials.

3. Choose your recovery key storage method: You can store it in iCloud tied to the user’s Apple ID, or generate a local recovery key to store yourself. In managed environments, MDM handles this through institutional key escrow.

4. Confirm and let encryption run: macOS begins encrypting in the background, but the system remains fully usable during this process.

During initial encryption, macOS generates the VEK, encrypts it with the KEK derived from the user’s password, and stores key material in the Secure Enclave on T2 and Apple Silicon Macs. You can check progress at any time by returning to System Settings > Privacy & Security > FileVault.

WARNING: FileVault generates a 24-character alphanumeric recovery key during this initial setup. This key is the fallback if the user’s login password fails. If you lose it, you risk being locked out of the device permanently. The correct practice for managed fleets usually involves enforcing FileVault via MDM, escrowing institutional keys centrally, verifying escrow status regularly, and treating recovery key management as an auditable process rather than a one-time setup step.

For most users, FileVault is invisible after the initial setup, but you might notice some operational differences:

• Startup requires a password before the system boots: This adds a step compared to non-encrypted Macs, but it is the only meaningful change to normal workflow. Standard sleep and wake cycles remain seamless and system updates work normally.
• Third-party tools that access the disk directly need the encryption key: Time Machine handles FileVault transparently because it operates at the volume level. Tools that attempt raw disk access (some backup utilities, imaging software, forensic tools, etc.) require the user’s password or recovery key to read the volume.

Disabling FileVault and decryption risks

Disabling FileVault follows the reverse path: System Settings > Privacy & Security > FileVault > Turn Off FileVault. macOS begins a background decryption process that progressively rewrites disk sectors in plaintext. The system remains usable throughout, and a progress indicator shows decryption status.

Make sure you have a stable power connection first and be aware of these possible risks:

• Power loss or forced shutdown during decryption can leave the volume in a partially decrypted state, causing boot issues or data corruption. Keep the Mac connected to power for the full duration.
• Hardware failure during decryption (particularly on aging SSDs) can leave the volume unreadable. Verify backups before starting decryption on any device with known hardware concerns.
• Recovery tools may behave unpredictably if decryption is incomplete. Time Machine and Migration Assistant can fail if the volume state is inconsistent.

» Worried about your SSD? Here’s how to check SSD health

FileVault is only as strong as how you manage it

FileVault solves a specific, underappreciated problem: it makes stolen hardware useless to whoever took it. That’s a meaningful guarantee, but it’s contingent on recovery key management. Encryption without a retrievable key is just permanent data loss with extra steps. For teams managing Mac fleets at scale, the question isn’t whether to enable FileVault; it’s whether the keys are escrowed, the authorized users are correct, and the MDM policy is enforced consistently across every device.

Atera’s RMM platform gives IT teams and MSPs centralized visibility across Mac, Windows, and Linux endpoints, so the devices that need FileVault enforcement don’t slip through the cracks. When physical security and endpoint management work together, a missing laptop stays a hardware problem instead of becoming a breach.