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 — Security described in adjectives ("bank-grade", "military encryption") with no architecture, no audit and no statement of what the vendor can read.
3 — Encryption algorithms named and "zero knowledge" claimed, but no whitepaper, no statement of which fields stay unencrypted, and audits mentioned without dates, auditors or results.
5 — A published security whitepaper naming algorithms, key derivation and the client-side encryption model, a stated list of what is and is not encrypted (including URLs and metadata), and a named independent audit or certification (ISO 27001, SOC 2) with its date.
8 — Recurring independent penetration tests or code audits with 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 SME Owner
The whitepaper and architecture pages name the algorithms — XSalsa20 plus Poly1305 and Curve25519 — state that the cloud stores data only and cannot decrypt vaults, and the privacy policy lists usernames, passwords and website URLs as end-to-end encrypted. That is a real design, but we found no public information on an independent audit, certification, penetration test or bug bounty, and no statement of which fields stay unencrypted. 3 5 6