Security overview
This is the security summary for evaluators. It states what SafeHanded commits to and how each commitment is enforced. For the everyday explanation, see How SafeHanded protects secrets.
Commitments
Section titled “Commitments”- Zero knowledge by design. No plaintext credential, and no key capable of decrypting one, ever reaches the service, database, backups, logs or operators — including share links SafeHanded emails or texts, which carry no key. Enforced by browser-side encryption (HPKE), and verified by an automated test that walks every response and rejects any secret material.
- Keys are checked before anything is sealed. Every recipient key carries a statement signed by its owner’s signing key, which only their vault can open. Browsers verify it and remember each person’s signing key; the server verifies it for requests it creates; key rows carry an app-keyed integrity code, designed so that a key inserted directly into the database is refused. See How keys are checked.
- Single-use, short-lived links. Links are single-use, expire by default in 60 minutes, and use 256-bit tokens stored only as hashes. An optional challenge code makes a link insufficient on its own.
- Phishing-resistant reveals. Every reveal requires a passkey step-up and is logged.
- Tamper-evident audit. Audit events are hash-chained, individually signed, exportable and streamable; retention is configurable from 30 days up to your plan’s maximum.
- Transparent recovery. Recovery is opt-in, recipients are visible on every request, and break-glass use of the org recovery key alerts every Owner and Admin.
- Data residency. Hosted in the European Union (Germany and Finland). See Data residency.
- Minimal subject data. A subject’s data is limited to what the handover needs: name, email/UPN (and a phone number only where SMS is used) and the encrypted payload. The payload is deleted on purge; the request record follows your audit retention period.
How to verify the zero-knowledge claim
Section titled “How to verify the zero-knowledge claim”- The reveal path is browser-only — decryption happens client-side, after a passkey step-up.
- There is no server API that returns a decrypted secret.
- A static test enforces the rule that no envelope inner field, link token, challenge code or recovery code is ever logged, stored in the clear, or sent to an error tracker.
The code that does the encryption
Section titled “The code that does the encryption”The encryption runs in your browser, using code SafeHanded delivers. That is how every web-based end-to-end encrypted service works, and it means you rely on us to deliver that code unaltered. We protect it with a strict content security policy, integrity hashes on every script, and no third-party scripts on any page that holds a secret (the anti-bot check runs in a separate, isolated frame).
Security questions and questionnaires: email security@safehanded.com.