TeamPassword

What the vendor can prove about its security design: end-to-end encryption with named algorithms and key derivation, which fields are encrypted on the device and which are not, independent audits and penetration tests with published results, a bug bounty, and incident history disclosed.

0 — Vault contents are readable by the vendor by its own description: server-side encryption with keys the vendor holds, or no encryption of stored credentials.

3 — Client-side or end-to-end encryption described with the algorithms named; key derivation, audits and the scope of what is encrypted are basic or not described.

5 — A published security whitepaper or security page naming algorithms, key derivation and the client-side encryption model, and an independent audit, penetration test or certification (ISO 27001, SOC 2) named.

8 — A stated list of which fields are and are not encrypted (including URLs and metadata), recurring independent penetration tests or code audits with dates and reports or summaries published, a public bug bounty or vulnerability disclosure policy, past security incidents documented with their impact, and open-source clients or cryptography that can be reviewed.

10 — The design is verifiable end to end: full source or cryptographic design public, every field encrypted client-side including metadata, audits by named firms repeated yearly with full reports, a threat model that states what a compromise of the vendor's servers would expose, and incident post-mortems published.

How credentials are shared and governed across a company: shared vaults or collections, role-based permissions, view-only and time-limited access, admin account recovery, emergency access, and what happens to shared items when an employee leaves.

0 — A personal password manager by the vendor's own description: no sharing between users is offered.

3 — Shared folders or vaults between users of one account; permission levels, admin recovery and offboarding are basic or not described.

5 — Shared vaults or collections with permission levels (for example read, edit, manage), groups and admin roles, and an admin account recovery or offboarding that keeps a leaver's shared items with the company.

8 — Recovery and offboarding documented with their key model, granular permissions down to hiding the password while allowing autofill, time-limited and one-time sharing with external parties, emergency access with a waiting period, delegated administration per team or location, and approval workflows for sensitive items.

10 — Access is governed and provable: least-privilege defaults, recovery and emergency access designed so the vendor never holds a key and stated so, periodic access reviews supported in the product, and every grant, change and revocation attributable to a person.

How the vault fits into the company's identity stack: SSO with Entra ID, Okta or Google, and the key model behind an SSO unlock; SCIM or directory sync for joiners and leavers; MFA options including hardware keys; and passkey support for users and the vault itself.

0 — A consumer product by the vendor's own description, with no business administration, SSO or directory connection offered.

3 — Users invited by email or CSV with two-factor authentication; SSO, directory sync and hardware keys are basic or not described.

5 — SSO with named identity providers (Entra ID, Okta, Google), SCIM or directory sync for provisioning and deprovisioning, and MFA including FIDO2 or hardware keys.

8 — The SSO unlock documented with how the vault key is derived or released and designed so the vendor cannot derive it, group sync driving vault permissions, automated suspension on deprovisioning, conditional access or device policies, and passkeys stored and used across platforms.

10 — Identity is integrated without trust shortcuts: the SSO key model published and independently reviewed, deprovisioning that revokes vault access and shared items immediately with a log entry, passwordless vault unlock with passkeys, and support for the customer's own key-management or trusted-device approval.

What an administrator and an auditor can see and enforce: event logs of access and changes, password health and breach reports, enforceable policies (master password, MFA, sharing, export), SIEM integration, and reports an ISO 27001 or NIS2 audit can use.

0 — No administration by the vendor's own description: a personal tool with no admin console, logs or policies.

3 — An admin console with an activity list and a password health or strength report; exportable logs and enforceable policies are basic or not described.

5 — Event logs covering logins, item access, sharing and admin changes, enforceable policies for master password and MFA, and password health and breach-monitoring reports.

8 — Logs exportable or available through an API with native SIEM integration to named targets (Splunk, Microsoft Sentinel, Elastic or syslog), policies for sharing, export and browser-extension behaviour, log retention stated, and compliance reports aligned to ISO 27001, NIS2 or BSI IT-Grundschutz.

10 — Auditability is complete: every view, copy, autofill and permission change logged with user and device, logs tamper-evident and retained for a configurable period, alerting on anomalous access, and an auditor role that can read logs without access to secrets.

Where and how the vault runs and how the data leaves it: cloud region choice, a self-hosted or on-premises option, offline access during a vendor outage, client coverage across operating systems and browsers, and a complete, documented export and import path.

0 — Vault data cannot leave the product: the vendor states that no export is offered.

3 — Apps for common platforms and browsers and an export of vault items (for example CSV); hosting region, offline access and export completeness are basic or not described.

5 — Clients for Windows, macOS, iOS, Android and the major browsers, offline access to the vault, an EU region or self-hosted option, and export and import of vault data including from named competitors.

8 — Both EU cloud and self-hosted or on-premises deployment documented, Linux clients, a status page with incident history, an encrypted full-fidelity export covering all item types including attachments, and vault access continuing during an outage of the vendor's service.

10 — The customer can run and leave the vault on their own terms: self-hosting with documented high availability and backup, an open or documented export format that preserves structure, permissions and history, and a stated procedure for continued access if the vendor ends the service.

Who the contracting entity and the parent company are, where vault data and metadata are hosted, and who the subprocessors are. Independently sourced by the sovereignty pipeline; end-to-end encryption narrows what a foreign authority could compel, but metadata, logs and the update channel for the client software remain in the vendor's hands, so the chain still counts.

0 — Proven non-EU on every dimension the evidence covers: non-EU vendor and contracting entity and non-EU hosting, with no EU or self-hosted option stated.

3 — One European element proven: an EU data region, an EU contracting entity or EU representative, a self-hosted option, or a published DPA, with the rest of the chain unstated.

5 — EU hosting as standard or selectable, or a self-hosted option, and an EU contracting entity or EU representative, with a DPA offered; the parent company or parts of the chain (support, analytics, email, client distribution) are unstated or non-EU.

8 — EU hosting on named infrastructure, EU contracting entity, subprocessor list published with locations, a DPA covering vault metadata and logs, and a self-hosted option that removes the vendor from the data path.

10 — Sovereign end to end and evidenced: European ownership, entity, hosting and every subprocessor, certifications published (ISO 27001, BSI C5 or equivalent), and source code or builds verifiable so the client update channel is not a blind trust in the vendor.

Whether a buyer can compute the real annual cost from public pages alone: price per user and tier, which features (SSO, SCIM, SIEM, self-hosting) sit in which tier, minimum seats, add-ons, and the minimum term.

0 — No public prices at all; every tier is a sales conversation.

3 — A public "from" price or one priced tier, per user or flat.

5 — Per-user prices public for the business tiers with the billing period stated and the main features per tier listed.

8 — Every tier priced publicly with its feature set and seat minimum, add-on prices listed, self-hosted licensing stated, minimum term and VAT treatment given.

10 — Complete price computability: annual invoice derivable for a given number of users, with every add-on, self-hosting licence, support level and renewal condition published.