The Claim Under Test

If your password and your TOTP seed live in the same 1Password vault, unlocked by the same master password, you are running two-step verification (2SV), not multi-factor authentication (MFA). Same secret store, same unlock event, same attacker who now has both factors the moment they get one.

This isn’t a hot take. It’s already worked out, published, and ignored, largely because PCI DSS Requirement 8.3 only mandates two factors from two categories, not factor independence or phishing resistance, and most cyber insurance underwriting still treats SMS OTP as an acceptable floor for standard users, even as carriers increasingly downgrade or reject it for privileged accounts. It’s really the same reason why faxing in the USA is considered acceptable for patient health data: HIPAA’s Security Rule requires reasonable and appropriate administrative, technical, and physical safeguards for transmitting e-PHI, not a specific transmission technology, so fax was never excluded and never got re-evaluated once better options existed. Not because either is safe or secure: because it’s legacy knowledge enshrined in permanance. The compliance bar and the security bar diverged years ago for MFA and 2SV; the industry kept building to the compliance bar.

2SV vs. MFA

The industry blurs “two-step” and “multi-factor” like they’re the same thing. They aren’t, engineers and designers who wrote interfaaces and workflows often don’t know the difference, either, and added to the confusion.

PCI’s own supplement draws the line cleaner than most vendors. Its independence section states the requirement directly: authentication mechanisms “should be independent of one another such that access to one factor does not grant access to any other factor, and the compromise of any one factor does not affect the integrity or confidentiality of any other factor.” Scenario 1 in the same document works the case explicitly: one set of credentials unlocking a device that also holds the OTP token collapses to “something you know” used twice, not two factors. Scenario 2 is the password manager case: single login unlocking both a cached password and a software token is flagged as failing independence, full stop.

That’s the test. Not “did I enter two things,” but “does compromising step one hand the attacker step two for free.” A password unlocking a vault that also spits out the TOTP is Scenario 2. Two steps, one factor, dressed up as MFA because the UI asked for input twice.

I believe this is one of those things that Microsoft had foresight on long before most, they never called their system 2FA. They well-documented the limitations of authentication methods in use, and always called it MFA. However, the criticism there is they haven’t done a great job ensuring you’re actually presenting MFA. They let you use a Password + TOTP (single-factor) and check their “multifactor enabled” boxf or a false sense of security- so to solve this issue they created they now have “phishing-resistent” MFA, which has seen terminology adoption in the industry. Google and 1Password, to contrast, called it 2FA and largely benefitted from condensing this from “Think about your factors” to “trust us bro”.

Why Passwords?

As a quick aside, someone, long ago, decided the best way to do computer authentication wasn’t using a key, like your house or car, but it was using something you “remembered”. That decision, made in innocence outside of the internet, has huge repurcussions today. I’m thankful that Microsoft’s Passwordless push, for instance, is gaining more and more awareness and moving us away from the fundamentally bad designs of the past.

What NIST Actually Says

NIST SP 800-63B is explicit: OTP authentication is not phishing-resistant. That line appears for both single-factor and multi-factor OTP authenticators. Out-of-band authentication (SMS, push) gets the same designation.

The reasoning is architectural, not procedural. SP 800-63B-4 describes single-factor OTP authenticators as containing two persistent values: a symmetric key that persists for the authenticator’s lifetime, and a nonce that changes per use or on a clock. That symmetric key is a shared secret. It exists on the authenticator and is duplicated on the verifier side. Anything built on a shared secret can be captured and re-used or replayed. In fact, 1Password and other password managers call these features, because the symmetric key gets marked exportable so that it can be synced to other devices for portability. After all, you need access to the vault on your phone, laptop, etc.

NIST’s phishing-resistance requirement at AAL3 calls for single-factor cryptographic authenticators using public-key cryptography instead, as a private key never leaves the device, nothing to intercept, nothing to relay. That’s the FIDO2/WebAuthn/passkey model. Revision 4 places explicit emphasis on phishing-resistant authenticators for exactly this reason, and federal guidance now points agencies toward syncable passkeys (commonly known as passkeys) as the phishing-resistant path forward, per NIST’s supplemental guidance on syncable authenticators. The reason passkeys succeed where OTP does not is the passkey is bound, at time of creation, with the creator’s domain information. That passkey is only ever valid at that domain. Click on a fake Microsoft domain, your passkey won’t prompt because there’s a mismatch. The reason it’s reliable is it’s baked into the browser: the user never gets the chance to hit “trust this mismatch”, additionally: the authenticator itself performs a second verification of this match.

None of this is new commentary. A 2022 NIST CSRC presentation on MFA and SP 800-63 states it directly: shared secrets don’t stay secret, and any MFA based on shared secrets can be phished. Strong MFA requires asymmetric key cryptography. OTP has never met that bar. NIST didn’t discover this in Revision 4 — the classification predates the 2026 timeframe by years. The industry just kept selling OTP as “MFA” because it clears the compliance checkbox laid by PCI for “something you have.”

What Gives, PCI?

Interestingly, PCI noted in February 2017, citing a mid-2016 draft of NIST SP 800-63B, that NIST “currently permits the use of SMS.” NIST landed on “restricted” instead, deciding SMS was permitted, but conditioned on verifying the number is bound to an actual mobile device (not VoIP), treating any number change as binding a brand new authenticator, and watching for SIM-swap or porting signals. PCI’s SMS section doesn’t carry any of those conditions forward, it’s one paragraph, permission stated, no caveats attached.

Why PCI would cite “NIST permits SMS” without the conditions attached to that permission is up to you to decide.

The Collapse Mechanism

Here’s the part that gets skipped in vendor docs: MFA’s security model depends on factor independence. Compromise of one factor should not yield the other. Two secrets, two attack surfaces, two recovery paths.

1Password’s TOTP-in-vault feature vaporizes that independence on purpose, for convenience. 1Password’s own writeup acknowledges the mechanics without flinching: “While you turn on the 2FA setting in your account, and subsequent sign-ins require your password and a TOTP, you lack a true second factor when both secrets originate from the same device.”. This arrangement is 2SV, not 2FA. Compromise the vault — weak master password, malicious browser extension, an infostealer that scrapes the unlocked session, a synced device that gets compromised, and the attacker has both the password and the OTP seed in one motion. There was never a second lock to pick.

This is stated plainly, elsewhere too: storing 2FA codes next to credentials is marginally less safe because the token is accessible to the attacker if they successfully compromise your password manager. “Marginally” is doing a lot of work in that sentence for something that removes an entire authentication factor.

I’m going to go out of my way and also mention that 1Password is one of the easiest bills that I pay for personally. It has great value and is a well-designed product with a great track record of security.

Why This Matters More Than It Used To

Even where OTP is technically separated from the password vault — dedicated authenticator app, second device — it’s still phishing-susceptible by NIST’s own classification, because the shared secret still has to cross the wire to a verifier, and a real-time adversary-in-the-middle proxy (Evilginx-class tooling, now commodity) captures and replays it in the same session the victim thinks they’re logging into. A password+OTP is always going to be both “what you know” and not something you have. Domain matching in 1Password blocks the sloppy phishing case — lookalike domains don’t trigger autofill — but it does nothing against a transparent reverse proxy sitting in front of the real domain, because the domain in the address bar is technically correct while the session token gets stolen behind it.

OTP was already the weak tier. Collapsing it into the same vault as the password removes the one property (factor independence) that made OTP tolerable as a stopgap in the first place.

The Pragmatic Compromise

Separating every boundary perfectly is a pain in the ass. I get it. Nobody is running a distinct hardware token or dedicated authenticator app for every one of the forty accounts they hold, and pretending otherwise is how security advice gets ignored wholesale instead of partially.

For the long tail of accounts (some random forum, a subscription service) that don’t support passkeys and never will, 1Password holding the OTP is a reasonable compromise. Those accounts are stuck at AAL2 regardless of where the seed lives; the seed being in your password vault instead of a separate authenticator app is a marginal difference against a threat model (someone popping a random social account) that usually isn’t worth architecting around. The critique in this post is aimed at what that convenience is being sold as, not at the convenience itself.

Storing passkeys inside 1Password is a different question entirely and a good trade. A passkey isn’t a shared secret the way an OTP seed is — it’s a private key, still bound to its origin domain regardless of where the private key material sits. Centralizing passkeys in a vault doesn’t recreate the factor-independence problem the same way TOTP-in-vault does, because there’s no symmetric secret to collapse against the password in the first place. If 1Password’s own encryption model holds, per their authentication and encryption documentation, the passkey material is protected independent of whatever gets an attacker into the account UI.

1Password’s Own Contradiction

Here’s the part that annoys me. 1Password’s documentation states plainly: “The 1Password apps don’t need two-factor authentication. 1Password accounts use Two Secret Key Derivation (2SKD) to make sure no one can access your data without both your account password and your Secret Key.” Point four on their own list.

And then their two-factor authentication page says: “Two-factor authentication is an extra layer of protection for your 1Password account. When turned on, a second factor will be required to sign in to your account on a new device, in addition to your 1Password account password and Secret Key.”

If it didn’t “need” it, why did they build it and then admit it adds an extra layer of protection? Isn’t that making security decisions for the users? Or is this just a case of the marketing team not being in step with engineering building it? The 2SKD claim is about data-at-rest: even a total failure of the authentication layer doesn’t hand an attacker plaintext, because decryption isn’t gated by login, it requires the password and Secret Key material directly. The 2FA claim is about account takeover on a new device: someone who has phished or stolen your password and, somehow, your Secret Key, still gets stopped at the new-device sign-in gate if 2FA is on.

Fine. Those are two different threat models and neither statement is technically false. But shipping “you don’t need 2FA” as a headline claim while simultaneously building and marketing 2FA as “an extra layer of protection” is the kind of framing that makes users underestimate what protects them and why: scroll back up to the start of this post talking about the conflation of 2FA and MFA and 1Password is a prime example of this. If the account password and Secret Key are ever both compromised — infostealer, synced device popped, whatever — 2SKD’s data-at-rest guarantee doesn’t save you from someone signing in as you on a new device and reading everything through the app itself, which is the exact scenario 2FA exists to stop. Say that plainly instead of “you don’t need it, but also here’s a layer of protection.”

The same conflation shows up again a few paragraphs later on that same 2FA support page: “If your team uses Duo, you won’t see the option to turn on two-factor authentication because Duo is already providing multi-factor authentication for everyone on your team.” Duo gets called multi-factor. Their own built-in feature gets called two-factor, on the same page, treated as redundant with it rather than stackable. That’s the exact pattern this post opened with — the words used interchangeably by the same company in the same breath — showing up inside their own documentation.

What Compliant Actually Looks Like

  • AAL2 minimum: separate the factors physically or logically. Password manager holds the password. A distinct authenticator app or hardware token holds the OTP seed, on a different unlock boundary.
  • AAL3 / phishing-resistant: move off shared-secret OTP entirely. FIDO2/WebAuthn hardware keys or platform passkeys. Public-key cryptography, private key never transmitted, nothing for a proxy to capture and replay.
  • If OTP is unavoidable (legacy vendor, no passkey support): dedicated authenticator app, not the password manager. Different compromise path required for each factor.

For an engineer auditing your own org’s auth posture, the check is one question: if someone gets root on your laptop or your password manager’s cloud sync, do they get into your production accounts with zero additional friction? If the TOTP seed and the password answer to the same unlock, the answer is yes, and the MFA requirement in your compliance framework is decorative.