Login Keychain Backups Won't Unlock Since macOS 26.4

For about twenty years, backing up your Mac's saved logins meant one thing: copy login.keychain-db somewhere safe, and on the day you needed it, drop it into ~/Library/Keychains/ on the new machine and type your password. According to Howard Oakley of The Eclectic Light Company, Michael Tsai and several developers, that stopped being true with macOS Tahoe 26.4 on 24 March 2026. A login keychain file on its own can now be useless: unlocking it needs your password plus a second, protected file that lives in /var/db/SystemKeys on the Mac that created it. Apple did not announce the change when it shipped. The first official write-up, an update to developer technote TN3137, arrived six months later, on 24 September 2026, and that is when most people heard about it. If you have ever dragged a keychain file onto a fresh install, kept a copy on a USB stick as your insurance policy, or you are about to wipe or replace a Mac, this guide is for you. It separates what Apple documents from what others have observed and from what nobody has confirmed yet, and it gives you a scenario-by-scenario table that the top search results do not.

Key Takeaways

• The change is real, but it is poorly documented. From macOS Tahoe 26.4 (24 March 2026) a login keychain can reference a protected entropy file in /var/db/SystemKeys. To unlock such a keychain you need the password and that file. Apple states this in technote TN3137; the details of how it works come from Howard Oakley's testing.
• Backing up only login.keychain-db is no longer a backup. A copy of the file without its entropy file cannot be unlocked, even with the correct password. Oakley's blunt advice: old copies that were not saved with their entropy files can never be unlocked, so treat them as lost.
• Mac-to-Mac tools that Apple controls reportedly work. Oakley reports that Time Machine backs up /var/db/SystemKeys and that Migration Assistant copies the entropy files. Independent VM tests also found Migration Assistant carried the keychain across. Third-party cloning tools must support the directory explicitly.
• A clean install is the dangerous moment. Michael Tsai summarises reports that even on the same Mac, erasing the disk and copying the keychain file back does not work, because the wipe removes the entropy key.
• iCloud Keychain and the Passwords app are a different store. They use the data protection keychain, not the file-based login keychain, so this change is not what hits them. Anything that only lives in the login keychain is what you must move or export before you erase.
• Do not unlock the SIP door casually. The only documented way to copy a keychain to another Mac requires turning System Integrity Protection off. Apple says that is for debugging, not a product feature.

What Changed, and in Which Version

Let us be careful about who said what, because the story has been repeated in forums with the details smudged. There are three layers: what Apple documents, what Howard Oakley and others observed, and what is still unconfirmed.

What Apple documents

Apple's developer technote TN3137: On Mac keychains now has a section on backing up file-based keychains. As I read it, it says the following.

• Starting with macOS 26.4, file-based keychains may reference protected entropy files. To unlock such a keychain you need the keychain password and the associated protected entropy file.
• You find the entropy file by dumping the keychain's salt with security show-keychain-info -s and a path to the keychain. The entropy file sits in /var/db/SystemKeys/ and its name is the salt value.
• Not every keychain has an entropy file. If no file matches the salt, that keychain does not reference one.
• Backup products must back up the entire /var/db/SystemKeys/ directory. Without those files, backed-up keychains may be unusable.
• To investigate by copying a keychain to another Mac, copy the keychain file anywhere and copy the entropy file into /var/db/SystemKeys/ on the destination. Accessing that directory requires disabling System Integrity Protection.
• The names, locations and formats of the entropy files are explicitly not API and may change at any time, so you should not build products around them.
• The system writes information about the files to the system log under a log category called dp_login.

I read the technote only in its machine-readable form, so treat my wording as a close paraphrase. It is the only Apple document I found on the subject. I did not find a mention of this change in the macOS 26.4 release notes, and the Apple security releases page lists macOS Tahoe 26.4 (24 March 2026) with no entry about keychain storage. That matches Oakley's complaint that the change went undocumented for six months.

What Howard Oakley and others observed

Oakley's posts give the practical picture. His 14 September piece, How can you copy or restore keychains?, describes the change as tying login keychain access to one Mac, and reports that non-login file-based keychains still work normally, as do file-based keychains created in macOS 26.3.1 or earlier. His 2 October article, How to copy login keychains that can be unlocked, is the documented procedure and the source for the backup-tool notes. His 3 October piece, What changed in macOS Tahoe 26.4, take 2, lists the change among a set of items he had missed first time round: the new SIP-protected directory, Time Machine including it, Migration Assistant copying entropy files, and the new -s option of security show-keychain-info.

Michael Tsai collected the reaction in Locked Down Passkey and Keychain Backups (24 September). He reports that the entropy files are encrypted and inaccessible without disabling SIP, that restoring a keychain to a different Mac fails, and that even the same Mac fails after a clean install. I read his post only as a summary and could not reproduce these claims.

Another independent check comes from the German site Born City, which reported VM tests. Copying login.keychain-db between virtual Macs, tested from Tahoe 26.6.2 to 26.6.2 and from 26.6.2 to a macOS 27 release candidate, failed with error -2147413984 even with the right password, while Migration Assistant carried the keychain across in every tested scenario. The same article attributes the failure to a key held in the Secure Enclave, which is the author's explanation, not Apple's.

What is unconfirmed

• Whether macOS 27 behaves the same. No source I found tests 27.0 or 27.0.1 beyond Born City's release-candidate test, and the technote does not say the rules differ. Assuming 26.4 behavior continues is an assumption.
• What exactly the second secret is. The 14 September post suggested involvement of the Secure Enclave or APFS volume-specific keys and said Apple has not clarified which. The 2 October post shows that, at least in Oakley's tests, copying the entropy file plus the keychain to another Mac with SIP off is enough. Those two findings do not obviously fit together, and I have not seen an explanation from Apple.
• Which exact setups are affected. Oakley notes keychains created before 26.4 can still work, and TN3137 says some keychains reference no entropy file at all. Whether a keychain that was created on 26.3 and has since been used on 26.4 or later gets an entropy file is not stated in anything I read.

A related claim that is not confirmed by Apple

In the same week Tsai also linked a post by Bob Gendler about a reported issue, tagged CVE-2026-43728, in which the keychain unlock reportedly succeeds with an incorrect password when other unlock factors are available, and quoted a man page note to that effect (see Accessing the Keychain Without the Password). I could not confirm this on Apple's side: the Apple security releases page I checked has no entry for that identifier and no keychain entry for the 26.4 through 26.7.1 releases, and I could not find the quoted sentence in the security man page on a Mac running macOS 26.5.2. Treat it as reported by a third party and not confirmed by Apple. It is also a separate issue from the one in this article, so it does not change anything in the backup advice below.

How It Works, in Plain Language

Think of the login keychain as a locked box. For years the box was a single file, ~/Library/Keychains/login.keychain-db, and the key was a password. With the file and the password you could open it anywhere.

From 26.4 the box can have a second lock. The sources agree on these parts:

1. The file records which entropy file it needs. The security show-keychain-info -s command prints a salt for a file-based keychain. Oakley's example output is a long hexadecimal salt after the word salt=. The entropy file in /var/db/SystemKeys is named after that salt.
2. The entropy file lives in a SIP-protected directory. /var/db/SystemKeys is a new directory that, according to Oakley, cannot be read or written unless SIP is disabled. Tsai's summary adds that the files in it are encrypted.
3. Unlocking needs both. Password alone does not do it any more. On the Mac that created the keychain, none of this is visible. You log in, the keychain unlocks, and the entropy file is read by the system without your involvement.
4. The entropy file lives on the volume. Erasing the disk removes the directory with it, which is why a clean install matters and why Time Machine including the directory is significant.

What sources do not establish is the role of the Secure Enclave. Early reports, including Oakley's 14 September piece and the Born City article, say the encryption is tied to it or to a machine-specific secret. Oakley wrote that Apple had not clarified this. Tsai quotes a commenter who points out that all Apple silicon Macs, and some Intel Macs, have a Secure Enclave processor, so the issue could reach millions of people. Only the documented machinery (password plus entropy file) is something you can act on.

One more distinction that causes confusion. Everything above is about the older, file-based login keychain. TN3137 describes a second kind, the data protection keychain, which came to the Mac with iCloud Keychain and is what iOS uses. That is a separate store, which brings us to the question people ask first.

Login Keychain, iCloud Keychain, Passwords App, Passkeys: What Is Affected

Store	What it is	Affected by the 26.4 change?	Source
Login keychain (login.keychain-db)	File-based keychain, per user, default on the Mac	Yes. Needs password plus entropy file	TN3137, Oakley
System keychain	One file-based keychain shared by the Mac	Not mentioned in any source I read	Unknown
Other file-based keychains you created	Separate .keychain-db files	No, per Oakley they work normally	Oakley, 14 Sept
iCloud Keychain / iCloud Passwords	Data protection keychain, synced through your Apple Account	Not by this change, as far as TN3137 describes	TN3137
Passwords app	Front end for passwords, passkeys, codes	Not the login file itself	Apple Passwords guide
Passkeys saved in iCloud Keychain	Synced credentials	Not by this change, see caveat below	TN3137, Tsai

TN3137 states that iCloud Keychain requires the data protection keychain and that it is shown in Keychain Access as iCloud Keychain when enabled or Local Items when disabled. It also says macOS 11 and later synchronises all item classes. In other words, if your passwords are synchronised through iCloud, a copy exists in Apple's sync service tied to your Apple Account, not to a file you carry around. Restoring them on a new Mac is a matter of signing in and turning iCloud Passwords on again, not of copying files.

That leaves the trap: an item can sit in the login keychain without you knowing. Tsai's discussion names Google Chrome, Zoom, MailMate, Vienna RSS and Xcode as apps storing credentials there. Old mail passwords, VPN secrets, client certificates and developer tokens often live there too, which is why a pre-erase check is worth ten minutes.

Passkeys

The headline of Tsai's post mentions passkey backups, so it is worth being precise about what I could and could not confirm. Passkeys that you created through the system and that sync through iCloud Keychain are stored in the data protection keychain world rather than in the login file, so the 26.4 entropy-file change is not what puts them at risk. What I could not establish from the sources I read is how Apple's passkey backup and export behavior compares to this change, because the passkey details in Tsai's post were not something I could read in full. Apple's own export guidance, which I did read, says you can export passwords to a CSV file but cannot export Wi-Fi passwords, passwords shared with a group (unless you created the group) or Sign in with Apple accounts. It does not say passkeys come out in that file, so do not plan on exporting passkeys. Plan on having them in iCloud Keychain, and for sites that matter, make sure there is a second way in, such as a recovery code or a second sign-in method.

Scenario Table: What Happens to Your Login Keychain Items

Where I say unknown, no source I read covers that case; for works or fails I name who reported it. None of this is my own testing.

Scenario	Result	Source and notes
In-place upgrade on the same Mac (for example to 26.7.1 or 27.0.1)	Expected to work, not directly tested in any source	Oakley says keychains backed up from the same Mac work. An upgrade keeps the same volume and the same /var/db/SystemKeys, so nothing is separated. No source describes a test of this exact path.
Migration Assistant to a new Mac, live, from the old Mac	Works	Oakley (14 Sept and 3 Oct) says Migration Assistant copies the entropy files. Born City's VM tests found it carried the keychain across in all scenarios. Tsai's summary reports a commenter saying it works only when the old Mac acts as the network server, so run it with both Macs powered on rather than from a stored backup.
Migration Assistant from a Time Machine backup	Unknown	Oakley says Time Machine backs up /var/db/SystemKeys. No source I read states what happens when the backup is then used as a migration source onto a different Mac.
Time Machine full restore to the same Mac (or back onto a replaced internal drive of the same Mac)	Works, per Oakley	Oakley says Time Machine backs up the directory since 26.4 and restores the entropy files automatically. Note the exceptions below for logic board replacement.
Time Machine restore onto a different Mac	Unknown	Not covered by the sources I read. Migration Assistant is the documented route to a new Mac.
Bootable clone with Carbon Copy Cloner, restored	Backup side works, restore side unknown	Oakley reports that Mike Bombich confirmed CCC backs up the contents of the SystemKeys folder without special steps because it works from volume snapshots. What happens when you restore that clone to another Mac is not stated.
Bootable clone with SuperDuper, restored	Unknown, with a pointer	A commenter in Tsai's post says SuperDuper can copy the needed keys using Apple's asr tool. I did not see a statement from the developer. Verify with the vendor before relying on it.
Manual copy of login.keychain-db to another Mac	Does not work	Oakley, TN3137 and Born City all agree. Born City reports error -2147413984 with the correct password.
Manual copy of the keychain plus its entropy file into /var/db/SystemKeys on the destination, SIP disabled	Works, per Oakley's documented procedure	Procedure and caveats are in the section below. I have not run it.
Clean install, then drag the old keychain file back (same Mac)	Does not work	Tsai's post reports that restoring the file after a clean install fails because the wipe removed the entropy key. Oakley says a login keychain saved without its entropy file can never be unlocked.
Restore a single login.keychain-db from a Time Machine backup	Depends	If the entropy file for that keychain's salt is still present on the live volume, the combination is the one the sources describe as working. After a clean install, or on another Mac, it fails. No source tests this restore path directly.
Hardware failure with logic board replacement, or DFU restore	Does not work	Oakley's 14 September post lists these among the cases where the login keychain cannot be unlocked, and warns that losing access to the Mac means losing the contents.
Keychains created on 26.3.1 or earlier, non-login file-based keychains	Work normally	Oakley, 14 September.

Two rules fall out of the table: the safe paths have Apple's own tools carry the whole system state, and the risky paths separate the entropy file from the keychain, either by moving the keychain alone or by erasing the disk that held it.

Before You Erase or Replace Your Mac: A Checklist

Do this before you click Erase All Content and Settings, before you reinstall macOS from Recovery, and before you hand a Mac to a repair shop that might replace the logic board. The goal is to make sure nothing important lives only in the login keychain.

1. Check the Mac's state and make a real backup

Confirm what you are running; the fix paths below assume 26.4 or later.

sw_vers -productVersion

Make a full Time Machine backup first. Oakley reports the backup now includes /var/db/SystemKeys. Our Time Machine troubleshooting guide covers a failing backup, and if your destination is a NAS over SMB, the 26.4 SMB backup fix explains a separate 26.4 problem. For a wider plan, see our backup strategy guide. Treat a Time Machine backup as the safety net, not the whole answer: it protects you on a restore, but not against the case where you only get a single file back.

2. Open Keychain Access and look at what is actually in there

On a Mac running macOS 26.5.2, I confirmed that Keychain Access is still present at /System/Library/CoreServices/Applications/Keychain Access.app. It is no longer in the old Applications/Utilities folder, so search for it with Spotlight, or open it from Terminal:

open "/System/Library/CoreServices/Applications/Keychain Access.app"

In the sidebar, look at the list under Default Keychains. Per TN3137, the entries are named login for the file-based keychain, and iCloud or Local Items for the data protection keychain, depending on whether iCloud Keychain is on. Click login and then the Passwords and Certificates categories. Sort by Kind and by Date Modified so that old and obviously important items rise to the top. Anything in login is what is at risk during a wipe. Anything under iCloud syncs with your Apple Account.

If you prefer Terminal, the security man page documents these two read-only commands:

security list-keychains
security show-keychain-info ~/Library/Keychains/login.keychain-db

The first lists the keychains currently in your search list. The second prints settings for the keychain you name; on the Mac I checked, the local man page does not list the -s option that Oakley and TN3137 describe, so if you want the salt, use the form from those sources, security show-keychain-info -s followed by the path, and expect a password prompt. Writing the salt value down is useful. It tells you which file in /var/db/SystemKeys belongs to this keychain, which matters if you later need to prove a backup contains it.

There is also security dump-keychain, which the man page says dumps keychain contents; its -d option dumps decrypted data. I have not run it, so keep any output private and delete it afterward.

3. Export what can be exported

The honest summary is that you can export some things easily, some with effort, and some not at all.

• Passwords from the Passwords app. Apple documents File, then Export Selected Password to File, or Export All Passwords to File. The result is a CSV that, as Apple warns, is not encrypted and visible to anyone with access to the file. Import it into your password manager and delete the CSV. Apple also says the export cannot include Wi-Fi passwords, passwords shared with a group you did not create, or Sign in with Apple access. Our piece on the Passwords app in macOS 27 covers the rest of the app.
• Items that only live in the login keychain. Passwords stored by older apps appear in Keychain Access but may not appear in the Passwords app. One user report I found says the Export Items command in Keychain Access is disabled when saved passwords are selected, so do not assume you can export those with a menu command. For each important item, open it, tick Show password, authenticate, and record the value in your password manager. It is tedious, and for a few dozen items it is also the only reliable route.
• Certificates and identities. The security man page documents an export command that accepts a type (including certs and identities) and a format (including pkcs12). Its general form looks like this:

security export -k ~/Library/Keychains/login.keychain-db -t identities -f pkcs12 -o ~/Desktop/identities.p12

The man page says that without -P, the wrapping passphrase is requested through a GUI prompt, which is the better choice since a passphrase on the command line ends up in your shell history. I have not run this command. Private keys that the creating tool marked as non-exportable may refuse to export, which is expected behavior for such keys, not a bug in the backup. If you rely on a client certificate for VPN or a work portal, ask whoever issued it whether they can reissue it; that is often faster than fighting an export.

• Wi-Fi passwords. Apple lists them as not exportable from the Passwords app. Note which networks matter and where each password is written down.
• Things you cannot get out. Secrets stored by an app with an access rule that only that app can read, and anything that exists only in a keychain you can no longer unlock. For these, the vendor's own export, sign-out, or re-authentication flow is the route.

4. Move the survivors somewhere durable

For each item you care about, decide where it should live next. Turn on iCloud Passwords and Keychain in System Settings under your Apple Account, then iCloud, if you want Apple's synced store. Or use a third-party password manager that offers an encrypted export of its own. Either way, the target should not be a file that depends on this particular Mac.

Check from a different device that a site signs in using only the synced copy. If it does, the item is safe from this change.

5. Prepare the erase

Our factory reset guide covers the erase itself; sign out of your Apple Account only after confirming the synced copy is complete. For a new Mac, run Migration Assistant with the old Mac powered on, and see our Migration Assistant troubleshooting guide if it stalls. Keep the old Mac's data intact until the new Mac has opened your login items for real.

The Documented Procedure for Copying a Keychain So It Can Be Unlocked

I have not run this procedure and did not test it on any Mac. This is Howard Oakley's documented method, combined with what Apple's TN3137 says, with the requirements and risks stated plainly.

The steps, as documented

1. On the source Mac, find the salt of the keychain you want to copy. Oakley and TN3137 give the form security show-keychain-info -s followed by the keychain path. You are prompted for the keychain password. The output ends in a long hexadecimal salt value.
2. The entropy file you need is /var/db/SystemKeys/ followed by that salt value. Reading that directory requires SIP to be disabled, according to TN3137 and Oakley. Neither source spells out whether the source Mac must have SIP off to read the file, but since the same directory protection applies on both sides, plan for it.
3. Copy the keychain file and its entropy file to the destination Mac. The keychain can go anywhere. Oakley's example keeps it in a Documents subfolder.
4. On the destination, with SIP disabled, put the entropy file into /var/db/SystemKeys, under the same name.
5. Re-enable SIP.
6. Open the copied keychain and enter its password.

To disable and re-enable SIP, Apple's documented method is to boot into recoveryOS and use the Terminal there. The relevant commands are:

csrutil disable
csrutil enable

csrutil disable turns SIP off for the installed system and requires a restart. csrutil enable turns it back on. To check the current state at any time, run csrutil status in Terminal. On the Mac I used for this research, it reported that SIP is enabled, which is the expected default. On an Apple silicon Mac, you reach recoveryOS by shutting down, then pressing and holding the power button until the startup options appear and choosing Options.

Requirements and risks

• SIP has to be off for the copy step. That is the central requirement. While it is off, the protection of system files is reduced, including the very directory you are working with. Keep the window short and do not install anything in it.
• Both the password and the entropy file must be right. A file copied under the wrong name does not help. If the wrong file is placed into /var/db/SystemKeys, you gain nothing and you have written to a protected system directory.
• It is explicitly not a supported feature. TN3137 says the locations, names and formats of the entropy files are not API, may change at any time, and that the procedure is for development and debugging. A macOS update could change the arrangement and invalidate your saved copy.
• The entropy file is sensitive. Together with your password it unlocks the keychain, so do not store the two together unencrypted or send them anywhere.
• It does not solve the case where the source Mac is gone. If the Mac died or its disk was erased, there is no entropy file to copy.

When not to do it

Do not use this procedure as your routine backup method, and do not follow it just because the Mac asks a keychain password you cannot remember. If you want to move to a new Mac, Migration Assistant is the supported route. If you only need to know what is in the keychain, Keychain Access on the original Mac does that. If you are not comfortable with recoveryOS and Terminal, or IT manages SIP on the Mac, leave it. It suits only a one-off recovery from an old Mac you still have, by someone who accepts lowering SIP temporarily.

If You Have Already Lost Access

Here is the honest picture, from the sources above, without false hope.

What is probably recoverable

• Anything synced to iCloud Keychain. Sign in to your Apple Account on the new Mac, turn on Passwords and Keychain, and wait for the items to arrive.
• Items in a Time Machine backup made on the same Mac. If you still have the Mac, or you restore a full Time Machine backup to the same Mac, Oakley says the entropy files are included and restored.
• Keychains created on macOS 26.3.1 or earlier. Oakley says these work. If you have an old copy from before March 2026, try it before assuming the worst.
• Any copy that still has its entropy file. If you copied the keychain by hand and also have a backup of /var/db/SystemKeys from the same Mac, the documented procedure above is your route.

What is probably not recoverable

• A login keychain from macOS 26.4 or later, saved without its entropy file, from a Mac that no longer exists or was erased. Oakley says plainly you will never be able to unlock it, and says the same for the case of losing physical access to the Mac, a logic board replacement, or a DFU restore.
• Anything you only ever stored in that keychain, with no sync, no export and no copy.

Do not pay for "keychain recovery" services that claim to bypass the password. The problem is a missing second input, not a forgotten password, and I found no source describing a way around it for an arbitrary copy.

What to do now: keep the Mac and backup drive untouched, then check in this order: iCloud Keychain, your password manager, any Time Machine backup, any clone, any old Mac, and finally per-account reset flows, starting with email and your Apple Account since those unlock the rest.

Notes for Admins and People Who Script Keychain Backups

If you manage Macs, or have a script that copies ~/Library/Keychains nightly, assume your backup is incomplete on 26.4 and later until proven otherwise.

• Audit the scripts. A script that only copies login.keychain-db produces files that may be useless. TN3137 says backup products should back up the entire /var/db/SystemKeys/ directory. That directory is SIP-protected, so a script running as a normal user, or even as root with SIP on, may not be able to read it; I did not find a source that says how to read it with SIP on, apart from snapshot-based tools. Oakley's note on CCC is instructive: it works from volume snapshots, so it sees the directory without special steps.
• Do not hard-code the paths. TN3137 says the names, locations and formats are not API. If you encode the salt-to-path mapping in a tool, it can break in any update. Use security show-keychain-info -s only for diagnostics and logging.
• Test restores, not backups. A backup that cannot be opened on the target is not a backup. Build a test that restores to a clean Mac or VM and tries to unlock a test keychain. Born City's VM test conditions (different MAC addresses, at least three CPU cores and 12 GB of memory per VM) are a useful reference if you do this with virtual machines.
• Check macOS 27. Your fleet likely contains both Tahoe 26.7.1 and Golden Gate 27.0.1. Do not assume behavior is identical; run your restore test on both. Use our macOS versions tool to see which builds your devices run.

Troubleshooting Common Issues

The copied keychain asks for a password and rejects the right one

Oakley, the Apple developer forums and Born City describe this symptom; Born City reports error -2147413984. A forum poster saw a copied login keychain refuse to unlock in 26.4 while the original stayed unlocked, and an Apple engineer asked for a Feedback Assistant report. The likeliest cause is a missing entropy file, not a wrong password. Do not reset passwords on the original; check whether the source Mac still exists.

Repeated password prompts are a different problem

If prompts began after an account password change or a restore, see our guide to the login keychain password prompt in Tahoe. Suspect the entropy file only when the keychain was copied from another volume or Mac.

show-keychain-info -s does not print a salt

TN3137 says not every keychain references an entropy file. If the command prints no salt, or no file in /var/db/SystemKeys matches, the keychain does not need one. That is good news for old keychains. Also check that you passed the full path of the file and that you are using a macOS version that supports the option; the local man page on a 26.5.2 Mac did not list the -s flag, though both Apple and Oakley describe it.

FAQ

Did Apple really change how the login keychain works?

According to Apple's TN3137 technote, since macOS 26.4 file-based keychains may reference a protected entropy file, and unlocking needs the password plus that file. Apple did not announce it at release; the technote update came on 24 September 2026, six months after 26.4 shipped on 24 March 2026, according to Howard Oakley.

Can I still copy login.keychain-db to a new Mac?

Not on its own. Sources agree that the file alone cannot be unlocked on another Mac, even with the correct password. The documented workaround is to copy the matching entropy file into /var/db/SystemKeys on the destination with SIP disabled, but Apple frames that as for debugging. For a real move to a new Mac, use Migration Assistant with the old Mac running.

Does this affect iCloud Keychain and the Passwords app?

According to TN3137, iCloud Keychain uses the data protection keychain, a different store from the file-based login keychain, so this change is about the login file. Items synced through iCloud Passwords are tied to your Apple Account. Check what lives only in the login keychain before you erase, because those items are the ones at risk.

Will Time Machine restore my keychain?

Howard Oakley reports that Time Machine has included /var/db/SystemKeys since 26.4 and restores the entropy files automatically, so a full restore to the same Mac should work. Restoring a single keychain file on its own, or restoring onto a different Mac, is not covered by the sources I read, so treat those cases as unknown.

Is macOS 27 the same?

Unknown. Apple's technote does not distinguish between releases, and I found no published test on 27.0 or 27.0.1 beyond one VM test on a release candidate that matched the 26.4 behavior. Assume the same rules, and test your restore path on 27 before relying on it. Apple may also change the entropy file details at any time.

Is there a way to unlock a copied keychain without the entropy file?

No source I read describes one. Oakley says old login keychains from 26.4 onwards that were not stored with their entropy files may as well be deleted, because they will never be unlocked. A third-party report of a keychain unlock accepting a wrong password, tagged CVE-2026-43728, is not confirmed on Apple's security page and should not be treated as a recovery method.

Conclusion

The practical lesson of macOS 26.4 is that the login keychain stopped being a file you can carry and became a piece of system state. The password is still necessary, but it is no longer sufficient, and the second ingredient sits in a directory that ordinary tools cannot see. Apple's own migration and backup tools appear to handle that for you, according to Oakley and independent VM tests. Hand-made copies, clean installs followed by a drag-and-drop restore, and third-party backups that do not capture /var/db/SystemKeys do not. Some details, such as the exact role of the Secure Enclave and whether macOS 27 differs, are still unconfirmed.

So change the habit. Before any erase, replacement or repair, back up with Time Machine, look at what is in the login keychain, move what matters to iCloud Passwords or a password manager, and confirm it from another device. Use Migration Assistant for the new Mac. Keep the old Mac until the new one has proved it can open your logins. And if you only have an old keychain file, find out whether its entropy file still exists before you give up on it.

Related reading: Best Mac backup strategy 2026, Migration Assistant stuck or slow, Mac security and privacy guide for Tahoe