TOTP in your password manager vault — the convenience and the circular risk

Storing TOTP codes in your password manager vault is the most contested security trade-off in consumer password management. The case for it is practical: one app holds both the password and the authenticator code; autofill handles both at login; no app switching; no risk of losing a separate authenticator app when you switch phones. The case against it is architectural: two-factor authentication exists specifically to create a second independent factor. Storing both factors in the same vault means a single compromise — the vault — gives an attacker both.

Security practitioners disagree on which position is correct. This is not a case where one side has obviously better arguments. The right answer depends on your specific threat model and which failure scenarios you weight more heavily.

There is one concrete failure mode that is not theoretical and applies regardless of threat model: the circular lock-out scenario. If the vault is locked and the TOTP source for the email account you use to recover the vault is inside the vault, you have created a situation where you cannot get in to anything. This is not a catastrophic security failure — it is a usability failure with permanent consequences.

The assumption 'storing TOTP in the vault defeats two-factor authentication entirely' overstates the security reduction. The vault itself has a second factor — your vault login is protected by a master password plus optionally a hardware key or a separate TOTP code. The TOTP codes stored inside the vault are a second layer for individual accounts. If the vault is compromised (requiring the master password to be cracked or obtained), the attacker gets both. But 'both factors vulnerable to vault compromise' is a different threat than 'no second factor at all.'

A second assumption is that a dedicated authenticator app is inherently more secure. A dedicated TOTP app protects against vault compromise but introduces its own risks: app loss when switching phones (if TOTP seeds weren't backed up), app unavailability, and the operational friction that leads some users to disable 2FA entirely. A 2FA setup that is used consistently is more protective than a 'stronger' one that gets abandoned.

A third assumption is that the circular lock-out problem is rare. For users who store TOTP in their vault, use the vault's email address as the account email for critical accounts, and use that same email address for vault recovery — the circular dependency is common rather than theoretical. Specifically: if Bitwarden is your TOTP source for Gmail, and you use Gmail for Bitwarden account recovery, losing vault access creates a loop.

The practical recommendation that resolves most of the tension: use the vault for TOTP on standard accounts, and use a separate authenticator (or hardware key) for your highest-value accounts — specifically email accounts and any account used for password manager recovery. This compartmentalises the circular lock-out risk to the accounts that matter most while keeping day-to-day TOTP in the vault for convenience.

Bitwarden Premium and Proton Pass both store TOTP seeds in the vault and generate codes during autofill. The implementation is encrypted and secure. The security consideration is not 'is it safe to store TOTP seeds there' — it is — but 'which accounts should have their TOTP stored separately to maintain meaningful factor independence for the vault recovery path.'

Hardware security keys (FIDO2/WebAuthn) eliminate the circular lock-out problem for the vault itself: a hardware key as the second factor for vault login is a separate physical device, not data stored inside the vault. This is the architecture that resolves the TOTP-in-vault trade-off most cleanly for users who want full factor independence on the vault.

This guide discusses TOTP (time-based one-time passwords). The trade-off analysis differs for passkeys, which are stored per-site rather than in a central authenticator and have different independence properties.