Encryption model & independent audits
How this is scored
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.
The Identity Engineer
SOC 2 certification is stated on the site and the passkey article documents a genuinely local key model: private keys AES-encrypted, wrapped with a personal public key, unwrapped only inside the extension, with the backend never seeing plaintext. For the vault itself, encryption is asserted without named algorithms or key derivation, and we found no public information on published audit reports, a bug bounty, or incident history. 1 6