Can you back up 1Password?
Yes. What you should not do is keep two live password managers "always in sync." That second idea is where people quietly lose data or lock themselves out, and it comes up in almost every conversation we have with a founder who has just started taking security seriously.
1Password already keeps a server side copy of every vault and item, backed up daily, and you can restore earlier versions of an individual item. A deleted vault is gone for good, so archive items instead of deleting a vault when you want to clean house.
That cloud copy is not a substitute for two other things. It does not help you get back in if the account itself is the problem, and it is not a copy you control if you ever need one.
The same question now has a second half. Small teams are handing API keys, tokens, and logins to AI agents that run in the terminal, in the browser, and in the background. Those keys need the same discipline as the vault, and most of the advice below applies to them with one important twist: the agent's keys should never live in the same place as yours.
What actually protects you: three layers, not two apps
Treat this as three layers instead of two apps talking to each other. Each layer covers a different failure.
The first layer is access to the 1Password account itself. The second is a cold copy of the vault that you hold. The third is a second manager used as a snapshot, never as a live twin. Companies that run security at scale add a fourth: a separate identity for every machine and agent, so a leaked automation key never exposes a human's vault.
How do you make sure you can always get into 1Password?
Get a current Emergency Kit from 1Password.com (your name, then Manage Account, then Save Emergency Kit). Print it. Write the account password on the paper copy. If your 1Password login uses an authenticator app, write the 16 character 2FA secret next to the QR code as well. Put one copy with important papers or in a safe, somewhere that is not only on a computer.
Also generate 1Password recovery codes if your plan allows it. Those are for "I can't sign in." They are not a dump of every password.
Do not store the only copy of 1Password's own 2FA inside 1Password. A hardware key (YubiKey or similar) registered as a sign in method, plus printed recovery material, is the usual setup when the vault holds a lot of TOTP seeds. Keep 1Password signed in on at least two devices you use every day. If you unlock 1Password with a passkey, 1Password still requires a recovery code, so keep that code.
How do you make a cold backup of the vault?
From the 1Password 8 desktop app you can export in two formats. The .1pux file is the fullest official dump: vault structure, custom fields, attachments, and TOTP seeds. It is the format to use if you ever need to get back into 1Password later. CSV only carries Login and Password items with a short field list. It misses custom fields, security questions, linked items, and 2FA backup codes. Fine as a readable last resort, not as the only copy.
The official warning is not marketing: both export files are plaintext. Anyone who gets the file can read every password. Do not email them, do not drop them in Drive, Dropbox, or iCloud unencrypted, and delete the plaintext once you have an encrypted copy.
The routine we recommend:
- Export .1pux, and CSV too if you want a second format.
- Immediately put the file in an encrypted container you control: a password protected archive, VeraCrypt, Cryptomator, age, or GPG. Pick one you already know how to open in a disaster.
- Copy the encrypted file to offline media. Two USB drives or an encrypted disk, stored in different places.
- Securely delete the unencrypted export from the computer and from any Downloads, Time Machine, or cloud backup path that may have scooped it up. 1Password themselves say to turn off backup software before an unencrypted export for exactly this reason.
- Repeat on a cadence that matches how often the vault changes. Monthly is plenty for most people. Quarterly if it barely moves.
Passkeys are the awkward part. Desktop .1pux and CSV exports generally do not take passkeys with them. 1Password documents passkey export on iOS and Android, and the newer OS level Credential Exchange flow can move passkeys app to app. If you rely on passkeys, a file export is not a complete backup of those, which is why the next section exists.
Should you run a second password manager in sync with 1Password?
No. There is no official, safe, continuous two way sync between 1Password and Bitwarden, Apple Passwords, KeePass, or anything else. 1Password's own support line on running it next to iCloud Keychain is to pick one primary, or you will get duplicates and stale logins. That applies to any pair.
What does work is a one way copy on a schedule.
| Approach | Good for | Not good for |
|---|---|---|
| Periodic .1pux, encrypted, offline | Disaster recovery, account lockout, the vendor going away | Day to day use |
| One way import into KeePassXC (it reads 1PUX) | A local encrypted file you hold, with no second cloud vendor | Autofill everywhere, passkeys, staying in sync |
| One way import into Bitwarden | A second cloud you could live in if you left 1Password | Live sync; attachments and some item types need cleanup |
| iOS or Android Credential Exchange into another app | A clean migration, including passkeys and TOTP on supported apps | Keeping both updated forever |
KeePassXC importing 1PUX is the cleanest "I want another copy that is not 1Password's" option when the goal is backup, because the result is a local encrypted database you can put on the same offline media as the .1pux.
Community scripts exist that sync two databases for other pairs, usually KeePass and Bitwarden. We would not point one at a vault full of 2FA seeds and legal or financial files.
What does a company like Meta do to back up its passkeys?
It does not back them up the way you back up a CSV, because it cannot. The private half of a passkey is designed so it cannot be copied into a file. What a company that size does instead is register more than one key and plan for lockout. That is the model to copy.
When you create a passkey, two things happen. The private key stays in an authenticator: the phone's secure enclave, 1Password's encrypted vault, or a hardware key. It is not supposed to exist as plaintext on disk. The public key plus some metadata goes to the website. That is all the company can back up on its side.
So a large company can lose a building and still have your public key. It cannot reconstruct the private key if you lose every copy of it. Their disaster plan is not "restore the secret." It is "this person already registered a second authenticator," or "identity proof them and let them enroll a new one." That is also why 1Password's desktop export deliberately leaves passkeys out. Dumping the private key into an unencrypted file would defeat the point of a passkey.
Companies at that scale mix two kinds of passkey and require redundancy. Synced passkeys, the kind you have in 1Password and the kind the big platform vendors use for normal staff, wrap the private key with end to end encryption and copy it through the provider's sync fabric. Lose the phone, sign into 1Password on a new one, the passkeys come back. Recovery means recovering the vault account, not recovering each site.
Device bound passkeys on hardware keys are used for admins and anything that would hurt if it leaked. The private key never leaves the chip. Lose the key and that credential is dead. Policy is to issue two keys, register both before turning off the old login, and keep one in a safe.
On top of that they always have a break glass path that is not another copy of the same secret: a second registered passkey, a helpdesk recovery after an ID check, printed recovery codes, sometimes a short lived admin issued pass. The FIDO Alliance's own guidance to sites is to allow multiple passkeys, label them, and let people delete the lost one. Nobody at that scale runs two password managers in sync. They pick one sync fabric per person and add a second authenticator.
How do you set up passkeys so you can never lose access?
Your 1Password passkeys are already backed up inside the 1Password account. Lose a laptop, install 1Password elsewhere, sign in with the account password and Secret Key, and the passkeys are there. The thing you must not lose is access to 1Password itself, which is what the Emergency Kit section above handles.
Then apply the same rule the big companies use: never one passkey per important account. For every account you cannot afford to lose (primary email, Apple or Google ID, bank, 1Password, and wherever your 2FA recovery email lives) keep one passkey in 1Password for daily use and a second passkey on a hardware key or in a different ecosystem such as Apple Passwords or Google, registered as a backup and then left alone.
Two passkeys in the same 1Password vault are not two copies. They are one basket. The second authenticator has to survive 1Password being down.
Keep the boring fallbacks. Passkeys do not replace recovery codes, backup codes, or a password the site still accepts. Download those codes once, put them in the encrypted offline backup you already planned for passwords, and keep a paper copy for the worst ones. If a site still lets you keep a password next to the passkey, keep it in 1Password. That is your helpdesk when the passkey provider is the thing you cannot open.
Treat Credential Exchange as a move, not a backup. On iPhone and iPad you can export passkeys from 1Password into Bitwarden or Apple Passwords through the system transfer. That is a migration. It is not a nightly sync and it is not a file you can drop in a safe.
Know which passkeys are actually synced. When a site offers a passkey, watch where the operating system wants to save it. If it saves into the phone's own keychain instead of 1Password, that passkey dies with the phone or with that Apple or Google account. For anything serious, force it into 1Password or onto a hardware key.
How should AI agents use keys without touching your vault?
An AI agent that can read your files, call APIs, and open web pages is a new employee with a very fast typing speed and no judgment about which secrets it is allowed to see. The most common mistake we see in small teams is giving that employee the founder's own credentials, usually by pasting an API key into a prompt or into a .env file the agent can read.
The rule is the same one large companies apply to service accounts: an agent gets its own identity, its own keys, and the narrowest scope that does the job. It never gets the human's 1Password login, never gets the Emergency Kit, and never gets a passkey, because passkeys are built for a person proving presence on a device. An agent authenticates with a token or an API key that can be revoked in one click without touching anything a human uses.
In practice that means a few habits.
Keys come from a secrets manager at run time, not from a file in the repo. We run agents through a broker that injects the key into the process that needs it and nowhere else. Infisical and 1Password's own Environments feature both do this. The agent's prompt never contains the value, only the name of the key.
Every agent key is scoped and rotated. A coding agent that publishes a blog post needs write access to one site, not to billing. A research agent needs read access to a search API, not your email. When an agent's task ends, the key it used is still valid, so rotate on a schedule and revoke the moment a key shows up somewhere it should not.
Agents get their own accounts for signups and test mail. If an agent needs an inbox to receive a verification code, give it a dedicated test inbox. Never let it sit in your real mailbox reading 2FA codes.
Gated actions stay gated. Committing, deploying, paying, publishing, and anything that changes access rights should need a human's explicit word in the request, even when the agent technically holds a key that could do it. The key gives the agent the ability. The rule gives it permission.
There is one more reason this matters for the backup story. When you export 1Password to a .1pux file, an agent with access to that directory now has every password in plaintext. Do the export on a machine or in a folder no agent has permission to read, encrypt it, and delete the plaintext before any automation runs again.
What does the whole setup look like?
You cannot get a guarantee of "never lose access" from cryptography alone. You get it from independent paths, so that no single failure takes out every way back in.
| If this fails | You still have |
|---|---|
| Your phone dies | 1Password on another device |
| Your 1Password account is locked | Emergency Kit, recovery codes, and the hardware key |
| 1Password the company is gone | Hardware key passkeys already registered on the sites, plus passwords and recovery codes in the offline backup |
| House fire | The second hardware key and paper kit stored somewhere else |
| You are unavailable | Someone you trust who can open the kit (a family vault or written instructions) |
| An agent's key leaks | Revoke one scoped token; the human vault was never reachable |
That last row for people is the part large companies staff with HR and a helpdesk. At home it is a printed kit and one other person who knows where it is. The last row for agents is the part most small teams have not built yet, and it is usually a day of work: one secrets manager, one identity per agent, keys injected per process.
Keep 1Password as the daily driver. Put the Emergency Kit, recovery codes, and a hardware key on the 1Password account. Keep an encrypted .1pux on two offline drives, updated on a schedule. Register a second passkey outside 1Password on every account that recovers something else. If you already have a second manager "just in case," use it as a periodic import destination and leave it alone until the next backup. Give every AI agent its own scoped keys through a broker, and never the vault.
After any test export or import, delete the plaintext file and confirm you can open the encrypted backup on a second device before you need it.
