Tahoe 26.4 Reports Raise Login Keychain Copy Risks

That is not proof of a universal macOS compatibility boundary, a particular hardware dependency, or Apple’s intent. It is, however, enough to challenge a familiar assumption: that preserving the login-keychain database file is by itself a dependable way to recover saved credentials on replacement hardware. The practical distinction is now between a raw file copy and a supported migration, and it matters most before the original Mac becomes unavailable.

What has been reported since Tahoe 26.4​

Apple released macOS Tahoe 26.4 on March 24, 2026. Reports place the onset of the observed raw-copy problem after that release, but they do not establish that 26.4 is a definitive boundary for every Mac, operating-system version, account type, or keychain.

In one reported test, a login keychain copied from an Apple-silicon Mac to a macOS virtual machine could not be opened using the password that should have unlocked it. Further testing reported the same outcome when copying a login keychain from an M4 Pro Mac to a Tahoe virtual machine and when copying between two Tahoe virtual machines. In these cases, the password failure was not necessarily evidence that the user had entered the wrong password; the copied keychain itself did not become usable in the destination environment.

Those are meaningful reports, including physical-Mac-to-VM and VM-to-VM cases. But their limits are just as important:

• They do not cover every Apple-silicon, Intel, or T2-equipped Mac.
• They do not establish the effect of FileVault configuration.
• They do not cover all account types, existing versus newly created keychains, or every Tahoe point release.
• They do not prove that all keychain items, all migration methods, or all recovery routes fail.

The defensible conclusion is therefore narrow. A raw copied Tahoe login-keychain file should not be treated as a reliable cross-Mac recovery asset based on the reported cases. For users who maintain manual filesystem backups, that is a consequential change even if the ultimate technical cause remains unknown.

A keychain password is not the whole security model​

Apple describes keychains as SQLite databases, but the important security properties are not confined to the database file. Apple’s platform-security documentation says that the metadata key is protected by the Secure Enclave and that accessing the secret key always requires a Secure Enclave round trip.

That architecture makes one explanation plausible: a copied database may be missing protected cryptographic relationships needed on the destination machine. In that scenario, the old password can be valid without being sufficient to unlock the copied material elsewhere.

Plausible is not the same as established. Apple has not confirmed, in the available evidence, that Tahoe intentionally made login keychains device-bound through a Secure Enclave secret. Nor is it safe to call this an Apple-silicon-only behavior. A reported Tahoe VM-to-VM raw-copy failure occurred in systems described as lacking a Secure Enclave. That does not disprove a Secure Enclave role on physical hardware, but it does show that the current reports cannot be reduced to a single demonstrated hardware explanation.

There is also a separate API-specific detail that should not be conflated with raw database copying. An Apple Developer Forums post by a DTS engineer reportedly characterized a change in SecKeychainUnlock behavior in macOS 26.4 as fallout from a wider, unspecified security-hardening change. That statement concerns the API behavior described by the engineer. It does not establish Secure Enclave binding, identify the wider change, or explain why copied login-keychain files fail to open in Keychain Access. The raw-copy reports remain a separate observation with an unresolved mechanism.

Apple’s manual-copy instructions now need caution​

Apple’s current Keychain Access guidance says that keychains other than Local Items and iCloud Keychain can be manually copied to another Mac. The guidance addresses standard keychains, including the login keychain, tells users to rename a copied standard keychain, and says the original keychain password is needed to access its contents.

That guidance conflicts with the reported Tahoe raw-copy failures. A user following the documented process could reasonably preserve a login-keychain database, import or attach it on a replacement Mac, enter the old password, and expect to retrieve saved credentials. In the reported cases, that expectation was not met.

There are several possible explanations for the mismatch. The documentation may apply to cases not represented by the reports, the reported cases may expose a regression or narrower condition, or the documentation may no longer reflect current behavior for this specific kind of keychain transfer. The available record does not settle which explanation is correct.

For recovery planning, the answer is straightforward: do not let a manually copied login.keychain-db become the only planned route to critical passwords, certificates, private keys, or application credentials. Preserve it if useful, but treat it as potentially inaccessible until tested in the environment where recovery would actually occur.

Migration Assistant has a better observed result​

The available migration evidence is more encouraging, although still limited. Apple says that Setup Assistant automatically transfers keychains. Separately, a Tahoe 26.6.2 VM-to-VM test reported that Migration Assistant transferred seeded login-keychain passwords and an ad hoc signing certificate, and that those items were accessible on the destination VM.

That is an observable result, not a disclosed explanation of the transfer process. The test does not reveal how Migration Assistant handled the keychain material, whether it copied, recreated, rewrapped, or otherwise transferred it, and it does not validate every category of protected item.

It also does not answer the most difficult recovery question: whether a Time Machine-only restoration can recover a usable post-26.4 login keychain after the source Mac has failed, been erased, or is otherwise unavailable.

Apple documents Migration Assistant as able to transfer from a Time Machine backup. That general capability should not be interpreted as proof that every protected keychain item will remain usable in a backup-only recovery. No available test establishes that outcome for a post-26.4 login keychain once the original Mac’s protected state is gone.

For now, the strongest practical reading is modest: a live-source Migration Assistant transfer succeeded in one Tahoe 26.6.2 VM-to-VM test. It is a better-supported option than a raw database copy, but not a universal guarantee.

Security updates are not a demonstrated cause​

Tahoe 26.4 included Keychain-related security fixes. It is tempting to assume that a raw-copy failure is an intentional consequence of security hardening, especially where a listed issue involves a local attacker potentially gaining access to a user’s Keychain items.

The evidence does not justify that conclusion. The same Keychain CVE fixes were also issued for macOS Sequoia 15.7.5 on the same date. Security bulletin timing alone cannot establish that either fix caused the Tahoe reports. Likewise, Tahoe’s Managed Migration Assistant changes should not be assumed to be connected simply because they arrived in the same update.

This distinction matters for IT decision-making. Calling the behavior either a security feature or a bug too early can produce the wrong response. A deliberate security control may require a new recovery design; a regression may eventually receive a fix; and a configuration-specific interaction could affect only some environments. Until Apple gives a technical explanation, recovery plans should be built around observed behavior rather than a guessed cause.

What Mac users and administrators should do​

A cautious plan should separate general backup from credential recovery.

1. Migrate while the source Mac is still available. When replacing or upgrading a Mac, use Setup Assistant or Migration Assistant while the original Mac can still participate. Before wiping, selling, or repurposing it, verify that important passwords, certificates, and application sign-ins work on the destination.
2. Keep Time Machine, but test its credential-recovery role. Time Machine remains valuable for files, applications, and broad system recovery. Do not assume that it can independently restore every post-26.4 login-keychain item to another Mac. Test a non-production account against the exact backup-only scenario your organization expects to use.
3. Identify secrets with high recovery cost. Developer signing certificates, VPN credentials, SSH keys, database credentials, recovery codes, enterprise application logins, and locally held certificates need specific recovery plans. Where permitted, use approved export, escrow, reissue, or documented account-recovery procedures.
4. Check what iCloud Keychain actually covers. iCloud Keychain can be a separate synchronization path for eligible items, but it should not be assumed to restore all local login-keychain content or certificates. Validate the credentials that matter rather than relying on a general expectation of sync.
5. Preserve the original state and avoid destructive troubleshooting. If an imported keychain rejects a password, do not immediately conclude that the password is wrong. Avoid deleting original files, repeatedly resetting passwords, or overwriting backups before attempting a supported migration or consulting the relevant recovery process.
6. Document platform-specific recovery methods. For mixed Windows and Mac fleets, “restore the user profile” is increasingly inadequate guidance. Protected credentials, certificates, device-associated keys, and application identities often need a platform-supported transfer path beyond copying files.

Why this matters beyond macOS​

Windows administrators will recognize the broader pattern. Modern operating systems often preserve encrypted data in backups without making that data universally portable to different hardware or a different installation. The bytes may survive while the protected relationships required to use them do not.

The consequence is operational rather than theoretical. A help-desk runbook that says “copy the profile,” “restore the backup,” or “enter the old password” can fail at exactly the point when a user needs access to VPN, developer tools, business applications, or encrypted records. Credential continuity must be planned independently from document continuity.

Mac fleet operators should update replacement and incident procedures accordingly. Supported live migration should be the preferred route when possible. Backup-only recovery should be tested rather than presumed, particularly for identities and certificates that cannot be quickly recreated.

The bottom line​

Reported behavior following macOS Tahoe 26.4 shows that copying a login-keychain database file to another Mac can fail even with the correct password, in both physical-to-VM and VM-to-VM cases. That is an observed onset in limited testing, not a fully established compatibility boundary across Mac models, FileVault configurations, account types, or macOS point releases.

A Secure Enclave explanation remains possible but unproven, and it does not by itself explain the reported VM-to-VM failure. Migration Assistant produced a positive result in one Tahoe 26.6.2 VM-to-VM test, where seeded passwords and an ad hoc signing certificate were accessible after transfer. The mechanism is undisclosed, and Time Machine-only recovery after loss of the original Mac remains untested.

For now, users should preserve raw keychain files if they wish, but should not rely on them alone. Move Macs through supported migration while the source system is available, verify critical credentials on the destination, and test backup-based recovery before an outage makes the question urgent.