This is pretty much how it's suppose to work...
Hardware keys are the way:
- Less likely to fail in the first place
- Cheap enough to have several of so you can use one to log in and manage the others in the event of loss
- Easy to move between devices
- Less likely to use the auth handshake as a side channel for things you didn't consent to
My non hardware key is a keypass file that I update only on my laptop and I sync to my other devices. I have plenty of backups. It does also the TOTP required to login into some customers servers.
I keep all my TOTP keys on an encrypted usb drive in a safe. When I lose a key, I manually add all the TOTP accounts onto the new key from my safe
Passkeys are a different story. Every account I need to make sure I have multiple yubikeys registered. When I lose one, I get in via a second key and then add the replacement one.
It’s a pain but it’s a model that makes sense to me. Lose the key? Time to reach for my backup key.
There's not really a plausible answer to that question, because the login keychain data is almost entirely specific to that host.
To iron-man your argument: Apps that store account credentials to third party services will need to be signed in again.
If you were using http basic auth for a website and saving that, then it was probably in there.
Private keys and certificates you manually imported, or that were created by an application for your host. This is the closest to a plausible answer, imo.
Pretty much everything?
As a general rule, I expect a file on an encrypted disk to be unreadable for anyone who lacks the encryption key(s).
> if I need to obtain some other thing from the original computer to "unlock" that file, I should be able to do it.
You can export your passwords to a plain text CSV from the original computer.
BitLocker does the same with key protectors. Even on a local account with no internet, there's always a 48-digit recovery password that opens the volume on a completely different machine.
Two of the three major platforms ship a portable passphrase path alongside the hardware one, so this being unavailable here is a product decision, not a law of key derivation.
Your average non-technical user will absolutely expect it to work this way, and if it doesn't, will be at best confused, and at worst incredibly angry that their photos are gone.
Exporting a private key from a keychain is hard to automate (the password of the keychain is asked for all exports, and HAS to be typed manually IIRC).
Use iCloud Keychain or don't use Keychain at all.
Nope, unpairing is a complete reset apparently. And Apple Support was apparently not trained to know that not everything syncs in the backup. She lost all her voice memos, which she uses for class notes, and probably other app data as well.
What happen though is the ability to encrypt the data with secure enclave, store it on our own. When migrating, we decrypt with secure enclave, get back original data and re-encryp on the new device.
No, it's not, and that's not how it ever worked in macOS 26.3 and earlier.
This change was introduced in 26.4 for some reason.