Apple’s iPhone User Guide for iOS 27 explains how to export your passwords for websites and accounts to a CSV file, which you can then import into another password manager. The option sits in the Settings app under Apps, then Safari, and Apple warns that the exported file is not encrypted. That makes the export […]
Way back in January I noted that one of the features that had kept me from using Passwords as my only password management app was its inability to manage SSH keys, a feature offered by competitor 1Password. What I liked about 1Password’s approach was that it abstracted this feature, letting me authenticate my keys using macOS’s built-in authorization system. So instead of typing in a passphrase for that key, I could just use Touch ID or type my 1Password password. This still seems to me like the kind of thing that Passwords should offer, and I still hope that it might in the future.1
In the meantime, I’ve recently turned to Secretive, an open-source tool by Max Goedjen and others that allows you to store your SSH keys inside your Mac’s Secure Enclave. Doing so means that your keys can’t be exported and are protected by the same level of security as your system’s most sensitive data. In addition to ECDSA-256 keys, running Secretive on macOS Tahoe and later lets you create post-quantum keys using the MLDSA-65 and MLDSA-87 algorithms. If you don’t know what any of that means, don’t worry about it—you’re fine.
Using Secretive still requires some technical know-how. You’re going to have to edit some configuration files and, if you’re using the keys to log in to remote servers, install them yourself. There are instructions for much of this both in the app and online. Other apps can work with Secretive too, assuming the developers have built in support: right now, it’s mainly targeted at developer tools like git and GitHub, as well as secure file transfer clients like Transmit and Cyberduck.
The one major downside of this system is that since the private keys are stored in the Secure Enclave, they cannot be backed up or transferred elsewhere. That’s more secure, but it’s more inconvenient as well; if your Mac gets hosed, or you migrate to a new device, you’ll have to recreate your keys all over again. It also means that if you maintain SSH keys on multiple Macs, you have to set up Secretive on all of them. That’s another reason that I’d like to see Apple find a way to abstract this process further via the Passwords app, if it can figure out a safe and secure way to do so—not to mention, potentially making it available on iOS as well. Like passkeys, ssh keys offer more security and less reliance on passwords.
Secretive’s not for everybody, but there are certainly a subset of users who will be very interested in the security it offers. But until such a time as Apple makes this process part and parcel of its operating system, I’ll be relying on Secretive to help me manage it.
It also might help more people who would like to move away from 1Password for…reasons. ↩
After my massive article on migrating your passwords, passkeys, and other secrets from third-party password managers to Apple’s Passwords, Wallet, Safari, and general ecosystem—potentially with help from another app—reader Scott asked whether I was directing people into weaker security. He wrote:
If someone manages to steal my device and its passcode, they have access to the contents of my phone, including all of the information stored in Apple Passwords. This is not the case if I use a third-party password manager and have set a separate password for access, as the thief will not have access to my other passwords…I’m surprised this liability is not discussed and considered more frequently.
This is a great follow-up question, and one that I didn’t address within the scope of the migration article, which was already long. Let me pick apart how to answer that by looking at risks and mitigations.
The risks of cracking our eggs at once
I understand the fear of losing everything, whether it is a set of material objects or digital secrets. One of the most heartrending stories I ever heard was from a photographer who lost all his work in an apartment fire shortly after moving to New York City to start his career. He rebuilt. That’s harder to do digitally, where if our privacy is “burned,” we might see bank accounts drained and potentially have to get our Social Security number or other identity number replaced.
Should these eggs crack, whither our password security? (Photo by Nick Fewings on Unsplash)
But we should consider alongside that how likely it is for the scenario Scott describes: “…someone manages to steal my device and its passcode, they have access to the contents of my phone…” A sequence of actions has to take place for that to be true:
Someone has to steal your device.
Someone has to have obtained your passcode or have forced you to reveal it when or after they steal the device.
That person has to then have the time to put the stolen booty to use, like performing money transfers or cryptocurrency actions, before you erase your device remotely.
It’s most likely an iPhone would be the thing stolen, because we have those with us all the time, and thieves have been known to shoulder surf or record video from a distance to capture you entering your passcode. iPads and Macs can, of course, be taken from us as well, but it’s just much less likely when we’re out and about. A stolen Mac has additional protections if it’s powered down, and we often set longer passwords for a Mac, where an iPhone or iPad might still have a four-digit code.
If you are a privacy advocate, protester, journalist, opposition politician, or promoter of freedom and peace, you are at greater risk, and thus using Passwords as an in-band solution—one in which compromising a device unlock pathway could compromise our secrets—already makes no sense. (I’ve seen some people recommend Bitwarden, not because of a necessarily superior security model, but because it’s open-source and has an expansive free personal tier that includes end-to-end encryption for synchronization among your devices.)
So this worry for the rest of us is a kind of prospective and speculative anxiety: that, in the wrong circumstances, all our passwords and other secrets would be exposed. While this happens regularly, the number of instances in which a passcode is obtained and malice occurs before we can stop it is fairly low. Most iPhones are stolen to wipe them for resale, which Apple has rendered difficult with the long-ago introduction of Activation Lock. Rather than knowing your passcode, criminals are more likely to try to threaten you or use phishing to obtain the passcode after they have the device.
Fortunately, Apple came up with a solution after the Wall Street Journal in 2023 exposed how a dangerous sequence of events, which could start with drugging or violence, would allow thieves to reset an Apple Account and take over someone’s digital accounts and life.
We don’t yet have face-stealing technology
Stolen Device Protection uses a combination of delays and biometrics to deter thieves from accessing your data and accounts.
Apple’s Stolen Device Protection is a feature that may be one that has irritated you enough that you haven’t cared to understand how it may also keep your secrets safe. Go to Settings: Privacy & Security: Stolen Device Protection, and it’s likely enabled. Based on reports, I believe Apple enabled this by default in iOS 26.4. It’s available only for iPhones.
When enabled, it restricts a number of activities and requires Touch ID or Face ID for many authentication steps—passwords can’t be used instead. For the purposes of protecting your secrets, Stolen Device Protection has two key attributes:
It locks many actions for an hour, such as changing your Apple Account password. Even then, you have to use biometrics to start the countdown and before taking the action. Knowledge of a passcode isn’t helpful. If you have Away from Familiar Locations selected, this occurs only when the device isn’t in a place you routinely spend a lot of time, typically home and work.1
You cannot view passwords or fill them into form fields from Apple’s Passwords system without using Touch ID or Face ID with Always enabled, so a thief having your passcode is out of luck. (If you have Away from Familiar Locations selected, a ne’er-do-well would have to be in one of those locations to use a passcode.)
This leaves one rotten scenario, in which you are kept under duress for at least an hour and are forced to use biometrics, then perform other actions. But how likely is that for most people? I don’t want to dismiss the distress of those who have been through that, but the likelihood of most people experiencing it is vanishingly small.
Leaving Stolen Device Protection enabled does mean that you may have to wait an hour in some scenarios to manage aspects of your Apple Account, make changes to Face ID or Touch ID, change your device passcode, and a few other actions. But this minor inconvenience might assuage the kinds of concerns that Scott wrote in about, and make you more comfortable that your big basket of secret eggs won’t scramble.
For further reading
I just updated my book Take Control of Securing Your Apple Devices to incorporate changes Apple has made in the last year, including in iOS 27, iPadOS 27, and macOS 27. In the book, I dig into risks and likelihoods further. The book takes the tack that Apple, having secured a lot of our data, now has implemented many protections against physical access to our hardware, including theft, and explains how to enable, configure, and manage a wide set of features.
[Got a question for the column? You can email glenn@sixcolors.com or use/glennin our subscriber-only Discord community.]
Apple tracks and retains places you visit if Settings: Privacy & Security: Location Services: System Services: Significant Locations & Routes is enabled, which it is by default. This information is kept securely on your device (requiring authentication to view), and synced with end-to-end encryption among your devices. Familiar locations are derived from this data, which cannot be modified, only cleared. ↩
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.)
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.
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.
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.
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.
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.]
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[…]
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
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.
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.
[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.
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.
As longer, more complex passwords have become a necessity, remembering all those strings of numbers, letters, and special characters has become nearly impossible. Password managers can solve that problem, but what happens when you want to move to a different login organizer? Sure, you could manually type all your logins into a new app, but now Android can do that for you without the tedium.
Google designed the new login transfer process to happen entirely on your phone, so you need the corresponding apps installed with your credentials synced. To start the move, you'll have to find the import option in the app you want to use. The location of that feature will vary, but in Google Password Manager (built into Android), it's near the top under the settings tab.
The import option in Google Password Manager will plug in to the new migration system, while export still just creates an unencrypted CSV with your passwords that can be dumped into any app. It will be similar in other apps, so make sure to start the process in the app you want to use. Currently, this works in Google's app, 1Password, Bitwarden, and Dashlane.
As longer, more complex passwords have become a necessity, remembering all those strings of numbers, letters, and special characters has become nearly impossible. Password managers can solve that problem, but what happens when you want to move to a different login organizer? Sure, you could manually type all your logins into a new app, but now Android can do that for you without the tedium.
Google designed the new login transfer process to happen entirely on your phone, so you need the corresponding apps installed with your credentials synced. To start the move, you'll have to find the import option in the app you want to use. The location of that feature will vary, but in Google Password Manager (built into Android), it's near the top under the settings tab.
The import option in Google Password Manager will plug in to the new migration system, while export still just creates an unencrypted CSV with your passwords that can be dumped into any app. It will be similar in other apps, so make sure to start the process in the app you want to use. Currently, this works in Google's app, 1Password, Bitwarden, and Dashlane.
You might be interested in knowing how to embrace Apple Passwords with a bear hug, leaving behind your current password manager. If you tried Apple’s Passwords app in the past and were disappointed, you should probably give it another try. The improvements Apple has made in the last couple of releases have brought it to what I consider parity with the most important useful features of well-designed third-party password managers.
Despite that, Passwords is focused on—no surprise—passwords and password-like items: website logins, passkeys, and Time-based One-Time Passwords (TOTPs). Many password managers include a junk drawer of other kinds of structured material you can store that doesn’t map directly to Apple’s Passwords structure. If you’re mostly using a third-party system for password-esque stuff and use all Apple devices or Apple and a Windows PC, a migration is straightforward. Otherwise, it can be hairier and could involve rethinking how you store assorted data.
You can use iCloud Passwords with Windows (and then use Microsoft Edge, Firefox, or Google Chrome). You can also use browsers other than Safari on a Mac with an iCloud Passwords plug-in or extension. However, if you or people you currently shared information with use Android, Linux/Unix, or ChromeOS, this migration won’t work for you: those platforms aren’t supported, and there’s no web app for iCloud Passwords.
You may have oodles of passwords and other items stored in your current password manager, as I do.
Because Joe Kissell and I have written entire books that help with different components involved in a password manager migration, I’ll include references throughout to appropriate Take Control series books. For a general grounding in passwords, for example, I recommend reading Joe Kissell’s Take Control of Your Passwords, updated earlier this year.
Map the data connections
As I noted, Passwords is best at passwords (and passkeys and TOTPs), and filling them in on webpages and in apps. If you care mostly about this, you’re in luck, as you can easily migrate data of these kinds:
Website and app logins: Account logins move to Passwords.
Loose passwords: Ones that have no direct connection to an app or site, like a bank card PIN, also move to Passwords.
TOTPs: These confirmation codes can be migrated. However, there’s a technical detail with how they may be stored by third parties (or Apple) that can prevent the migration and might require using a backup code; see details below.
Passkeys: The password “industry” finally developed and rolled out a secure copying system that Apple supports that will let you move passkeys among password managers. This requires migrating on an iPhone or iPad; you can’t move these on a Mac.
Two other categories of fill-in entries that aren’t managed in Passwords can be handled—and you may already be using—in Wallet and Safari:
Payment cards: Payment cards need to move to Wallet & Apple Pay. You have to enter these manually as AutoFill Cards, unless you’ve already done so or added the card to Apple Pay. It’s a little complicated, as I explain.
Identities: Apple supports filling in personal or business address information through Safari using AutoFill.
(You can see Safari’s evolution on the Mac at Safari: Settings: AutoFill: your personal contact now links to Contacts, user name and passwords to Passwords, and credit cards to Wallet & Apple Pay.)
Where you will be left hanging by Apple:
Miscellaneous secure items and attachments: If you store Social Security numbers and other account information that is distinct from a password, but you want to have available to fill in at particular websites or by searching Passwords, you can create these as entries in Passwords. In some cases, you may want to create entries in Notes (with additional security, described later).
Structured data: You may have bank accounts, passports, driver licenses, memberships, software licenses, or other structured information stored in a password manager. That is a trickier needle to thread, as Passwords offers no support beyond a Note field.
For both of these, you might want to migrate to… a password manager. But wait! This would be one you use solely for secure storage of these miscellaneous structured or less-classifiable items, not for field-oriented secrets and accounts you want to fill in.
There’s one more important migration issue:
Shared vaults and items: If you use a password manager that supports secure storage areas with other people—like vaults in 1Password, Dashlane, or LastPass, for example—Passwords provides something akin, though not precisely the same: Shared Groups. Because of the above provisos, many non-password items shared via a third-party manager will need to be migrated to Notes or another secured shared item-storage-based space.
Three big things that may derail the whole migration for you:
Tags/labels: Some people make use of metadata organizational systems, like tags. These don’t transfer to Passwords at all!
Extra data: Much like the paper card catalogs of yore had book information plus tons of annotation, accumulated over time, you may have used password manager features to add extensive notes, additional fields, include attachments, and create richly detailed records. All that will be gone, like tears in rain. True, Passwords has a Notes field, but it lacks structure, rich text, and Markdown support. If you move to another, more focused password manager, you may be able to retain this.
Access after you’re gone: Non-Apple password managers have recovery kits that could allow a relative or other party who has that information to gain access to stored, synced data. Apple’s Legacy Contacts system, which allows an executor or other authorized person to access your data when you’re gone, excludes iCloud Keychain: no passwords, passkeys, Wi-Fi passwords, or other data. However, Legacy Contacts must be activated; until it is, it’s possible for someone who retains access to one or more of your devices to view your passwords and other data in Passwords. (See Joe Kissell’s Take Control of Your Digital Legacy, or my Take Control of Your Apple Account.
One last bit of aggravation? Passwords does not yet support removing duplicates!
Plan your migration
As you consider migrating, I urge you to run your old manager and Passwords in parallel.1 Particularly if you store a lot of different kinds of data in your old manager, you may want to be able to consult it and migrate some of it over time. This can be a pain if you are paying an annual fee and the renewal is coming up soon. Consult the maker’s website to see whether you retain access to your data after a subscription expires and, if that bothers you, in what form.
The place to start is pruning old entries.
First, sort by last modified date. Did I know that nearly 2,200 of my 2,600 entries haven’t been modified since 2022? Some since 2008? I did not. However, you likely don’t want to delete these wholesale, because there may be secrets you can’t recover. Online backup private keys (such as with Backblaze), Bitcoin and other cryptocurrency phrases or keys, or other secrets you set once need to be retained or you lose access forever.
My strategy:
Use Disk Utility to create a secure disk image and avoid saving password secrets to a backed-up location on your drive.
First, export everything. These exports are unencrypted and must be performed on your Mac. The export won’t include passkeys. (See below for that pathway.) This gives you a revert point. Because there are so many export formats across systems, I refer you to the software documentation to pick the best one. Warning: That file will be unencrypted and is like plutonium. Handle with care. The best plan is to use Disk Utility to create a disk image (APFS, 256-bit AES, Sparse Bundle Image), use a password you know or that is stored in Passwords, and then export directly to that encrypted image. The reason? If you save the file elsewhere, it might be backed up to Time Machine or become accessible in a way you didn’t intend. When unmounted, the drive is as secure as your startup volume. Just don’t forget or lose the password!
Exporting in the 1Password PUX format allows direct import into apps such as Strongbox.
Move all the older entries into a group. You might be able to create a group, tag all entries, or, in the worst case, move to a separate vault. In 1Password, the only strategy I found was to create a new vault called Outdated Entries and move all the older entries there. Warning: When selecting, make sure you aren’t including entries from all vaults, as that might move items you share with others or that others share with you.
Next, sort by name or title. This lets you scan through entries and identify duplicates. I found a number of items I’d already labeled “outdated,” or that were from services I couldn’t even remember. However, there were also a huge number of passwords and account logins that hadn’t been changed in more than four years—some for more than a decade! (There’s no reason to change uniquely set passwords routinely unless your current one is weak and a site is compromised. Most password managers, including Passwords, let you know about weak and reused passwords.) This process can be mighty tedious, which is why I’d recommend tackling it over time rather than all at once.
When you’re pruned, cleaned up, and otherwise reduced, you can now use the set you’re exporting; it’s time to go to the next step.
Export your secrets
Your best and first choice should be to use your iPhone or iPad; at this time, you can only perform a secure password storage transfer in iOS.2 Major password managers support this transfer method, which lets you move passkeys—it’s currently the only way to migrate a passkey.3
Navigate to the export section of 1Password—that’s Lock (upper-left corner): Settings: Advanced: Start Export.
Enter your account name; the app provides a hint. Tap “Approve export.”
An explanation screen appears. Tap Continue.
Choose the destination. In this case, tap Passwords, then tap Continue.
Tap Continue in “Passwords,” and you’re switched to the Passwords app, where you can watch the import in progress.
You can use an Apple framework in several password managers to transfer secrets securely to another manager.
While this is the best method, you can also export from most apps in CSV (comma-separated values) format, which truncates most information and likely leads to problems. Warning: You will have to re-create your passkeys. You may need to use the desktop version of the password manager to export. In Passwords for Mac, choose File: Import Passwords from File, click Choose File, select the file, and proceed. This doesn’t overwrite entries.
Now, check important accounts:
Does the regular login work? If not, reset the password. Take this opportunity to upgrade to TOTP or a passkey if either is available.
Does TOTP or a passkey work for logging in? If not, find a backup code or another method to generate a new TOTP or passkey.
TOTPs have a particular idiosyncrasy. They are seeded with a secret generated by a website. The site displays that code as a QR code, so you rarely need to copy it, though Password and other managers allow you to do so. When migrating an entry with a TOTP, it might appear in its URL format, which is generically like otpauth://totp/user@user.user?secret=SEQUENCE in the Notes field instead of appearing as a TOTP within Passwords. If that’s the case, you can fix it manually:
Copy the text after secret=.
Tap or click Edit.
Tap or click Set Up Code.
Paste the secret you copied into the Setup Key field.
Tap or click Use Setup Key.
Tap or click Done.
If that fails, log into the website in question and use a backup code or other means to re-enroll with TOTP.
Enter credit cards, set up AutoFill, and move to Notes
Before getting started, I strongly recommend enabling Advanced Data Protection in iCloud. ADP improves iCloud security by encrypting nearly all application data—iCloud Drive, Messages, Photos, Notes, etc.—via keys stored only on your devices, just like iCloud Keychain. Without ADP, these kinds of data are encrypted in transit and at rest using only Apple’s encryption secrets, and could be demanded via a government subpoena or someone gaining access to your Apple Account. (Note that contacts, events, and email remain encrypted at rest, not end-to-end, because of the need for compatibility with third-party software.)
Follow the steps in the link to enable. You can also still access this information via iCloud.com through a process that enables a temporary end-to-end session. (For more about ADP, see Joe Kissell’s Take Control of iCloud or my recently updated for the 27 releases, Take Control of Securing Your Apple Devices.)
Now, work through these categories:
Payment cards: Use Settings: Wallet & Apple Pay on an iPhone or iPad, or System Settings: Wallet & Apple Pay on a Mac. Tap or click AutoFill cards and authentication. Now you can tap or click Add Card to provide the card details. This lets you fill in the card anywhere there’s a form field or wherever you can tap or Control-click/right-click in a field and bring up AutoFill as a menu item. AutoFill cards sync across your devices when Wallet sync is active in iCloud (Settings/System Settings: Your Name: iCloud: See All). For more on working with Wallet and payment cards, see my book Take Control of Apple Wallet. This information is secured end-to-end.
Identity filling: A different kind of AutoFill, for identity information, is found in Settings: Apps: Safari: AutoFill or Safari: Settings: AutoFill. Enable Use Contact Info on an iPhone or iPad, or check “Using information from my contacts” on a Mac. Now you can tap the entry next to My Info on an iPhone or iPad, or click Edit to the right of the checkbox label. This lets you pick an entry—you probably already did—and populate it with all the things you’d want to fill in on a form, including multiple addresses. Safari doesn’t protect identity information with ADP. However, the type of address and other information you would use are likely the least important to protect in what would be a very unlikely break-in to an Apple Account or one of your devices.
AutoFill is a good dashboard for Mac-based ancillary personal data settings.
Fill in Notes: As I noted earlier, the structured entry style of third-party password managers doesn’t mesh well with either Passwords or Notes. Passwords has a single Notes field, which may be enough for some entries, but not the more detailed ones I describe. The Notes app is structured around entries, but it’s not well designed for hundreds or thousands, and it lacks inherent field data or structure. Judge what you’re storing in your old password manager to figure out if Notes could work. With ADP enabled, it offers strong security. For migrating structured data intact, read on!
Migrate structured data
If you’re looking to move structured entries, I suggest checking out Strongbox, but not for passwords, passkeys, TOTPs, and the like. Its developer offers a free syncing version (for iPhone, iPad, Mac, and Apple Watch) with everything you need except Touch ID/Face ID unlocking. That requires the Pro flavor at $24.99 per year, which includes several other features.5
Strongbox can be a good repository of structured data you want to keep secure.
Strongbox, unlike some managers, allows you to sync via a file under your control or through its secure syncing service, depending on your preference. This lets you keep your, er, digital strongbox under your personal control, if that matters to you. It can import from all major password manager export formats.
In testing, it preserved my 1Password structured data extremely well. This included tags. It also arranged my vaults into what it calls groups, letting me retain a sense of what I was sharing with others.
The one complication is that if you want to use one of the migration processes above to copy your items into Passwords, you have to do one of two things after performing your migration:
In your old manager, delete all passwords, passkeys, and TOTPs. This is dangerous in my accounting, as it reduces your ability to have a parallel working solution, and you could accidentally delete secrets you need to keep.
Import everything into Strongbox, then select all the passwords, passkeys, and TOTPs from Strongbox, and empty the trash. This gives you two copies of everything: Passwords and old password manager for secrets; Strongbox and old password manager for structured data.
When you’re ready to abandon your old password manager, maybe weeks or months from the migration, you can retain a securely stored backup copy or perhaps retain access depending on the product, while not using it actively or paying renewal fees.
Working in groups
The Shared Groups approach is rigid, but does let you have discrete vault-like secret sharing with other people.
Sharing your passwords and other secrets with other people remains Passwords’ weakest aspect, because Apple offers only Shared Groups. Each entry can be stored only in your personal Passwords storage or in Shared Groups. Otherwise, you have to duplicate an entry, which can cause such entries to drift out of sync.
In the Passwords app, select any entry, then click or tap the Group pop-up menu. You can then choose an existing group or create a new one. When you make your choice, the password, passkey, or other item is now exclusively found in the Shared Groups section, not copied! Passwords doesn’t offer a copy or duplicate feature, so you have to re-create the entry if you want to share it with two or more groups that aren’t a complete overlap of the same people.
It may be easier to understand from a family perspective. Let’s say you have items you share only with your spouse, others with your children, and some with both. You can’t create a “spouse” group and a “children” group. You need to have one for your spouse, one for your children, and one for the whole family. This is where there’s real room for improvement by Apple.
The password rhymes with orange
I know this is a whole rigmarole, but I’m actually impressed that it’s finally doable in a reasonable manner. A couple of years ago, it was not. It was possible a year ago, but I wouldn’t have recommended it. Now, if you’re careful with each step, maintain a backup, and keep your old manager running in parallel as you complete the migration, you should be able to achieve success.
This article was updated on Sept. 10th to add missing details about fixing a broken TOTP import.
[Got a question for the column? You can email glenn@sixcolors.com or use/glennin our subscriber-only Discord community.]
Frankly, I’ve been in this state for years: iCloud Keychain and then the Passwords app weren’t robust enough for a long time; as Passwords improved dramatically, I’ve gradually moved items over and set up new passwords only in Apple’s system. ↩
Apple supports this migration on all its platforms. It’s unclear why third-party storage apps don’t yet let you do it in macOS. ↩
I have noticed more sites let us create at least two passkeys, which is handy if you want to have passkey login in multiple password managers during a transition. ↩
This process can’t be screen captured on the device; I had to use another camera to take photos. ↩
You can also pay $2.99 a month, which seems silly, or $124.99 for a lifetime license, which I’d wait on—if I were you—until you’re sure you’ll use it for a few years or longer. ↩
Adds support for using as a macOS AutoFill provider to natively fill and save credentials in Safari and other apps. ($47.88 annual subscription, free update, 4.8 MB, macOS 12+)
The panel debates whether giving Claude controlled access to 1Password credentials is a practical automation feature or an unnecessary security risk, weighing trust, passkeys, vault isolation, and AI limitations. The conversation then shifts to the humor of waterproof phone holders and shower tech before wrapping with a discussion of how autonomous vehicles could reshape liability, […]
The panel examines a Bluetooth-related earbuds vulnerability, debating whether the issue lies in the protocol or Apple’s proprietary pairing approach, and why the implications feel unsettling. Chuck Joiner, David Ginsburg, Eric Bolden, Ben Roethig, Marty Jencius, Jim Rea, Jeff Gamet, and Guy Serle also touch on a useful tool born from a creator’s own workflow before turning to another LastPass incident and where it puts them on the trust spectrum.
The MacVoices Live! panel discusses Apple’s updated App Store review guidelines, the challenge of filtering low-quality or AI-generated apps, and whether trusted developers should receive faster review. Chuck Joiner, David Ginsburg, Jim Rea, Marty Jencius, Web Bixby, Jeff Gamet, and Eric Bolden also debate Apple’s Passwords app gaining automatic password-changing abilities, weighing convenience against account-lockout risk. They also provide reactions to Snap’s new Specs and the uncertain future of smart glasses.
AI is taking on a growing role in cybersecurity (whether we like it or not), from vulnerability discovery to faster exploit development. Chuck Joiner, David Ginsburg, Eric Bolden, Web Bixby, Jim Rea, Brian Flanigan-Arthurs, Jeff Gamet, and Marty Jencius look at both sides oof the issue and push back on “Bugmageddon” hype. The discussion also covers X post limits, Microsoft Teams retiring the misguided Together Mode, safer login practices, AI-run radio chaos, Google’s Apple-like naming choices, and free storage tied to phone numbers.
The Road to Macstock takes a serious turn as Mike T. Rose previews his workshop on becoming a digital caretaker for family members and loved ones. Mike discusses scams targeting older adults, password sharing, remote support, Apple Passwords, financial preparedness, and the need to balance protection, respect, independence, and trust when helping others manage their digital lives.
Apple today announced that the Passwords app can now automatically update weak and compromised passwords using Apple Intelligence and Safari to take action on a user’s behalf.
[…]
Apple describes the system as agentic, with Apple Intelligence and Safari securely navigating through websites, signing in, and upgrading accounts to strong passwords without the user needing to intervene beyond an initial tap.
Raise your hand if you’re going to trust an AI agent with your passwords.
Maybe it’s architected so that the agent doesn’t see the actual passwords, but I find the idea of this ghost surfing through sites, logged in as me, really creepy.
Passwords has an agentic AI feature that will scan your list of compromised passwords and then present you with a list of the ones it believes it can update for you. Even on that subset though, my experience was uneven, with just 5 of 18 updated. It’s a very cool idea, and should hopefully see improvements as the technology progresses, but right now it’s hit or miss.
Maintenance release with a handful of improvements and bug fixes for the password manager. ($47.88 annual subscription, free update, 4.8 MB, macOS 12+)
Researchers have uncovered a massive breach of Fortinet firewalls that has given Russian-speaking attackers near-unrestricted access to some of the world’s largest and most powerful organizations, including Oracle, Chevron, Lenovo, Federal Express, a NATO defense contractor, and Fortinet itself.
Nearly 74,000 Fortinet devices from more than 21,000 IP addresses in 194 countries have been compromised and their plaintext credentials exposed online, Bob Diachenko, a security researcher and head of SecurityDiscovery.com, said online and in an interview. He said he found the data after gaining access to the attackers’ command-and-control server and other infrastructure. The exposed data also included the industry, revenue, and employee count for each compromised organization.
Exceptional scale, poor opsec
Independent researcher Kevin Beaumont reported that “almost all” of the compromised devices remained online as of Wednesday morning. He went on to say that he has confirmed with multiple organizations found in the attackers’ logs that the credentials are real and current. In many cases, once the threat actors compromised the devices, they went on to access affected organizations’ centralized authentication systems, such as Radius servers and Microsoft Active Directory. The number of compromised devices comprises roughly half of all Internet-facing Fortinet firewalls, based on polling from Shodan.
Researchers have uncovered a massive breach of Fortinet firewalls that has given Russian-speaking attackers near-unrestricted access to some of the world’s largest and most powerful organizations, including Oracle, Chevron, Lenovo, Federal Express, a NATO defense contractor, and Fortinet itself.
Nearly 74,000 Fortinet devices from more than 21,000 IP addresses in 194 countries have been compromised and their plaintext credentials exposed online, Bob Diachenko, a security researcher and head of SecurityDiscovery.com, said online and in an interview. He said he found the data after gaining access to the attackers’ command-and-control server and other infrastructure. The exposed data also included the industry, revenue, and employee count for each compromised organization.
Exceptional scale, poor opsec
Independent researcher Kevin Beaumont reported that “almost all” of the compromised devices remained online as of Wednesday morning. He went on to say that he has confirmed with multiple organizations found in the attackers’ logs that the credentials are real and current. In many cases, once the threat actors compromised the devices, they went on to access affected organizations’ centralized authentication systems, such as Radius servers and Microsoft Active Directory. The number of compromised devices comprises roughly half of all Internet-facing Fortinet firewalls, based on polling from Shodan.
An alleged Russian-speaking group of cybercriminals is reportedly compromising and targeting several major companies that use Fortinet Firewalls and VPNs through previously known passwords.
Login
