I remain unhappy with Apple’s passkey backup story. There’s little documentation about this, but from what I can tell:

• There are no automatic versioned backups. (Syncing is not backup because it doesn’t protect you against human error, bugs, or attacks.)

• Even if you have a Time Machine backup, it’s not possible to restore it to the same Mac without logging into iCloud. This could be a problem if your account is locked or compromised.

• Restoring it to a different Mac is impossible because the decryption key is stored in the other Mac’s Secure Enclave. Apple is protecting you from accessing your own backup, even though the keychain is already an encrypted file, protected by the password that you set. (And the Time Machine or clone drive that it’s stored on is probably encrypted, too.)

• The Passwords app can now export passkeys, but you cannot create an export file that you can import back into Passwords on another Mac. You can only export to a third-party password manager that’s installed on the same Mac (which may require a working Apple account). Even then, this does not include passkeys for Apple services; they don’t show up in the Passwords app. There are also some other restrictions around shared items and Sign In with Apple.

The above is last year’s news, but I don’t think I had written it all in one place before. The new bad news is that, as of macOS 26.4, these problems now affect regular passwords, not just passkeys. (You do have more flexibility to export passwords, though.)

Rich Trouton (Hacker News):

Historically, you could copy the login keychain file from one Mac to another and be able to open it on the destination Mac by providing the password to that keychain. As of macOS Tahoe, this does not appear to work for Macs which use Secure Enclave.

[…]

From that, it appears that unlocking the login keychain requires more than the password because the keys it unlocks are tied to the Secure Enclave of the Mac where the keychain was created. With the decryption keys stored in the source Mac’s Secure Enclave, manually copying the keychain to another Mac and then unlocking it won’t work. The password you have for the keychain may be correct, but the actual keys needed to decrypt its contents won’t be available on the destination Mac.

Jeff Johnson:

According to Apple, all Apple silicon Macs, as well as some Intel Mac models, have the secure enclave processor, so the issue affects millions of Mac users.

[…]

If anything happens to your Mac, if it’s stolen or becomes inoperable, your login keychain is also lost, unrecoverable, even if you have a copy of the login keychain file! This is a stunning development that has left me bewildered and irate. WTF was Apple thinking? To my knowledge, Apple did not even publicize the change in Tahoe.

[…]

How does Migration Assistant handle the situation on Tahoe? I don’t know. I would guess that since Migration Assistant still has access to the old Mac, it simply decrypts the old login keychain and copies the login keychain entries to the new login keychain on the new Mac, rather than transferring the keychain files directly.

[…]

I recommend that you open your login keychain with the Keychain Access app (now located in /System/Library/CoreServices/Applications) and check what’s in there, the data that you’re in danger of losing. Whether you realize or it not, many apps use the login keychain. For example, Google Chrome and other Chromium browsers store passwords in the login keychain. MailMate stores email account passwords in the login keychain. The open source RSS reader Vienna stores website passwords in the login keychain. The Zoom app also uses the login keychain. My Developer ID code signing certificate is stored in the login keychain; if I’m not mistaken, I believe that Apple’s own Xcode put it there. And of course, any items that you’ve manually added to the login keychain would be lost if the keychain file could not be unlocked.

Howard Oakley:

I have confirmed that a login.keychain-db copied from my Mac mini M4 Pro to a virtual machine (VM) running macOS Tahoe 26.6.2 cannot reveal any of its secrets to the Keychain Access app on the VM, as it refuses to accept the valid password. Not only that, but Keychain Access running in a VM cannot access the login.keychain-db keychain copied from another Tahoe VM, although neither has been anywhere near a Secure Enclave.

If you intend migrating manually between Macs, don’t waste time trying to copy across the login keychain, as it’s not likely to work, and its secrets will remain.

[…]

I performed test migrations between VMs, and demonstrated that Migration Assistant does copy the contents of the login keychain successfully to the destination Mac.

I think this only happens if you migrate over a network, with the old Mac acting as a server. I prefer to connect the old Mac using Target Disk Mode, but in that case Migration Assistant wouldn’t be running on the old Mac so the special sauce wouldn’t work. Likewise if I were trying to do the migration using a third-party cloning app.

Howard Oakley:

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

[…]

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.

rsUSA0 (via Jeff Johnson):

When upgrading to macos 27 Golden Gate, I erased my system through recovery to do a clean install. I planned to manually migrate data back to the computer from an external drive clone of Macintosh HD and a Time Machine backup. This has worked well in the past and eliminated system bloat.

When I manually migrated my login keychain, it opened, showed entries, but it wouldn’t accept my password to reveal any actual passwords. The window shakes like I’m using the wrong password. I’m 100% sure I’m using the correct password. I also tried every password I’ve ever used and I’m certain it’s not a password issue.

Perhaps even restoring to the same Mac failed because the clean install wiped the key stored in the Secure Enclave. [Update (2026-10-01): See update below.]

Jeff Johnson:

Some people who read my previous blog post misunderstood the issue, because they didn’t know that the macOS login keychain is distinct from iCloud Keychain.

[…]

In the Keychain Access app, you can see two separate default keychains, one of which is the login keychain. The other default keychain is named “iCloud” if you’ve enabled iCloud Keychain, “Local Items” if not. There’s actually a longstanding issue with this keychain analogous to the newer issue with the login keychain.

[…]

Mac users like myself who forsake iCloud Keychain face the prospect of no disaster recovery for the Local Items keychain. My habit is to manually create a new password item in the login keychain and only then supply the credentials to an app, for example, Safari AutoFill. Ironically, the login keychain change brought by macOS 26.4 sabotages my password backup procedure[…]

jen1x:

Today, I got my new Mac mini M6. When I started setting up the new machine, it asked me to update to macOS 27, so I followed the instructions.

[…]

After signing in to iCloud, it asked me to enter the passcode of one of my Apple devices. I entered the correct passcode and even tried the passcodes for all of my devices, but I keep getting the same message:

Verification Failed
There was an error verifying the passcode of your iPhone

I don’t like having to rely on iCloud.

Previously:

• SuperDuper’s “Follow-Up”
• macOS 26.4
• 2025 Six Colors Apple Report Card
• Locked Out of Apple Account Due to Gift Card
• Downloading Xcode With a Passkey
• iOS and iCloud Keychain Are Hostile to Backups
• Passkeys Credential Exchange
• Passkeys: A Loss of User Control?
• Fixing iCloud Keychains, and Backing Them Up

Update (2026-10-01): TN3137 has been updated for macOS 26.4:

Historically each file-based keychain was a standalone file. You could, for example, copy a keychain file from one Mac to another and still use it, as long as you knew the keychain password.

In macOS 26.4 and later that’s no longer the case. A keychain file might reference a protected entropy file. To unlock such a keychain you need both the keychain password and the protected entropy file.

[…]

These protected entropy files are stored in /var/db/SystemKeys. If you’re creating a backup product, make sure to back up that directory. Without it, the keychain files that you back up might be useless.

[…]

The /var/db/SystemKeys directory is not directly accessible, even when running as root, so you can’t copy a protected entropy file in the normal way. To access it, disable System Integrity Protection (SIP).

First things first: I don’t think turning off SIP every time you make a backup is a real solution. And I don’t understand what problem Apple is really trying to solve with protecting the entropy file; it seems like they don’t trust their own encryption. Lastly, it’s not explicitly stated, but I don’t think copying the entropy file helps with backing up passkeys.

That aside, I find the details both illuminating and confusing. This probably explains the rsUSA0 case above, where restoring to the same Mac didn’t work. The key wasn’t stored in the Secure Enclave but rather in the entropy file on the SSD, which had been wiped. This also suggests a simpler way for Migration Assistant to work; it could have special access to copy the entropy file without having to actually open the keychain.

It also seems to be saying that, if you turn off SIP and copy the entropy file, you can then access your keychain backup from another Mac. But I’m not sure how to square that with Apple’s keychain documentation:

Keychain items are encrypted using two different AES-256-GCM keys: a table key (metadata) and a per-row key (secret key). Keychain metadata (all attributes other than kSecValue) is encrypted with the metadata key to speed searches, and the secret value (kSecValueData) is encrypted with the secret key. The metadata key is protected by the Secure Enclave but is cached in the Application Processor to allow fast queries of the keychain. The secret key always requires a round trip through the Secure Enclave.

How can copying the entropy file work if the Secure Enclave is required? My guess is that the entropy file itself is encrypted (NSFileProtection) using the Secure Enclave. So accessing it on the original Mac does require going through the Secure Enclave. But when you make a backup, the entropy file gets decrypted. Maybe accessing the keychain on the second Mac causes file protection to be re-applied to the contents of /var/db/SystemKeys, so then it becomes protected by that Mac’s Secure Enclave.

Previously:

• Accessing the Keychain Without the Password

Update (2026-10-02): Dave Nanian (Mastodon):

This is obviously not a good user solution, because no one is going to boot to Recovery, turn off SIP, back up, boot back to Recovery, and turn SIP back on. Thinking they would do so is kind of crazy.

[…]

SuperDuper handles this situation. When you make a bootable copy, the required keys are copied without requiring any special steps.

SuperDuper itself can’t read the entropy file, but it uses Apple’s asr tool to make bootable backups, and that has special access. (Unfortunately, it can’t update the entropy file without making a fresh bootable backup, but in practice I don’t expect it to need updating.) I had not been bothering to make most of my backups bootable, since in most cases I just want to restore to an internal SSD, not actually boot from the backup. But I now think it makes sense to choose bootable backups as the default.

Howard Oakley (Rich Trouton):

I won’t expand on my feelings any further than by saying that in my 37 years as an Apple developer, I have never come across anything so shameful.

Unfortunately, it seems like the keychain stuff was just the warm-up act.

Update (2026-10-05): Howard Oakley:

[macOS 26.4] Added the protected directory at /var/db/SystemKeys to backups of Data volumes, and protects them in backups.

So Time Machine does back up the entropy file. I missed this because I didn’t see /var/db in my backups, but it turns out that they do have /private/var/db/SystemKeys and are just missing the /var symlink.

Update (2026-10-07): Jeff Johnson:

The -s option to the security show-keychain-info is not yet documented in man security, not even on the latest version of macOS Golden Gate. Moreover, the -s option does not work on macOS Sequoia and earlier. In general, the security show-keychain-info command reveals no information unless the specified keychain is unlocked, which makes it impossible to discover the salt of a keychain file that you can’t currently unlock. However, as long as you already have the entire contents of the /var/db/SystemKeys directory from the macOS volume on which a keychain file was created, the inability to determine the keychain file’s salt beforehand shouldn’t be much of a problem, because in practice there are typically only a few salt files, so you can simply copy them all to another macOS volume.

[…]

You don’t actually have to disable SIP to add files to the /var/db/SystemKeys directory, because you can do so from another boot volume. You have to boot into recovery anyway in order to disable SIP, so you could simply edit /var/db/SystemKeys from recovery rather than disabling SIP on the non-recovery volume.

The security unlock-keychain command lacks an option to specify the location of an entropy file or to provide the file data directly, so unfortunately a login keychain can’t be unlocked from the recovery volume, only from a volume where you can add files to the /var/db/SystemKeys directory.

Neil Fraser (via Hacker News):

Nearly twenty-five years ago I registered neil.fraser.name to provide a stable presence on the Internet. It has been the home of this website, my email address, and a server for APIs.

[…]

On 15 April 2026 Verisign proposed the destruction of the entire 3rd level of the ‘.name’ hierarchy in order to simplify their administration. Astonishingly, on 28 July 2026 ICANN approved this action.

[…]

One of my original reasons for choosing ‘.name’ was that it was run by Global Name Registry -- more specifically, it was not run by Verisign. I had history with Verisign and did not trust them. Unfortunately, Verisign acquired Global Name Registry a few years later.

He’s going to lose his site and e-mail address, and someone else could potentially register the domain and hijack his accounts.

Previously:

• .org Top-Level Domain Sold
• The .blog Bait and Switch

Alex Chan (Hacker News):

Many of these outages were caused by a single bug, deep in SQLite. It took months of intense forensics to track it down.

[…]

This lack of reliable trigger conditions meant we couldn’t reproduce the bug synthetically. Instead, we had to rely on deploying passive, forensic telemetry in our live environment to catch the corruption red-handed. Gathering live diagnostics for a database issue is the last thing we wanted to do, but we had no choice.

[…]

As an additional complication, the corruption didn’t occur on a regular schedule. Sometimes incidents would be hours apart, other times weeks. This made it difficult to predict progress or plan further work, because we were never sure when we’d get our next diagnostic dump. We had a six-week period between October and December when there were no corruption incidents, before they returned as an unwelcome Christmas present.

[…]

In two incidents, our transaction logs failed to replay cleanly. Upon closer inspection, we discovered that data written and committed by one transaction was inexplicably invisible to later transactions. A write had vanished into thin air without raising an error.

SQLite:

The bug is likely present in all version of SQLite from 3.7.0 (2010-07-21) through 3.51.2 (2026-01-09). It is fixed in version 3.51.3 (2026-03-13) and later. Backports of the fix are available for some earlier releases: 3.44.6 and 3.50.7.

The bug only affects databases in WAL mode when there are two or more database connections open on the same file, in separate threads or processes, and when those two connections attempt to write or checkpoint at the same instant.

Alex Chan:

This investigation is a useful reminder: running boring technology in a non-standard way is a risk. The common paths and standard configurations are incredibly well-tested and reliable. Most people use SQLite in a standard configuration and never face this sort of issue. Everything we were doing was a public, documented, supported configuration—but by taking manual control of the checkpointing process and running at our own aggressive pace, we stepped off the well-trodden operational path.

Scott Perry:

I spent the last two years of my time working on SQLite trying to chase this bug down. It was so rare that I never got an internal report; my assessment of the number of customers affected was “about a county’s worth”, some of whom were generous enough to allow their local Genius Bar to send me backups of the affected databases. I spent so many hours in a hex editor staring at the wreckage.

Top three data corruption bug of my career for sure, and the other two weren’t bugs in SQLite.

A former Tailscale employee got in touch and shared that they were checkpointing these databases every 250ms. Multiplied across a fleet of servers that is a fantastic way to surface a super rare bug—they basically built our test rack as a product, but two orders of magnitude more effective (partially due to scale, but mostly because our rack also panics devices at random in order to test the filesystem, NAND controller, etc. and rebooting takes a while)

[…]

13/10 fantastic bug. proof that 100% test coverage is a good start, and that formal methods are needed for critical applications.

Carl Sverre (Hacker News):

I whipped out my phone, and asked Claude to get to work. I had it get SQL 3.51.2 – still buggy – set up in Antithesis, and then instrument the code with a bunch of Antithesis assertions. You can see the instrumented version here.

Then I asked it to write a simple workload which exercised the WAL insert and checkpoint code. Notably, this is a completely generic workload. It just runs writes and checkpoints concurrently – things you’d expect to actually happen in production, all the time. The assertions are also generic to the bug, they’re all standard assertions you’d add to any database, things like “no lost committed writes” and “database is not corrupt” (called integrity check in sqlite).

On my first run, Antithesis caught the bug in 15 mins. Here’s the report.

Of course, it helps that he knew to look in the checkpoint code, but you could imagine using tools like this to quickly investigate hypotheses when you don’t already know the answer.

Cindy Harper (Hacker News, ArsTechnica):

Sony plans to wipe 551 movies and TV shows from the PlayStation Store libraries of customers who paid full price for them. The deletion is coming on September 1 and so far the company has said nothing about giving anyone their money back.

[…]

Anyone who hit “buy” on one of them will open their library that morning and find a hole where it used to be. PlayStation’s notice states it without apology: “You will no longer be able to access your previously purchased content from Studio Canal, and it will be removed from your video library.”

The justification Sony offers runs to six words, “due to our content licensing agreements.”

You might try to avoid this problem by purchasing physical discs, but movies and TV shows no longer always make it to that medium. And the same will be true for games.

Sid Shuman (via Nick Heer):

As consumer preferences and the broader entertainment industry continue to shift away from physical discs to digital, physical game disc production for all new games releasing on PlayStation consoles will be discontinued starting January 2028. Following this date, new games will be available on PlayStation Store and at retailers in digital formats only.

Timothy Geigner (Hacker News):

In all of our discussions about how the digital revolution has created a system in which people don’t actually own the things they think they’re buying, I get particularly frustrated by the lack of change in it all. We’ve spilled much ink complaining that this clearly anti-consumer practice needs to be done away with, where an unsuspecting public thinks they’re buying “a thing” only to learn months or years later that “the thing” they bought was actually a license to use/view/listen to another “thing”, and that license exists at the pleasure of the company that collected the money for it.

[…]

As Kotaku notes later in their post, part of what is striking in all of this is the sheer mundanity of the announcement. Because there have been no consequences, or any action at all from the public or government, Sony treats this all as if it’s perfectly normal and no big deal. You can tell me all you want about how the Ts and Cs in these purchases do in fact note that the nature of the purchase is a temporary licensing of the content for an undetermined time period… but I can promise you that the public in general doesn’t understand that. They think they’re buying a thing, not a license.

And that’s because of the purposeful obfuscation of that fact.

Kyle Orland:

Sony’s recent decision to stop producing physical PlayStation games in the near future has naturally led to a renewed focus and appreciation for physical games that can be played just by sticking a cartridge or disc in a console. But an increasing number of those “physical” games these days still require additional downloads from a centralized server to function as intended.

Previously:

• Xbox Outage Affected Discs
• Removing Archives of Comedy Central and MTV News
• Sony Removing Purchased Discovery TV Shows
• HomePod Late Adopter
• Arrested Development Leaving Netflix Soon
• Apple Sued for Removing Purchased Content
• Apple Can Delete Purchased Movies From Your Library Without Telling You

Joshua Khane (Hacker News):

Microsoft DELETED my account AND OneDrive!!?? After ACKNOWLEDGING that I’m the owner of the account and that it was compromised???

25 fucking years of data, thousands of euros spended on games?? My son’s baby pictures? GONE!

Scott:

This is EXACTLY why cloud providers should be building (and might need to FORCED to, via consumer protection regulation) access for other online backup services into their solutions INHERENTLY. Apple… are you paying attention?

That One Guy:

Honestly they could recover it, they choose not to because they dont give a shit about their user base.

XBOX Support:

We’re sorry this happened, it’s not the experience we want anyone to have when their account is compromised. We have been working to restore access to your purchases and reached out with the next steps.

Running to the press works.

Previously:

• Xbox Outage Affected Discs
• Sony Removing Purchased Content
• Locked Out of Apple Account Due to Gift Card
• Locked Out of Apple Developer Accounts
• Google Cloud Accidentally Deletes Customer’s Account
• Another User Locked Out of Apple Account
• Amazon Account Locked Due to Alleged Remarks to Driver
• iPhone Thieves Locking Users Out of Their Apple Accounts
• Google Account Deleted Due to CSAM False Positive
• Apple Accounts “Permanently” Blocked
• Apple Account Locked Due to Failed Trade-in
• Stolen Instagram Account
• Developer Accounts Nearly Terminated
• Guilherme Rambo Locked Out of Apple Developer Account
• Locked Out of an Apple Account
• Outlawed by Amazon DRM

Apple:

In macOS 28 and later, the Mac OS Extended file system format will be supported only for volumes (disks and other storage devices) that aren’t encrypted. For future macOS compatibility, either decrypt or reformat any encrypted Mac OS Extended volumes.

I think Apple removed the user interface for creating such volumes way back in Big Sur. It’s not really surprising that they’re going away, although only offering a year of warnings seems rather aggressive. Many people delay updating to major OS versions or wait until they get a new Mac. There will be users that switch to a Mac that can only run macOS 28 and get rid of their old one before realizing that some drive they haven’t connected in a while won’t mount.

The other surprising part is that Apple’s options—reformat or decrypt—are not great. During the initial transition to APFS, macOS would transparently convert an encrypted HFS+ boot volume to encrypted APFS without rewriting any data. This functionality is nominally still available via the diskutil apfs convert command, but Apple hasn’t mentioned this or built an automatic upgrader GUI.

[Decrypting] doesn’t apply to encrypted Time Machine backup disks.

It’s obvious why. The old Time Machine format with hard links is totally different from the new one based on APFS snapshots. But this means that you’ll either need to buy a new Time Machine drive for use with macOS 28 or delete your backup history. Even if you keep the old drive, you’ll need an older boot drive or an old Mac in order to be able to access it.

Previously:

• Searching Time Machine Backups and Versions
• macOS 27 Golden Gate Announced
• macOS 27 to Drop Support for AirPort and Time Capsule Backups
• Removing Unwanted APFS Time Machine Backups
• Should You Continue Using HFS+?
• Time Machine Evolution and APFS
• SuperDuper 3.3 for Catalina
• APFS to be Mandatory for SSDs in High Sierra

Update (2026-07-24): Marcus Mendes:

Apple has now revised the page to add a third option, allowing users to convert an encrypted HFS+ volume directly to encrypted APFS without decrypting it first.

[…]

The company has also removed its previous instructions for decrypting the volume first, converting it to APFS without erasing it, and then optionally re-encrypting it.

Hammer:

Ignore Apple’s guidance and do not use Convert to APFS in Disk Utility for disk images.

The first encrypted HFS+ disk image I tried to convert that way failed and left me with an unusable disk image. If I didn’t have backups I’d have lost its contents.

It didn’t corrupt the disk images that I tried, but it didn’t work, either, instead failing with an error about expecting a GPT partitioning scheme.

Update (2026-07-28): Howard Oakley:

As encrypted disk images have never used CoreStorage, withdrawal of support for that has no impact on the continued use of any form of encrypted disk image, including those using HFS+ as their virtual file system.

This is a good point. Apple’s support page refers to “encrypted Mac OS Extended disks,” but the developer release notes refer to CoreStorage specifically. So this shouldn’t affect most encrypted disk images, which show up in Finder as unencrypted after mounting. The encryption is at the disk image level rather than at the file system level. However, I’m not sure that all encrypted disk images are safe. Presumably, a device image, which directly copies the blocks rather than the files, would still use CoreStorage.