FileVault on macOS Tahoe uses iCloud Keychain to store its Recovery Key
In macOS 26 Tahoe, Apple has updated how it manages encryption keys in FileVault, the feature that protects your Mac’s data volume by encrypting it. Users with existing choices won’t be immediately impacted, but eventually everyone will need to use the new approach—which I think is an improvement. But if you rely on Apple to hold on to your Recovery Key for you, it’s time to start considering a new strategy.
The modern version of FileVault first appeared way back in Mac OS X 10.7 Lion. (The first version of FileVault only encrypted your Home directory.) Today’s FileVault provides both boot protection and disk protection: you have to enter an account password before the operating system loads, and passing that stage unlocks an encryption key that provides access to the otherwise fully locked-down startup volume’s contents.
When you set up FileVault, macOS generates a Recovery Key for you. Normally, you decrypt the disk by logging in with your password, but if the portion of your drive containing login data becomes corrupted, the Recovery Key is the only alternate path to decrypting your data. This is a really rare failure, but if it happens, there needs to be an alternate path to recovery. That’s the Recovery Key.
Previously, you had two choices for how to store that key: You could view it once, ever, and be sure to write it down (or more properly, stick it in a password manager). Or you could opt to use iCloud escrow, where the key was stored as part of your data on Apple’s servers without strong security—anyone with Apple Account access could retrieve it from a locked Mac. Apple has changed the iCloud option in Tahoe, boosting security and changing how it’s accessed, which I am sure it did for better overall security and privacy.
However, this change means you are much more responsible for managing a critical recovery component with FileVault active. There’s some nuance to this, as I discuss ahead.
Encrypt the whole thing
People used to be paranoid about someone stealing the contents of their hard disk drive. Maybe it was a fear of actual theft—someone stealing a computer from a business or home—but the big bugbear was you leaving a laptop behind or having it stolen from you while out and about. Only truly endangered or overworried people thought a criminal or government agent would enter their home and try to siphon their data—and, sometimes, that did occur!
The solution to this, in part, is full-disk encryption (FDE), where your entire drive is encrypted. This requires cleverness: some kind of post-boot but pre-full-operating-session mode had to be developed where a disk could be mounted and encrypted the first time, and then prompt for a key and be decrypted on subsequent boots and restarts.1
Encrypting an entire drive could be incredibly slow. However, this tedious operation typically happened once. After the entire drive’s contents were first encrypted, reading and decrypting or writing and encrypting provided a speed hit, but not much. (Spinning hard drives were already so slow that it was hard to notice the difference.) Some drive manufacturers even built FDE into their hardware, which sped things up until chip makers built encryption circuits into their CPUs, at which point operating systems could handle the whole thing speedily. Add the shift to SSDs into the mix, and fully encrypted drives read and write nearly as fast as fully exposed ones.
Ultimately, Apple decided to encrypt its computers’ startup drives all the time, first with the T2 Security Chip for later Intel models, and then as part of all M-series Apple silicon Macs. FileVault for those models is a boot-protection system; the encryption comes free and cannot be disabled.2
A Potemkin Village of a startup screen
On Apple silicon Macs, FileVault offers operating-system-based FDE with a clever twist. With FileVault enabled, you no longer start up into macOS—it might seem that way, but that’s not what happens! Instead, the low-level boot process presents a screen that looks exactly like the login window—the macOS startup screen. When you enter your account password, the boot program validates it against a special data store, then unlocks your user data volume and boots the system seamlessly.3
Here’s how it works:
- When setting up FileVault at System Settings > Privacy & Security > FileVault, you might be asked to deem which accounts are available when starting up, and be prompted to enter the password. For each account, that password is used to wrap the encryption key for the volume, and then the cryptographically protected version of the password is cached in the recovery partition. (You may still be asked this today; it has to do with a very tweaky secure token issue.)
-
The next time you restart, now with FileVault enabled, you can only log in with an account that was set up with FileVault—those are the only ones that will be listed—though that might be all of your accounts. Once you choose an account and enter its password, the next stage takes place.
-
The boot process’s FileVault component validates the password against its cache. It uses that to unlock the encryption key for the startup volume, passing that along with authentication for the macOS account to the primary macOS system.
This hidden and mildly complicated handoff just works—until it doesn’t. The data that the boot partition accesses can be erased or its data corrupted. Who knows why! Or, more improbably, you have forgotten the password for any account that would let you log in—perhaps you hadn’t used that Mac for a while and failed to make a note in a password manager of the account’s password. But then you would find yourself without a way to unlock your startup volume.4
Apple prepared for that by creating something called the FileVault Recovery Key. This special key can unlock the drive’s encryption key when all else fails. But how can you ensure you always have that Recovery Key?
When setting up FileVault, you used to be presented with two choices:5
- View the Recovery Key, write it down, and keep it safe. It’s never presented again.6 (But as long as you can log in, you can toggle FileVault and get a new key.)7
-
Use your iCloud account to store the key in escrow. However, the key is not end-to-end encrypted, so there was always the slight potential that the key could be recovered by anyone who gains access to your Apple Account and unlocks that escrow.
Neither choice was great; I always opted for the first. Apple apparently now agrees, perhaps because we are in a time of heightened government and criminal exfiltration of private data, often without warrants or judicial oversight, even in democratic nations. The company hasn’t said this, but I can read the writing on the wall.
Now the key can be shown after it’s first created, which makes it easier to retrieve it without cycling FileVault off and on to regenerate the Recovery Key. And, instead of using basic Apple Account encryption, protected just by a password, the Recovery Key is now stored in your end-to-end encrypted iCloud Keychain and accessible via the Passwords app.
The loss of Apple Account-based iCloud escrow means that you have to pay more attention to where the Recovery Key is stored. If your password can’t unlock your Mac, you can’t just log into your Apple Account: you need access to another trusted device, if using iCloud Keychain; or you need to have written down or stored the Recovery Key in a password manager that you can reach.
Keep it secret, keep it safe
I was surprised in updating Take Control of Securing Your Apple Devices for Tahoe (see below) to find FileVault’s interface had changed! It had been static for years. Once I scratched at the surface, I saw what Apple had done:
- Your previous choices are preserved. If you wrote the key down or used iCloud escrow, this remains in place.
- If you are setting up a new Mac, reinstalling macOS, or disabling and re-enabling FileVault, you must use the new method.
In Tahoe, when the key is generated, it’s not shown and then discarded. Rather, it remains permanently available. Just click the Show button and use Touch ID or enter your account password, and it’s displayed again.
You can also find the Recovery Key in Passwords. With iCloud Keychain enabled, you can access it from other devices. At this writing, Passwords in macOS shows a complete entry with details including the Mac’s serial number (blurred for privacy in figure), while Passwords in iOS and iPadOS has a rudimentary entry that identifies it as a new Recovery Key password type but lacks identifying details—it contains only the Recovery Key.
I don’t believe this new approach provides any less security. If someone approached your unlocked Mac or another of your devices, they would still require your fingerprint for Touch ID, face for Face ID, or knowledge of the password used to start up the computer or device in the first place. Sheer proximity doesn’t let them magically extract your FileVault Recovery Key.
I appreciate that you can now recover the key without turning FileVault off and on, as well as access it from other devices with the protection of end-to-end encryption. This makes the whole approach friendlier, if boot protection could be described that way.
But it also puts key retention more fully in your court. If you formerly used iCloud escrow storage and turn FileVault off and back on, or are required to after a reinstallation, take special care that the Recovery Key is either in iCloud Keychain, in another pasword manager, or even written down securely and in a safe or other secure area. In any case, ensure you can access the key if your Mac won’t let you start up into your account.
For further reading
My book Take Control of Securing Your Apple Devices explains FileVault in great depth, along with a lot of other highly useful information for keeping your iPhones, iPads, and Macs secure when in your possession or not, as well as protecting your passcode and passwords. A new edition came out just days ago with updates for iOS 26, iPadOS 26, and macOS 26!
[Got a question for the column? You can email glenn@sixcolors.com or use /glenn in our subscriber-only Discord community.]
Update: I discovered through a post by software developer Jeff Johnson after this column was published that Apple had added iCloud Keychain syncing! This isn’t noted in documentation, nor did I (nor colleagues I consulted) see the startup screenshot Jeff did. This column now incorporates that information. Thanks, Jeff!
- Of course, when you make backups, those are created from the unencrypted files, so your backups have to be protected separately. This can include setting an encryption key, something you can easily do with Time Machine—but then store that encryption key somewhere secure. ↩
- Look, I am sure there is some horrible deep-dive way to turn off decryption, but let’s pretend there isn’t, as there’s no reason for a regular user to ever do that. ↩
- When Apple split the system files and data files from a startup volume into two separate partitions several versions ago, it made the system files immutable and cryptographically protected. It no longer needed to protect those files further with FileVault. So only your data volume needs to be—and is—encrypted, including any account-related information. ↩
- If you have FileVault disabled, when your Mac starts up, it unlocks the startup volume without any additional account protection. (It’s still encrypted, but only via a key based on your Mac’s hardware identifier—helpful if your SSD chip is separated from your Mac, but only then.) The login window you see then is just the normal macOS session starter. ↩
- As of this writing, Apple’s updated Tahoe support page for FileVault contains out-of-date information that doesn’t match the Tahoe release version. ↩
- Many forms of encryption that rely on a key have a system generate the key but then store a cryptographically transformed—or “hashed”—version of it, so that the original key isn’t retained with the encrypted data. To unlock the encryption, the original key must be presented, which is then transformed and matches the stored hash. Apple used to throw away the Recovery Key for that reason. ↩
-
You can check whether the Recovery Key you have stored for your Mac is valid by entering
sudo fdesetup validaterecoveryat the command line, pressing Return, entering your account password, and pasting in the key. If it’s accurately stored, you seetrue; otherwise,false. ↩
[Glenn Fleishman is a printing and comics historian, Jeopardy champion, and serial Kickstarterer. His latest books are Six Centuries of Type & Printing (Aperiodical LLC) and How Comics Are Made (Andrews McMeel Publishing).]
If you appreciate articles like this one, support us by becoming a Six Colors subscriber. Subscribers get access to an exclusive podcast, members-only stories, and a special community.