On a Mac with Apple silicon or a T2 chip, the internal APFS storage is already encrypted by hardware. What does turning on FileVault actually change, and what does it not protect against?

seniorshould knowfreq 42%

answer

encrypted already, but by whose key
the question is who can unlock
credentials enter the key hierarchy
that is why it stops at the login window
nothing is protected while unlocked

basics

~20 s

FileVault binds the APFS volume's encryption key to user credentials, so the data cannot be unlocked without someone authenticating. The hardware already encrypts at rest; without FileVault the keys are released without a password. It protects nothing on a running, unlocked machine.

solid answer

~50 s

On those Macs the storage controller encrypts everything written to the internal SSD regardless of settings, so "is it encrypted?" is the wrong question — the right one is who can unlock it. Without FileVault, the keys that unwrap the APFS volume key are released without any user credential, so anyone who can start the machine reaches the data. Turning FileVault on makes the volume key's protection depend on a user password (or a recovery key), so the Data volume stays locked until someone authenticates at the login window — which is why a FileVault Mac cannot fully boot to a desktop unattended. Because the data was already encrypted, enabling it is near-instant on these machines; on pre-T2 Intel Macs it triggers a real background conversion. The limit is important: FileVault is at-rest protection only. Once the volume is unlocked, every process that gets past the OS's own access controls sees plaintext, so it does nothing against malware, a stolen unlocked laptop or a compromised admin account.

On those Macs the storage controller encrypts everything written to the internal SSD regardless of settings, so "is it encrypted?" is the wrong question — the right one is **who can unlock it**. Without FileVault, the keys that unwrap the APFS volume key are released without any user credential, so anyone who can start the machine reaches the data. Turning FileVault on makes the volume key's protection depend on a user password (or a recovery key), so the Data volume stays locked until someone authenticates at the login window — which is why a FileVault Mac cannot fully boot to a desktop unattended. Because the data was already encrypted, enabling it is near-instant on these machines; on pre-T2 Intel Macs it triggers a real background conversion. The limit is important: FileVault is at-rest protection only. Once the volume is unlocked, every process that gets past the OS's own access controls sees plaintext, so it does nothing against malware, a stolen unlocked laptop or a compromised admin account.

code

bash · 1 line

bash

fdesetup status

go deeper

for a junior

Know that FileVault means the Mac's data cannot be read without a user password, and that a recovery key exists precisely because a forgotten password otherwise means lost data.

for a middle

Explain the key hierarchy: file and volume keys are wrapped by a key that user credentials unwrap, so FileVault changes who can unlock rather than whether the bytes are ciphertext.

for a senior

Reason about the threat model — at-rest protection for a lost or stolen machine, no protection once unlocked — and about operations: escrowed recovery keys, why boot needs an authenticated user, and what changes for unattended servers.

for a principal

Own the fleet decision: mandatory FileVault with escrowed keys versus the availability cost of machines that cannot boot unattended, and be clear about which risks it genuinely retires.

Reframing the question

On Macs with a T2 chip or Apple silicon, the internal SSD's controller encrypts everything written to it, using keys the Secure Enclave manages, whether or not the user has ever heard of FileVault. So the naive framing — "FileVault encrypts my disk" — is wrong on modern hardware. The bytes on the flash are ciphertext either way.

The real question is what is required to unwrap the keys, and that is precisely what FileVault changes.

The key hierarchy

APFS encryption is a native, per-volume property with a layered key structure. In outline: file contents are encrypted under data keys; those are protected by a volume-level key; and the volume key is itself wrapped by a key-encryption key. Nothing in the hierarchy is stored in the clear — everything hinges on what unwraps the top.

FileVault off. The wrapping key is available to the hardware without any user credential. Start the machine and the volume unlocks; the encryption is doing real work against someone who desolders the flash, but nothing against someone holding the whole computer.
FileVault on. The user's password (and alternatives such as the recovery key) becomes a required input to unwrap the volume key. Nothing on the Data volume can be read until someone authenticates.

This is why enabling FileVault on these machines is nearly instantaneous: no data is re-encrypted, only the key hierarchy is re-wrapped. On a pre-T2 Intel Mac, where data really was stored unencrypted, enabling it kicks off a genuine background conversion that reads and rewrites the volume.

The visible consequence at boot

A FileVault Mac cannot reach a logged-in desktop by itself, because the volume holding the user data is locked until credentials arrive. Boot proceeds far enough to present a login window — supported by the small Preboot volume in the container, which holds what is needed to authenticate and unlock — and stops there.

For a laptop that is the intended behaviour. For a Mac used as an unattended build machine or server it is an operational fact to plan around: after a power cut it will sit at the login window until someone unlocks it. Trading that away by turning FileVault off is a decision to make deliberately, with the threat model written down.

What it protects, precisely

FileVault is at-rest protection. It is effective against:

A machine lost or stolen while shut down.
Storage removed from the machine and read elsewhere.
A device retired or resold: destroying the keys makes the data unreadable, which is why a cryptographic erase is fast rather than a multi-hour overwrite.

It is not effective against anything that happens while the volume is unlocked:

Malware or a malicious process running as the signed-in user, which the filesystem serves plaintext like any other reader.
A laptop stolen while open and logged in.
A compromised administrator account, or an attacker who can coerce a password.

Candidates who describe FileVault as "protecting the data" without that boundary are the ones interviewers are filtering for.

Key escrow, which is the real deployment question

Because the data becomes cryptographically dependent on credentials, losing every unlock path means losing the data outright. Deployments therefore choose an escrow strategy up front: a personal recovery key the user must store, iCloud-based recovery, or an institutional/MDM-escrowed key held by the organisation. Each is a different trade between user autonomy, helpdesk workload and insider risk — and none of them can be retrofitted after the password is forgotten.

Scope

FileVault applies to the startup volume group. External drives are a separate matter: APFS supports encryption as a per-volume property, so an external volume is protected only if it was created or converted encrypted, and hardware storage encryption in the Mac does not extend to media whose controller lives elsewhere.

The answer in one breath

"The data is already ciphertext on the flash; FileVault decides whether unwrapping the key needs a person. It turns on almost instantly because only the key hierarchy is re-wrapped, it is why the Mac stops at a login window after a reboot, and it protects a powered-off machine — not a running one."

## Reframing the question On Macs with a T2 chip or Apple silicon, the internal SSD's controller encrypts everything written to it, using keys the Secure Enclave manages, whether or not the user has ever heard of FileVault. So the naive framing — "FileVault encrypts my disk" — is wrong on modern hardware. The bytes on the flash are ciphertext either way. The real question is **what is required to unwrap the keys**, and that is precisely what FileVault changes. ## The key hierarchy APFS encryption is a native, per-volume property with a layered key structure. In outline: file contents are encrypted under data keys; those are protected by a volume-level key; and the volume key is itself wrapped by a key-encryption key. Nothing in the hierarchy is stored in the clear — everything hinges on what unwraps the top. - **FileVault off.** The wrapping key is available to the hardware without any user credential. Start the machine and the volume unlocks; the encryption is doing real work against someone who desolders the flash, but nothing against someone holding the whole computer. - **FileVault on.** The user's password (and alternatives such as the recovery key) becomes a required input to unwrap the volume key. Nothing on the Data volume can be read until someone authenticates. This is why enabling FileVault on these machines is nearly instantaneous: no data is re-encrypted, only the key hierarchy is re-wrapped. On a pre-T2 Intel Mac, where data really was stored unencrypted, enabling it kicks off a genuine background conversion that reads and rewrites the volume. ## The visible consequence at boot A FileVault Mac cannot reach a logged-in desktop by itself, because the volume holding the user data is locked until credentials arrive. Boot proceeds far enough to present a login window — supported by the small **Preboot** volume in the container, which holds what is needed to authenticate and unlock — and stops there. For a laptop that is the intended behaviour. For a Mac used as an unattended build machine or server it is an operational fact to plan around: after a power cut it will sit at the login window until someone unlocks it. Trading that away by turning FileVault off is a decision to make deliberately, with the threat model written down. ## What it protects, precisely FileVault is **at-rest** protection. It is effective against: - A machine lost or stolen while shut down. - Storage removed from the machine and read elsewhere. - A device retired or resold: destroying the keys makes the data unreadable, which is why a cryptographic erase is fast rather than a multi-hour overwrite. It is *not* effective against anything that happens while the volume is unlocked: - Malware or a malicious process running as the signed-in user, which the filesystem serves plaintext like any other reader. - A laptop stolen while open and logged in. - A compromised administrator account, or an attacker who can coerce a password. Candidates who describe FileVault as "protecting the data" without that boundary are the ones interviewers are filtering for. ## Key escrow, which is the real deployment question Because the data becomes cryptographically dependent on credentials, losing every unlock path means losing the data outright. Deployments therefore choose an escrow strategy up front: a personal recovery key the user must store, iCloud-based recovery, or an institutional/MDM-escrowed key held by the organisation. Each is a different trade between user autonomy, helpdesk workload and insider risk — and none of them can be retrofitted after the password is forgotten. ## Scope FileVault applies to the startup volume group. External drives are a separate matter: APFS supports encryption as a per-volume property, so an external volume is protected only if it was created or converted encrypted, and hardware storage encryption in the Mac does not extend to media whose controller lives elsewhere. ## The answer in one breath "The data is already ciphertext on the flash; FileVault decides whether unwrapping the key needs a person. It turns on almost instantly because only the key hierarchy is re-wrapped, it is why the Mac stops at a login window after a reboot, and it protects a powered-off machine — not a running one."

Why does enabling FileVault finish almost immediately on a modern Mac but take hours on an older Intel one?
Because on T2 and Apple silicon Macs the data is already encrypted with hardware keys, so enabling FileVault only re-wraps the existing key hierarchy so that unwrapping requires user credentials — a metadata-scale operation. A pre-T2 Intel Mac stores plaintext until you ask for encryption, so it must read and rewrite the whole volume in the background, which takes as long as the disk is large.
If a user forgets their password on a FileVault Mac, why can the data be unrecoverable?
Because the key that unwraps the volume is protected by credentials. If no other unlock path was provisioned — the recovery key, iCloud recovery, an institutional or MDM-escrowed key, or another enabled user — there is nothing left to derive the key from, and the data is cryptographically gone. That is why key escrow is a deployment decision to make before rollout, not after the first lost password.
Does FileVault protect an external USB drive plugged into the Mac?
Not by itself. FileVault applies to the startup volume group; an external APFS volume is encrypted only if you encrypt it, which APFS supports natively as a per-volume property. External media is where hardware storage encryption does not help either, since the drive's controller is outside the Mac's security model — so external volumes need explicit encryption and their own key handling.

saying these in an interview costs you the question

Says FileVault is what encrypts the disk in the first place
Claims FileVault protects data on a running, unlocked machine
Thinks enabling it always requires a long conversion pass
Assumes the recovery key is optional with no consequences
Believes it defends against malware running as the logged-in user

On a Mac with Apple silicon or a T2 chip, the internal APFS storage is already encrypted by hardware. What does turning on FileVault actually change, and what does it not protect against?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Reframing the question

The key hierarchy

The visible consequence at boot

What it protects, precisely

Key escrow, which is the real deployment question

Scope

The answer in one breath

▾common follow-ups3 questions

▾red flags5 flags

§ context

▾related questions3 questions

▾related topics3 topics

Reframing the question

The key hierarchy

The visible consequence at boot

What it protects, precisely

Key escrow, which is the real deployment question

Scope

The answer in one breath

answer

go deeper

context