September 21 2026
This is a follow-up to my September 10 blog post macOS Tahoe silently sabotaged the login keychain A subsequent addendum to the blog post noted that the change was introduced in a specific version of macOS Tahoe, 26.4, released by Apple on March 24. In brief, macOS 26.4 added a restriction to the login keychain that makes it non-portable, impossible to unlock outside of its original context. Consequently, recovery of login keychain data from backup has also become impossible in some critical circumstances, most notably if your Mac is lost or broken. Apple has sabotaged disaster recovery for Mac users, who may not discover the sabotage until it’s too late, after disaster occurs. Even Mac users who have tested their disaster recovery process will get caught unawares if their testing was done prior to the macOS 26.4 update. I believe I now understand what changed exactly in macOS 26.4: Apple enabled data protection for the login keychain, like on iOS.
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. I mentioned some apps that store data in the login keychain, such as Google Chrome and MailMate; it should have been obvious that I did not mention Apple apps such as Safari and Mail, whose passwords are handled by the Passwords app on Tahoe. 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. From Apple’s Keychain Access User Guide:
Note: You can’t copy passwords stored in your Local Items or iCloud Keychain. To transfer these keychain items to another computer, set up iCloud Keychain on the other computer by signing in to your Apple Account.
You can manually copy keychains other than Local Items or iCloud Keychains to another Mac using the steps below.
The second paragraph from the quote is no longer accurate as of macOS 26.4, but Apple has neglected to update its support documentation!
You can manually export items from the Passwords app, but that’s a terrible procedure for routine backups. Most Mac users will probably rely on iCloud Keychain sync for backups, which in my opinion is foolhardy, because iCloud Keychain provides no versioning—multiple historical timestamped backups—and if you ever get locked out of your Apple Account for whatever reason, you’re totally screwed. In any case, 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, but fortunately I’m still running macOS 15 Sequoia on my main Mac, so I don’t have to deal with the issue yet.
In Terminal app, the following command displays your default keychain, which should be your login keychain located at ~/Library/ on disk.
security default-keychainAnd the following command will lock your default keychain. (You can also specify a keychain file, but it operates on your default keychain if nothing is specified.)
security lock-keychainAfter you’ve locked your default keychain, you can unlock it with this command, which will request a password.
security unlock-keychainMy M1 Mac mini has multiple macOS boot volumes including the latest versions of Sequoia, Tahoe, and Golden Gate. On macOS 15.8, entering an incorrect password will give an error such as this:
$ security unlock-keychain
password to unlock default:
security: SecKeychainUnlock <NULL>: The user name or passphrase you entered is not correct.On macOS 26.7 and 27.0, however, entering an incorrect password… incredibly, just works! Is this a previously undiscovered security vulnerability? No, it’s actually by design, as you can see in the Apple source code, which is open for selected components. Here’s an excerpt from the source code for the macOS keychain:
if (os_feature_enabled(Security, ProtectLoginKeychainWithDP)) {
// keychain will be unlocked with DP thus it should accept any password
// but we also don't want to rekey to the empty string password
// use NULL here, just in case the user's password is legitimately the empty string
secnotice("dp_login", "attempting to unlock with empty and will definitely not rekey");
theKeychain->unlock(CssmData(static_castlgt;void *>(NULL), 0));
unlockedByDp = true;
}The acronym DP in ProtectLoginKeychainWithDP undoubtedly stands for Data Protection. Apple has a support document about keychain data protection:
Many apps need to handle passwords and other short but sensitive bits of data, such as keys and login tokens. The keychain provides a secure way to store these items. The various Apple operating systems use differing mechanisms to enforce the guarantees associated with the different keychain protection classes. On devices with macOS, Data Protection isn’t used directly to enforce these guarantees.
The published date of the document is December 19, 2024, but as of macOS 26.4, the last sentence of that first paragraph appears to be out of date and inaccurate.
Curiously, using an incorrect password with security unlock-keychain does not work in a macOS virtual machine. I assume the difference is that, unlike macOS boot volumes on the Mac internal disk, a macOS VM is not unlocked with the Secure Enclave of the Mac. Nonetheless, the login keychain of a macOS 26.4 or later VM is still not portable! Indeed, even the VM’s own recovery volume can’t unlock the login keychain of a user on the non-recovery volume. Moreover, the login keychain of one VM can’t be unlocked by another VM (or by a non-VM, for that matter, as confirmed by Howard Oakley). I tested by creating two separate macOS 26.6.2 VMs on one Mac. Both VMs use the same login password, yet I was unable to successfully transplant the login keychain from one 26.2.2 VM to the other. After transplanting the login keychain and booting back into macOS, I found that the transplanted login keychain was renamed to login_renamed_1.keychain-db and a new login keychain was created from scratch.
As I mentioned in my previous blog post, I couldn’t unlock the Tahoe login keychain from Golden Gate on my M1 Mac mini, which seems to indicate that the login keychain encryption is unique to each macOS boot volume, not shared by every volume that uses the same Mac Secure Enclave. According to an Apple support document, “All APFS volumes are created with a volume encryption key by default. Volume and metadata contents are encrypted with this volume encryption key, which is wrapped with a key encryption key (KEK). The KEK is protected by a combination of the user’s password and hardware UID when FileVault is turned on.”
The term “data protection” is ironic in this case, because the unannounced addition of data protection to the login keychain in macOS 26.4 introduced the possibility of catastrophic data loss. The other day I noticed a Reddit post that appears to demonstrate the catastrophic data loss is not merely theoretical.
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.
Things I have tried that did not work:
Rolled back to Tahoe and to try and recover from Time Machine
Went into Recovery mode, opened Terminal, and manually replaced the login keychain and associated files with my recoverd [sic] Keychain files from Time Machine. The password to reveal passwords still wasn’t accepted.
I have 100+ passwords saved locally, and I desperately need a solution, or I may lose my job.
How can I get my migrated keychain file to open and show me saved passwords
The good news is that on my suggestion, the redditor seems to have been able to recover passwords by using a Time Machine backup of the login keychain from before the macOS 26.4 update. I’m confused why the redditor needed to use a VM for this recovery; perhaps they didn’t understand that I was using a VM myself only for testing purposes. The latest versions of macOS 26 and 27 should still be able to unlock a pre-26.4 login keychain, though you’d want to rename the keychain file to avoid confusing the system. Of course any data added to the login keychain after the macOS 26.4 update would have been lost, but hopefully the majority of the redditor’s 100+ passwords were older than that.