An authenticator for people with a lot of accounts
Updated 21 September 2026.
Five accounts is easy. Any authenticator handles five.
Fifty becomes a search problem: the code you need is somewhere in a scrolling wall of six-digit numbers, and the entry labels were written by the services, not by you. Two hundred becomes an organization problem, and a different kind of one — now you have four entries called Amazon Web Services and no way to tell which is the production root account, which is your personal account, and which two belong to clients you onboarded last year.
That is the point where authenticators stop being adequate, because almost all of them are one flat list with a search box bolted on. KeyNesta is built for what comes after.
The short version of this argument is on the blog: an authenticator app with folders and groups.
Four levels, and what each one is for
| Level | Use it when | Boundary |
|---|---|---|
| Vault | Two sets of codes must not mix — your own and a client's, or work and personal on a work-managed phone. | Cryptographic. Separate passphrase, separate master key, separate sync account. |
| Space | Broad divisions inside one vault, each with its own colour, auto-lock and visibility policy. | Organizational, with its own security policy. |
| Group | The actual filing: provider, then environment, then client. Groups nest as deep as the work does. | Organizational. |
| Tag | The facts a tree cannot hold — which accounts are root, which are shared with a colleague, which are scheduled for decommissioning. | Cuts across everything. |
What that looks like filled in
Work (space)
└─ AWS (group)
└─ Production (group)
└─ root@example.com #root (entry)
Clients (space)
└─ Client A (group)
└─ Cloudflare
└─ admin@example.com #shared
Personal (space)
└─ Finance
└─ Exchange
└─ account@example.comThe value is not the tidiness. It is that root@example.com is now unambiguous at a glance, because the path says production AWS and the tag says root. A flat list gives you the same entry name with no way to tell it from the staging one.
Finding one code in two hundred
Search is ranked and covers the entry name, the issuer, the account name, the tags and the full group path. So prod aws lands on the production root account without you remembering the filing, and client a cf gets to Cloudflare for that client. On the web app the same search is a keyboard-driven command palette, which matters when the whole interaction is meant to take three seconds in the middle of typing a password.
Favourites pin the handful you use daily to the top. The archive takes the entries you cannot delete but never open — old employers, decommissioned servers — out of your way without losing them.
When to use a second vault instead of a space
Spaces organize; vaults separate. Use a second vault when the separation needs to be real: client work you may have to hand over or destroy, a shared team credential that should not sit in your personal vault, anything you would not want visible on a device someone else can unlock. Each vault has its own passphrase and its own master key, so unlocking one tells an attacker — or a colleague looking over your shoulder — nothing about the other. They appear as separate entries on the lock screen picker.
The trade-off is real and worth stating: another vault is another passphrase, and a passphrase you type once a month is one you can forget. Two or three vaults is a system. Nine is a future support ticket we cannot resolve for you.
Getting two hundred accounts in without a bad afternoon
Bulk import is the whole point here. KeyNesta reads Google Authenticator's transfer QR, Aegis and 2FAS exports, generic JSON, CSV, and lists of otpauth:// URIs. Every import shows a preview with duplicates already flagged — which is what you want when you are merging three phones' worth of history — and the entire import can be undone in one action if the preview was not what you expected. Then file them: entries move between spaces and groups freely afterwards, so import first, organize second.
Start with importing from Google Authenticator or from Aegis and 2FAS. Authy is the exception, and the one people ask about most: it has no export at all, so those accounts have to be re-enrolled one by one rather than imported.
The part that scales worst if you get it wrong
Backups. One phone holding two hundred codes is not a filing problem, it is a single point of failure attached to every account you own. Encrypted sync, or an encrypted backup file you keep yourself, turns losing that phone into a ten-minute restore — hierarchy intact, because spaces and groups sync as encrypted objects like everything else. See 2FA backup and sync, and, if it has already happened, lost phone recovery.
Frequently asked questions
How many spaces, groups and vaults can I create?
All unlimited, including nesting depth, and they stay free. The sensible limit is your own: one vault per genuinely separate context, spaces for the broad divisions inside it, and groups as deep as the work actually is.
Can I move an entry between spaces or groups later?
Yes, at any time, and nothing about the code changes when you do — the secret, issuer and parameters are untouched. This is why bulk importing first and filing afterwards is the faster order to work in.
Does my hierarchy sync, or only the codes?
Spaces, groups and settings sync as individually encrypted objects alongside the entries, so a new device rebuilds the whole structure, not a flat list. The server stores them as ciphertext and cannot read the names.
What happens to my filing if I delete a space or a group?
Nothing is orphaned. Deleting a group moves its entries and sub-groups up to its parent; deleting a space moves its contents to the first remaining space, and the last space cannot be deleted. Deleted entries sit in the trash for 30 days.
Try KeyNesta free. The web app needs no sign-up.
Open the web app All platforms