Locked Down Passkey and Keychain Backups
I remain unhappy with Apple’s passkey backup story. There’s little documentation about this, but from what I can tell:
There are no automatic versioned backups. (Syncing is not backup because it doesn’t protect you against human error, bugs, or attacks.)
Even if you have a Time Machine backup, it’s not possible to restore it to the same Mac without logging into iCloud. This could be a problem if your account is locked or compromised.
Restoring it to a different Mac is impossible because the decryption key is stored in the other Mac’s Secure Enclave. Apple is protecting you from accessing your own backup, even though the keychain is already an encrypted file, protected by the password that you set. (And the Time Machine or clone drive that it’s stored on is probably encrypted, too.)
The Passwords app can now export passkeys, but you cannot create an export file that you can import back into Passwords on another Mac. You can only export to a third-party password manager that’s installed on the same Mac (which may require a working Apple account). Even then, this does not include passkeys for Apple services; they don’t show up in the Passwords app. There are also some other restrictions around shared items and Sign In with Apple.
The above is last year’s news, but I don’t think I had written it all in one place before. The new bad news is that, as of macOS 26.4, these problems now affect regular passwords, not just passkeys. (You do have more flexibility to export passwords, though.)
Historically, you could copy the login keychain file from one Mac to another and be able to open it on the destination Mac by providing the password to that keychain. As of macOS Tahoe, this does not appear to work for Macs which use Secure Enclave.
[…]
From that, it appears that unlocking the login keychain requires more than the password because the keys it unlocks are tied to the Secure Enclave of the Mac where the keychain was created. With the decryption keys stored in the source Mac’s Secure Enclave, manually copying the keychain to another Mac and then unlocking it won’t work. The password you have for the keychain may be correct, but the actual keys needed to decrypt its contents won’t be available on the destination Mac.
According to Apple, all Apple silicon Macs, as well as some Intel Mac models, have the secure enclave processor, so the issue affects millions of Mac users.
[…]
If anything happens to your Mac, if it’s stolen or becomes inoperable, your login keychain is also lost, unrecoverable, even if you have a copy of the login keychain file! This is a stunning development that has left me bewildered and irate. WTF was Apple thinking? To my knowledge, Apple did not even publicize the change in Tahoe.
[…]
How does Migration Assistant handle the situation on Tahoe? I don’t know. I would guess that since Migration Assistant still has access to the old Mac, it simply decrypts the old login keychain and copies the login keychain entries to the new login keychain on the new Mac, rather than transferring the keychain files directly.
[…]
I recommend that you open your login keychain with the Keychain Access app (now located in
/System/Library/CoreServices/Applications) and check what’s in there, the data that you’re in danger of losing. Whether you realize or it not, many apps use the login keychain. For example, Google Chrome and other Chromium browsers store passwords in the login keychain. MailMate stores email account passwords in the login keychain. The open source RSS reader Vienna stores website passwords in the login keychain. The Zoom app also uses the login keychain. My Developer ID code signing certificate is stored in the login keychain; if I’m not mistaken, I believe that Apple’s own Xcode put it there. And of course, any items that you’ve manually added to the login keychain would be lost if the keychain file could not be unlocked.
I have confirmed that a login.keychain-db copied from my Mac mini M4 Pro to a virtual machine (VM) running macOS Tahoe 26.6.2 cannot reveal any of its secrets to the Keychain Access app on the VM, as it refuses to accept the valid password. Not only that, but Keychain Access running in a VM cannot access the login.keychain-db keychain copied from another Tahoe VM, although neither has been anywhere near a Secure Enclave.
If you intend migrating manually between Macs, don’t waste time trying to copy across the login keychain, as it’s not likely to work, and its secrets will remain.
[…]
I performed test migrations between VMs, and demonstrated that Migration Assistant does copy the contents of the login keychain successfully to the destination Mac.
I think this only happens if you migrate over a network, with the old Mac acting as a server. I prefer to connect the old Mac using Target Disk Mode, but in that case Migration Assistant wouldn’t be running on the old Mac so the special sauce wouldn’t work. Likewise if I were trying to do the migration using a third-party cloning app.
- Loss of physical access to a Mac running 26.4 or later prevents access to any items stored in its login keychain.
- Hardware failure requiring logic board replacement may have the same effect on restoring the contents of its login keychain (assuming that migration from a backup doesn’t work).
- Restoring an Apple silicon Mac in DFU mode may be similar in effect.
What I don’t know yet is whether you can unlock and access any login keychain written by macOS 26.4 or later and migrated from a backup accessed directly from a different Mac. This would occur in one-Mac migration, when Migration Assistant uses a backup of a Mac not acting as a Migration server. This would only be possible if the backup also stored the additional secret required to access the login keychain, which seems unlikely.
[…]
Apple’s documentation for macOS Tahoe and the copying of keychains makes no mention of this change, in spite of its serious consequences and the change being made almost six months ago.
It there states “If you didn’t use Setup Assistant, the best way to copy your keychains to a new computer is to export and then import them using Keychain Access”. However, Keychain Access can only export some keychain items including certificates and keys, but not passwords. And to do that, the Mac must be able to unlock and access those items in the source keychain. Thus, Apple’s recommendations are out of date and will now fail.
rsUSA0 (via Jeff Johnson):
When upgrading to macos 27 Golden Gate, I erased my system through recovery to do a clean install. I planned to manually migrate data back to the computer from an external drive clone of Macintosh HD and a Time Machine backup. This has worked well in the past and eliminated system bloat.
When I manually migrated my login keychain, it opened, showed entries, but it wouldn’t accept my password to reveal any actual passwords. The window shakes like I’m using the wrong password. I’m 100% sure I’m using the correct password. I also tried every password I’ve ever used and I’m certain it’s not a password issue.
Perhaps even restoring to the same Mac failed because the clean install wiped the key stored in the Secure Enclave. [Update (2026-10-01): See update below.]
Some people who read my previous blog post misunderstood the issue, because they didn’t know that the macOS login keychain is distinct from iCloud Keychain.
[…]
In the Keychain Access app, you can see two separate default keychains, one of which is the login keychain. The other default keychain is named “iCloud” if you’ve enabled iCloud Keychain, “Local Items” if not. There’s actually a longstanding issue with this keychain analogous to the newer issue with the login keychain.
[…]
Mac users like myself who forsake iCloud Keychain face the prospect of no disaster recovery for the Local Items keychain. My habit is to manually create a new password item in the login keychain and only then supply the credentials to an app, for example, Safari AutoFill. Ironically, the login keychain change brought by macOS 26.4 sabotages my password backup procedure[…]
Today, I got my new Mac mini M6. When I started setting up the new machine, it asked me to update to macOS 27, so I followed the instructions.
[…]
After signing in to iCloud, it asked me to enter the passcode of one of my Apple devices. I entered the correct passcode and even tried the passcodes for all of my devices, but I keep getting the same message:
Verification Failed
There was an error verifying the passcode of your iPhone
I don’t like having to rely on iCloud.
Previously:
- SuperDuper’s “Follow-Up”
- macOS 26.4
- 2025 Six Colors Apple Report Card
- Locked Out of Apple Account Due to Gift Card
- Downloading Xcode With a Passkey
- iOS and iCloud Keychain Are Hostile to Backups
- Passkeys Credential Exchange
- Passkeys: A Loss of User Control?
- Fixing iCloud Keychains, and Backing Them Up
Update (2026-10-01): TN3137 has been updated for macOS 26.4:
Historically each file-based keychain was a standalone file. You could, for example, copy a keychain file from one Mac to another and still use it, as long as you knew the keychain password.
In macOS 26.4 and later that’s no longer the case. A keychain file might reference a protected entropy file. To unlock such a keychain you need both the keychain password and the protected entropy file.
[…]
These protected entropy files are stored in /var/db/SystemKeys. If you’re creating a backup product, make sure to back up that directory. Without it, the keychain files that you back up might be useless.
[…]
The /var/db/SystemKeys directory is not directly accessible, even when running as root, so you can’t copy a protected entropy file in the normal way. To access it, disable System Integrity Protection (SIP).
First things first: I don’t think turning off SIP every time you make a backup is a real solution. And I don’t understand what problem Apple is really trying to solve with protecting the entropy file; it seems like they don’t trust their own encryption. Lastly, it’s not explicitly stated, but I don’t think copying the entropy file helps with backing up passkeys.
That aside, I find the details both illuminating and confusing. This probably explains the rsUSA0 case above, where restoring to the same Mac didn’t work. The key wasn’t stored in the Secure Enclave but rather in the entropy file on the SSD, which had been wiped. This also suggests a simpler way for Migration Assistant to work; it could have special access to copy the entropy file without having to actually open the keychain.
It also seems to be saying that, if you turn off SIP and copy the entropy file, you can then access your keychain backup from another Mac. But I’m not sure how to square that with Apple’s keychain documentation:
Keychain items are encrypted using two different AES-256-GCM keys: a table key (metadata) and a per-row key (secret key). Keychain metadata (all attributes other than kSecValue) is encrypted with the metadata key to speed searches, and the secret value (kSecValueData) is encrypted with the secret key. The metadata key is protected by the Secure Enclave but is cached in the Application Processor to allow fast queries of the keychain. The secret key always requires a round trip through the Secure Enclave.
How can copying the entropy file work if the Secure Enclave is required? My guess is that the entropy file itself is encrypted (NSFileProtection) using the Secure Enclave. So accessing it on the original Mac does require going through the Secure Enclave. But when you make a backup, the entropy file gets decrypted. Maybe accessing the keychain on the second Mac causes file protection to be re-applied to the contents of /var/db/SystemKeys, so then it becomes protected by that Mac’s Secure Enclave.
Previously:
Update (2026-10-02): Dave Nanian (Mastodon):
This is obviously not a good user solution, because no one is going to boot to Recovery, turn off SIP, back up, boot back to Recovery, and turn SIP back on. Thinking they would do so is kind of crazy.
[…]
SuperDuper handles this situation. When you make a bootable copy, the required keys are copied without requiring any special steps.
SuperDuper itself can’t read the entropy file, but it uses Apple’s asr tool to make bootable backups, and that has special access. (Unfortunately, it can’t update the entropy file without making a fresh bootable backup, but in practice I don’t expect it to need updating.) I had not been bothering to make most of my backups bootable, since in most cases I just want to restore to an internal SSD, not actually boot from the backup. But I now think it makes sense to choose bootable backups as the default.
I won’t expand on my feelings any further than by saying that in my 37 years as an Apple developer, I have never come across anything so shameful.
Unfortunately, it seems like the keychain stuff was just the warm-up act.
Update (2026-10-05): Howard Oakley:
[macOS 26.4] Added the protected directory at /var/db/SystemKeys to backups of Data volumes, and protects them in backups.
So Time Machine does back up the entropy file. I missed this because I didn’t see /var/db in my backups, but it turns out that they do have /private/var/db/SystemKeys and are just missing the /var symlink.
Update (2026-10-07): Jeff Johnson:
The
-soption to thesecurity show-keychain-infois not yet documented inman security, not even on the latest version of macOS Golden Gate. Moreover, the-soption does not work on macOS Sequoia and earlier. In general, thesecurity show-keychain-infocommand reveals no information unless the specified keychain is unlocked, which makes it impossible to discover the salt of a keychain file that you can’t currently unlock. However, as long as you already have the entire contents of the /var/db/SystemKeys directory from the macOS volume on which a keychain file was created, the inability to determine the keychain file’s salt beforehand shouldn’t be much of a problem, because in practice there are typically only a few salt files, so you can simply copy them all to another macOS volume.[…]
You don’t actually have to disable SIP to add files to the /var/db/SystemKeys directory, because you can do so from another boot volume. You have to boot into recovery anyway in order to disable SIP, so you could simply edit /var/db/SystemKeys from recovery rather than disabling SIP on the non-recovery volume.
The
security unlock-keychaincommand lacks an option to specify the location of an entropy file or to provide the file data directly, so unfortunately a login keychain can’t be unlocked from the recovery volume, only from a volume where you can add files to the /var/db/SystemKeys directory.
17 Comments RSS · Twitter · Mastodon
Someone page Ricky Mondello, who works on Passwords and password management at Apple, who seems to like posting publicly about Passwords stuff. Might actually get something to change, rather than the black box that is Apple's feedback and reporting mechanisms.
The login keychain change is news to me. My Mac app uses both keychains.
One difference between the two keychains is that the login keychain works in BFU (before first unlock) state, and iCloud keychain does not. This is a sticking point for my app because it features an (optional) always-running server for network clients. If the Mac reboots (e.g. due to a software update) then it relaunches all previously-running apps in BFU state, and if the credentials were in iCloud keychain then my app couldn't access its own credentials, and therefore could not authenticate any clients, and therefore could not accept any incoming network connections. I had to put the credentials in the login keychain to avoid this.
Besides that, it's amazing to me (not in a good way) that this change was made without an announcement of any kind... I don't even know what to say to that.
A lot of Mac apps still store stuff in the login keychain. Users generally don't have any choice in the matter, and probably aren't even aware that their Mac has two different keychains that work differently. I myself wasn't aware until I ran into this BFU issue. The Keychain API docs are extremely vague about the differences between them, so I didn't find out until after much trial-and-error.
I'm sure Apple would say "well, the developers should have been using iCloud keychain instead, like the API docs recommend" but that would be failing to account for valid use cases like mine. And that still does nothing to help users who have no information about this and no way to be proactive about it.
Seems like some users are going to suffer catastrophic data loss as a result of this change, with no possibility of recovery. Thankfully I don't think it will be a huge issue for my app in particular, because in my use case, it should mostly just be a minor annoyance to reset the credentials. But others won't be so lucky.
Ruminating a bit more on this, I might actually consider this a blocker to upgrading to Golden Gate (I'm still on Sequoia, so unaffected by this particular change unless it has also occurred in one of the recent Sequoia security updates, has anyone checked on that?).
The exporting/importing dance by different password manager apps actually have a common format standard, the Credential Exchange Format documented here: https://fidoalliance.org/specs/cx/cxf-v1.0-ps-errata-20260309.html . It seems like each password manager would just need to export in this format and then maybe enclose it in an encrypted wrapper. The specification mentions "[t]he exporting provider MUST ensure the data is transferred securely by either encrypting it themselves or by relying on an orchestrator’s security guarantees". This doesn't really help with automatic backups of all your passwords, though, as happened with the login keychain + Time Machine or another backup provider of your choice.
This actually reminds me of something similar that I just got around to dealing with: secure notes in keychains. Before Apple's Notes app had secure notes and before the Passwords app, you could save arbitrary information in secure notes (different from secure notes in Notes) in any arbitrary keychain. I got into that habit for a few things, and I have about 25 secure notes still around in my iCloud Keychain. The problem is, Apple deprecated the ability to create those keychain secure notes as of Sequoia, and I had moved them to my iCloud Keychain where they were happily still synced by iCloud. However, there was no way to export them out of the iCloud Keychain, and they don't appear in Passwords. And because Apple doesn't allow the creation of keychain secure notes anymore, you can't even *copy* these items to a local keychain anymore either (I guess that's the same as creation). I found some old code that was created for exporting these keychain secure notes here: https://github.com/wincent/secure-notes-exporter . However, it doesn't work with the iCloud Keychain, and you still have to press "Allow" a bunch of times in password prompts which is really obnoxious if you have a lot of these notes. I dunno if anyone has document anything about this?
Like this new problem with passkeys and passwords in Passwords, I had to find a backup of my login keychain from a few years ago that also still had the secure notes and exported from there. I could've lost some important sensitive information! It seems like Apple has a habit of changing things regarding password storage and not notifying anyone about it even though it could bite them years later. :(
Wow, amazingly tone-deaf and obnoxious of Apple; in fact, I'd be inclined to describe this as intentional data corruption, if I weren't generally aware of Apple's MO to lock-in and lock-down at every opportunity. Regardless, you clearly can't trust Apple's Keychain infrastructure anymore, and you should just assume anything stored there is fundamentally ephemeral, and have alternative records of that data. Meantime, make that transition to another secrets manager; I happen to use Strongbox, and if it ever gets blacklisted by sites for daring to allow the end-user to expose passkey keypairs directly, I'll just stop using passkeys again. I know its owned by Applause, but they've not enshittified it yet, and I highly recommend it for native functionality; besides, the KeePass format is open and you can use KeePassXC to read it if the need ever arises.
> I'm still on Sequoia, so unaffected by this particular change unless it has also occurred in one of the recent Sequoia security updates, has anyone checked on that?
Yes, I tested with the latest Sequoia.
> Apple deprecated the ability to create those keychain secure notes as of Sequoia
There's still a way to create them: https://lapcatsoftware.com/articles/2025/1/5.html
This along with the private relay bug… how is Apple this bad at security. This isn’t excusable in any way
Simone wrote: "Someone page Ricky Mondello"
You realize that most of the links here are to Ricky Mondello posts, and follow-ups by mjtsai, right? :-)
Migration assistant prior to Golden Gate sounds like it was vulnerable to a man-in-the-middle attack.
FWIW, 1Password *6* still works more of less perfectly on Sequoia. Device-direct (with 1PW 7 on iOS) wifi syncing and all.
If you maintained proper password discipline, and NEVER trusted an Apple app / service to be THE canonical store of your passwords, would this still be a problem?
A while ago I wrote Keysafe - https://miln.eu/keysafe/ - to access and bulk export my keychain contents. It was fun to explore the file format. The file's data structure is a self describing database. I was surprised by how much metadata is exposed before any decryption is needed.
Keysafe is written in Go and is platform agnostic. Binaries are available for Mac, Linux, and Windows.
Keysafe's export option saves all it can from the keychain format. Secure notes are also supported and decoded, including RTFD with any attachments.
Sadly, Keysafe does not support macOS 26.4+ keychains because of the hardware encryption. I typically recommend people restore an older Keychain from their back-ups and use that instead. In the very worst case, password recovery might still be possible via a brute force approach https://miln.eu/keysafe/recover/
@Someone Yes, I think I’ve written before about how the keychain should be thought of as secondary storage, a cache for your real store. (I use PasswordWallet.) But I think very few people do that. And even for me it’s become the primary store for 2FA and passkeys.
Passwords have their problems, but I don't know anyone who is happy with passkeys as a solution. At least with passwords, the operation and security model is clear.
Passkeys (so far) have bad UI, bad support, and bad documentation. I've read a dozen "intro to passkeys" tutorials and I still don't understand how we're supposed to manage them, unless you want to trust your entire digital life to some cloud provider. Any time I ask how to do some basic task (like backup), I get some answer that rhymes with "You're holding it wrong".
Apple may have screwed us here, but they're not uniquely bad at passkeys. I haven't seen any company do passkeys well. They all find ways to screw it up.
"I still don't understand how we're supposed to manage them, unless you want to trust your entire digital life to some cloud provider"
Put Vaultwarden on an old computer in your closet. Install Bitwarden and connect it to your Vaultwarden instance.
It's extremely disappointing how this keychain transition was handled. I haven't relied on macOS or iCloud keychains for years to keep my secrets safe. But I feel sorry for users who will lose data because of it, even if the number is small.
Plume: It's certainly possible that one answer may be "Migrate all my passwords to a different password manager, get a spare computer up and running (and figure out backups for THAT), learn how to use Docker for running an unofficial password manager server clone, yada yada yada".
Not only does no passkey tutorial tell me this, but it sounds like 100 times more work than simply avoiding passkeys and sticking with my existing password manager (whose database I can sync or back up like any other file).
I'm not defending passkeys; I think they're poorly conceived. I'm just telling you the answer to your question.
I have one important account now that doesn't allow passwords at all, so I'm forced to use passkeys. Sure, setting this up yourself is probably 100× more work than storing the passkey with Apple, but I'm sure as hell not doing that.
> … my existing password manager (whose database I can sync or back up like any other file).
Strongbox (or similar).
Yes, it's work. But get it done, and your passwords are under *your* control, not Apple's. And we keep learning, painfully, that Apple alone simply can't be trusted. Either a hosted or self-hosted option will do, so long as you've got redundancy somewhere. Just do it, seriously.
