Since Mac OS X 10.6 Snow Leopard in 2009, Macs have supported two different types of keychain. Their login and other file-based keychains are SecKeychains derived from older types, and encrypted databases stored in single files, such as those in ~/Library/Keychains. When iPhones were introduced, iOS introduced the more secure Data Protection keychain, supported by Snow Leopard and now used for the iCloud Keychain, otherwise shown as Local Items. Although file-based SecKeychains were deprecated in El Capitan, they continue to be used in all Macs, and include the essential login keychain, unlocked when you enter your login password, and used widely by apps.

Changed behaviour

As Rich Trouton has described in his Der Flounder article, macOS Tahoe has changed the behaviour of the login keychain. Jeff Johnson was quick to pin down that change to macOS Tahoe 26.4, and to point out that other file-based SecKeychains aren’t affected.

This effectively results in there now being three types of keychain in macOS:

• file-based SecKeychains behaving as they have done in the past, which can be unlocked and their contents accessed using passwords;
• login file-based SecKeychains which can only be unlocked using passwords in conjunction with another secret tied to that Mac, probably held in the Secure Enclave;
• Data Protection keychains including the iCloud Keychain and its equivalent Local Items. At present, macOS only permits one of these on each Mac.

Effects

Since my previous article, I have been extending my tests using VMs and Apple silicon Macs running macOS Tahoe 26.6.2 and Golden Gate release candidate. These are my conclusions.

You should be able to unlock and access items in:

• any login keychain backed up from the same Mac
• any non-login file-based keychain
• any file-based keychain, including login, written by macOS 26.3.1 or earlier
• any keychain migrated successfully from a Migration server running on another Mac.

The last of those includes migrations performed between two Macs, one acting as server, the other as client. As Migration Assistant takes both Macs over completely, discovering whether it copies individual items between keychains or the whole keychain is a challenge of limited relevance.

What you almost certainly can’t do is unlock and access items in any login keychain copied or backed up from a different Mac running macOS 26.4 or later. This means

• 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.

Workarounds

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.

Jeff Johnson recommends creating a custom non-login file-based keychain and using that instead, where possible. Although this does at least avoid the new problems of login keychains, there doesn’t appear to be a way of automatically unlocking custom keychains at the start of each session, and default settings for automatic locking after 5 minutes or when sleeping could result in excessive prompts for password entry.

Perhaps the only advantage of the new restricted access to login keychains is making them harder to crack in the event of theft by stealer malware. Traditional file-based keychains are notoriously easy to crack, so moving secrets to a custom keychain would be exposing them to greater risk should it be stolen by an attacker.

Key points

• As of macOS Tahoe 26.4, the behaviour of the login keychain has changed, tying its access to one Mac.
• This could prevent access to its contents in several circumstances, when the Mac that created it isn’t available, undergoes repair, or with restore in DFU mode.
• Most reliable transfer of login keychain contents is by two-Mac migration using Migration Assistant.
• Apple needs to document these changes as a matter of urgency, and provide a method to preserve login keychain access.