macOS Tahoe blocks manual login keychain migration on Secure Enclave Macs

A familiar migration trick has stopped working

A long-standing Mac technique has quietly broken with macOS Tahoe: manually copying a user's login keychain file from one machine to another no longer works when the keychain came from a Mac with a Secure Enclave. According to a September 8 write-up on the Der Flounder blog that reached the Hacker News front page, the copied file refuses to unlock even when the correct password is supplied, because the cryptographic keys needed to decrypt it now live in the Secure Enclave of the Mac where the keychain was created.

The login keychain is the store macOS builds automatically for every user account. On macOS Tahoe it is a SQLite database named login.keychain-db sitting in the user's Library/Keychains folder, and by default it unlocks at login because its password matches the account password. For years that made the file a convenient thing to carry between machines: copy it to another Mac, put it in place, unlock it with the password, and your saved credentials travel with you.

Why the copy fails

Der Flounder points to Apple's Platform Security documentation for the explanation. Keychain items are encrypted with two separate AES-256-GCM keys: one covering metadata, which keeps keychain searches fast, and a per-row key covering the actual secret values. The metadata key is guarded by the Secure Enclave but is cached on the Application Processor so queries stay quick. The secret key gets no such caching — decrypting a stored secret always involves the Secure Enclave directly.

The implication is that a keychain created on a Secure Enclave Mac is bound to that specific piece of hardware. The password you type may be right, but it is no longer the only gate between you and the plaintext; the decryption keys themselves stay with the source machine's enclave. On the destination Mac, there is nothing to ask for them.

A controlled test in a VM

To verify the behavior, the author copied a login.keychain-db from an Apple Silicon Mac into a freshly created macOS virtual machine. The VM was a deliberate choice: virtual machines have no Secure Enclave, so if the keys really do live in the source Mac's hardware, the VM has no possible route to them. The test account on the VM used the same username and password as the account on the Apple Silicon Mac, which rules out a password mismatch before the test even starts.

After the VM's own keychain file was swapped out for the copied one and the machine restarted, the keychain did not unlock at login. Instead, macOS quietly built a brand-new login keychain and renamed the copied file to login_renamed_1.keychain-db.

What the logs showed

Digging into the unified log with a query against the com.apple.securityd subsystem and the KCLogin category confirmed the sequence. securityd attempted to unlock the copied keychain and reported that a password had been supplied, then failed with error -2147413984. Moments later it logged that it was creating a new login keychain, followed by a success message for that creation.

Since the password was verified as correct during the test setup, and the log explicitly notes that a password was supplied, the failure cannot be dismissed as a typo. It lines up with the Secure Enclave binding described in Apple's own documentation. The blog frames the breakage as applying to Secure Enclave Macs running Tahoe; the demonstration used a VM as the destination precisely because it lacks an enclave entirely.

Why it matters

The change cuts both ways. On the security side it is a clear win: a stolen or copied keychain file is now useless off the original hardware, because the password alone can no longer unlock it. That closes a fairly practical exfiltration and offline-attack path.

On the usability side, it kills a workflow that Mac admins and power users have leaned on for years — file-level keychain migration, restoring credentials from backups, and moving saved secrets between machines during hardware swaps. Anyone who expects to drop an old keychain onto different Apple Silicon hardware running Tahoe should assume the copy-and-unlock approach will fail. The practical effect is to push credential migration toward Apple's supported transfer and sync mechanisms, and to make the old Mac's own environment — not a loose database file — the thing you need access to while migrating.