Password Manager and Authenticator Comparison

A vault comparison starts with custody paths, not a winner

Account identity, data location, export, recovery, passkeys, TOTP, audits, and source availability are separate documented questions across the four frozen rows: 1Password, Bitwarden, KeePassXC, and Proton Pass.

A password manager authenticator comparison becomes misleading when it compresses every documented attribute into one privacy or security label. The account used to enter a service, the entity operating it, the place data is held, the way a vault can be exported, the route for recovery, and the placement of an authentication factor are different parts of the custody path. This page keeps those parts separate and supplies no score, rank, best label, preferred product, or recommendation.

The roster was frozen before the page was written. Each row has one current persisted cell for each of fifteen preregistered attributes. A displayed value therefore comes from the exact product row and exact attribute shown in the table; it is not borrowed from another product, inferred from marketing language elsewhere, or filled from a superficially similar field. Product, plan, region, platform, claim type, source class, source URL, capture date, and observation version remain attached to each cell.

The matrix compares published evidence rather than product behavior observed through account creation or testing. A vendor architecture statement remains a vendor-stated claim. A public repository remains evidence for the component and scope it names. An assessment record remains evidence of the stated assessor, scope, standard, date, and limitations. None of those evidence types silently becomes a guarantee about the whole service.

Use the privacy-tool comparison methodology and corrections hub for its preregistered roster and attributes, claim labels, capture dates, and correction path. The product cells below carry the product-specific facts. The email alias service comparison covers a neighboring account-identity layer, while the private phone number app comparison applies the same separation to another recovery and identity path.

What identity the product collects and what can trigger later verification

Initial signup identifiers and later verification triggers are different fields, so the matrix does not treat an account-opening requirement as a complete description of every later identity check.

The signup field reports only the identifiers, requiredness, collecting actor, and scope established by the current cell. The later-verification field separately reports a trigger, requested identifier, requesting actor, and scope when the captured document establishes them. A statement in one column does not supply a missing value in the other.

That distinction preserves time and actor boundaries. Initial use, a paid-plan change, account recovery, a risk review, support contact, and another later event are not merged merely because each may involve an identifier. The row stays tied to the product, plan, region, and platform recorded by its source. When a document does not settle one of those qualifiers, the matrix preserves the field-level evidence state instead of inferring it from the rest of the row.

These columns describe documentation, not a completed signup or verification exercise. No account was created and no later event was triggered for this comparison. A requirement stated in a captured document remains scoped to that document and observation. It is not generalized into a claim about every account, plan, platform, region, or future version.

Source: 4 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Where data is operated, retained, and deleted

Operating entity, documented data region, retention, and deletion are separate fields, and an account-deletion mechanism does not establish complete erasure across every record or actor.

The operating-entity column identifies the legal name and jurisdictional details supported by the exact current cell. The data-region column separately reports a documented storage or processing location and whether the captured source describes a user choice. Legal domicile, governing law, customer location, storage location, processing location, and selectable region are not treated as synonyms.

Retention stays at the grain the cell provides: a data category, controller, trigger, duration, and any stated exception. A period attached to one category is not generalized to every record connected with a vault. A relative or non-numeric period remains in the source's terms rather than being converted into an estimated calendar date. If the source does not establish a duration, the matrix does not substitute the deletion flow or a general policy statement.

Deletion reports the documented initiation path, controller, completion statement, timeframe, exceptions, and scope. A way to close an account is not presented as proof that every backup, billing record, support record, legal record, shared item, local file, or separately controlled artifact is erased. The table keeps the actor and stated scope visible so a narrow deletion claim cannot expand into a service-wide promise.

A local-file product and a hosted service are not generalized beyond their own cells. Where the captured evidence leaves a field unsettled, the result remains a typed unknown for that field. Unknown is not rewritten as no collection, no retention, immediate deletion, or proof that a record does not exist.

Source: 4 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Exports and emergency access create different recovery paths

An encrypted export or database path concerns portable vault material, while emergency access concerns a documented person- or organization-mediated path into selected account data.

The encrypted-export column records the artifact, format, protection, creation path, restore path, plan, platform, scope, and limitations stated by the current cell. It does not treat every export as equivalent. An encrypted database, an encrypted archive, an export whose protection depends on a selected option, and a general portability statement remain distinct when the source distinguishes them.

The emergency-access column asks a different set of questions: who can be designated, what event starts access, whether a waiting period or approval step is documented, what data or account scope becomes available, and how access can be revoked. Those details describe a delegated process. They do not establish that an export exists, that recovery covers every item, or that the process fits every household or organization.

The two columns should therefore be read side by side without collapsing them into a resilience score. Portability does not automatically create delegated recovery. Delegated access does not automatically produce a portable protected copy. A restore path does not establish emergency access, and a named emergency feature does not establish the format or protection of exported material.

Each value stays product- and plan-scoped. If a format, protection method, restore step, waiting period, approval condition, scope, or revocation path is absent from the exact cell, the matrix leaves that element in its recorded evidence state. It does not fill the gap from another plan, platform, vendor row, or general expectation about password managers.

Source: 4 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Passkeys and TOTP depend on where the second factor lives

Passkey support and TOTP placement are separate documented paths, and the matrix reports whether a factor lives inside the vault, in a separate app, or in a named companion context without prescribing one arrangement.

The passkey column records the documented role, storage or synchronization statement, supported platform, plan, scope, and limitations established by the cell. Creating, storing, synchronizing, using, importing, or exporting a passkey are not assumed to be the same capability. A statement about one role does not fill another, and a platform statement does not automatically extend to every client or account type.

The separate-app TOTP column reports the documented placement and relationship of the authenticator path. It keeps an integrated vault feature, a separate application, and a companion product in their stated scopes. The four compared rows do not expand merely because a cell names another app as context. A companion reference helps explain placement; it does not create an extra vendor row or transfer the companion's attributes into the password-manager row.

Location is not a universal verdict. Keeping a password and a time-based one-time password in one product, separating them into different applications, or using another authentication path changes custody and recovery relationships, but the current evidence does not authorize a single arrangement for every threat model. The matrix reports the documented architecture and qualifiers rather than declaring one factor pattern safer.

Plan and platform limits remain load-bearing. When a source describes one device family, subscription, client, or companion path, the table does not broaden it to every platform. When a role or scope is not established, the value remains bounded by the cell rather than being completed from another product's documentation.

Source: 4 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Zero-knowledge, audits, and source availability are different evidence types

A zero-knowledge statement, an assessment record, a public source artifact, and a client-versus-server source statement answer different questions and do not combine into a product-wide assurance.

The zero-knowledge column records the architecture claim, named data or key material, stated limitation, audit relationship, scope, and source type supported by its cell. The matrix preserves the claim as published. It does not independently prove implementation, extend the statement to material the source excludes, or treat the phrase as a universal description of every client, server, recovery process, support workflow, or release.

The assessment column reports the assessor, scope, standard, period or date, report locator, publication status, and stated limitations. An assessment of a bounded component or period remains bounded. Its presence is not a trust badge for every product function, and its absence from the declared source set is not proof that no assessment exists. The claim type printed with the cell controls how the record is read.

Source availability and open-source client or server scope remain separate columns because a repository can establish less than a product-wide source claim. The table records the named component, artifact or repository locator, version or release locator, license, client scope, server scope, and limitations only where the exact cells establish them. A public component does not make an undocumented hosted service, synchronization path, policy layer, or release open source by association.

These four evidence types can inform different questions, but none substitutes for the others. Architecture language is not an assessment. An assessment is not a complete source inventory. A public repository is not an independent test of a hosted deployment. A client-source statement does not settle server scope. Unsupported links between them remain unresolved rather than becoming an overall security conclusion.

Source: 4 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Request reporting and the limits of this comparison

Each request-reporting cell records only the published period, jurisdiction, unit, scope, and counts its source supplies; the page does not independently test, score, or rank the four products.

Request reports require their units to remain visible. Requests, orders, accounts, identifiers, disclosures, and challenged matters are not interchangeable counts. A process statement is not a count, and a count does not fully describe a process. When the captured evidence does not disclose a field under the declared method, the comparison preserves that evidence state instead of printing zero.

Read every value as a dated, scoped record. The capture date says when the source was collected; it does not promise that a policy, interface, repository, plan, platform, or product remains unchanged. Inclusion and alphabetical row order do not express an endorsement. The page has no score, rank, highlight, affiliate parameter, best label, or preferred-product conclusion.

The matrix also makes no independent performance claim. Vendor-stated architecture, zero-knowledge, encryption, recovery, and deletion language describes the captured documents. A source artifact applies to the component and version it names. An assessment record applies to its stated scope and period. Separate-app TOTP placement describes documented custody, not the correct design for every threat model.

A typed unknown is field-specific. It does not inherit an answer from another column or vendor, and it does not mean the underlying feature, record, process, or capability cannot exist. The frozen roster is limited to the four compared rows. Context named inside a cell does not create another row or import that context's attributes.

The privacy-tool comparison methodology and corrections hub explains that a capture date records when a source was read, not that the source has stayed the same since; it also provides the correction path. This page remains bounded to the four-row, sixty-cell evidence set it transcludes.

Source: 4 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Frequently asked questions

Related research

• Private Phone Number App ComparisonAn adjacent comparison that separates identity, recovery, and provider-custody fields
• Email Alias Service ComparisonAn adjacent account-identity layer governed by the same neutral matrix method