Over the last few weeks, it has become clear that macOS Tahoe 26.4 changed access to login keychains, blocking their unlocking in many circumstances that have been important and well-used in the past. This was first reported by Rich Trouton, further investigated by Jeff Johnson and explored here. On 24 September, Apple at last added a brief section to its developer tech note TN3137 outlining what has changed. This article explains.

Before 26.4

Since Mac OS X 10.6 Snow Leopard in 2009, macOS has supported two different types of keychain.

Login and other file-based keychains are SecKeychains derived from older types, stored as encrypted databases in single files, such as those in ~/Library/Keychains. Although file-based SecKeychains were deprecated in El Capitan, they continue to be used in all Macs, and include the essential login keychain, unlocked automatically when you enter your login password, and still used by apps.

When iPhones were introduced, iOS introduced the more secure Data Protection keychain, supported by Snow Leopard and now used for the iCloud Keychain; when that’s not shared in iCloud it’s shown as Local Items.

Although the login keychain can be copied across from a suitable backup by Migration Assistant, as a single file it has been common practice to copy or restore it, and to unlock it using its password, the same as the login password for the Mac that created and used it.

One major disadvantage of file-based keychains has become clear with stealer malware: exfiltrate the login keychain and it’s quick and cheap to crack its password, and access all the secrets within it. That’s likely to have been the main reason for Apple changing them earlier this year.

Tahoe’s extra secret

macOS Tahoe 26.4 broke the copying of login keychains in almost all circumstances. Although Rich Trouton suggested this resulted from encryption using an additional secret held in the Secure Enclave, Jeff Johnson came closest with the observation that the additional secret is volume-specific. It turns out that secret is stored in a locked directory in Data volumes, in /var/db/SystemKeys.

File-based keychains, specifically but not necessarily exclusively the login keychain, might now require both their password and a protected entropy file, stored in /var/db/SystemKeys. Without the latter, login keychains, and possibly some other file-based keychains, can’t be unlocked and used. Thus, if you copy one of these protected keychains and its entropy file becomes inaccessible, that copy can’t be unlocked.

Copy login keychains

If you want to copy a file-based keychain between Macs or boot volumes you must therefore copy across its protected entropy file, to be located in /var/db/SystemKeys on the destination Data volume. To enable that, System Integrity Protection (SIP) must be disabled, and the entropy file identified by dumping the keychain’s salt, using the command
security show-keychain-info -s path
where path is the full path to the keychain, typically ~/Library/Keychains/login.keychain-db for a login keychain. When you run that command, you will be prompted to enter that keychain’s password, and without that the command will fail.

This will return something like
Keychain "/Users/hoakley/Documents/zKeychains/login.keychain-db" no-timeout salt=30993ABCECBE29D91ED95C2A3827326DB5C39B2F
indicating that keychain’s entropy file is
/var/db/SystemKeys/30993ABCECBE29D91ED95C2A3827326DB5C39B2F

All file-based keychains return values for salt, but only those requiring entropy will have an entropy file of that name.

Backups

This procedure also applies to backups, presenting backup software with the challenge of backing up the entropy files in their locked directory, and restoring them should the user need to copy or restore that keychain. This explains how Migration Assistant can still copy fully functional login keychains between Macs, and should be able to do so when migrating from a backup, provided that contains the /var/db/SystemKeys directory with its entropy files.

For some time now, each Time Machine backup has consisted of two phases, one for protected files. Since macOS 26.4, its backups of Data volumes have also included the protected directory /var/db/SystemKeys, also protected in those backups. This has presumably ensured that performing a one-Mac migration using a Time Machine backup can copy both the login keychain and its entropy file.

Although I have checked the documentation for some third-party backup products, I can see no explicit details of whether they back up the protected directory, or how they can restore entropy files for login keychains.

Key points

• Login keychains from macOS Tahoe 26.4 onwards require an additional secret to unlock them.
• That additional secret is an entropy file stored in a protected directory /var/db/SystemKeys.
• Copying a login keychain successfully now requires copying its entropy file as well.
• Backup software must back up that protected directory, and restore its entropy file(s) with any keychains that require them.
• Time Machine has backed up entropy files since macOS 26.4, and Migration Assistant will copy them when necessary during migration.
• If you use third-party backup software, check it supports entropy files correctly.
• If you have old login keychains from 26.4 onwards that aren’t stored with their entropy files, you may as well delete them now, as you will never be able to unlock them.
• macOS Tahoe 26.4 was released on 24 March 2026. Apple documented this for developers only on 24 September 2026, exactly six months later.

References

Apple’s TN3137, see the section at the end on backing up a file-based keychain.
Apple’s user documentation, which has been incorrect for over six months.