Security
How we protect what you leave behind
You are being asked to put passwords, wallet locations, document copies and letters to your children into a service you have just met. That deserves a precise answer, not reassurance. This page describes what we actually do — and, just as importantly, what we deliberately do not do.
The problem with « zero-knowledge »
Several vault products advertise zero-knowledge architecture: the provider cannot read your data because only you hold the key. For a password manager, that is the correct design and we would recommend it.
For an inheritance vault, it collapses at the one moment it needs to work. If you are the only person who can ever decrypt the vault, then the day your family needs it is precisely the day nobody can open it. A strictly zero-knowledge inheritance vault is a sealed box buried with its owner.
So we will state it plainly: Sucesio is not zero-knowledge. The engineering question is not how to make decryption impossible, but how to make it impossible except under conditions you defined while alive. That is what the rest of this page describes.
Encryption at rest
- AES-256-GCMfor every sensitive field, with a 96-bit initialisation vector and a 128-bit authentication tag — the parameters recommended by NIST SP 800-38D. GCM authenticates as well as encrypts, so tampered ciphertext fails to decrypt rather than returning corrupted data.
- A distinct key per user, derived with HKDF-SHA256 from a master key held in the server environment and a per-user salt. No two accounts share an encryption key, so compromising one account's key does not expose another.
- Decryption server-side only. Plaintext is never assembled in the browser and never written back to the database. Encrypted values are stored as initialisation vector, authentication tag and ciphertext together.
The transmission key is split in three
Each account has a Master Encryption Key of 32 random bytes. That key is never stored anywhere in the clear. It is split using Shamir's Secret Sharing into three shares, of which two are required to reconstruct it:
- Share A — sealed with your own transmission key pair (X25519).
- Share B — sealed separately, and released only after a compliance officer has manually verified a death certificate.
- Share C — held server-side, used to countersign that verification.
The consequence is the property that matters: a transmission cannot be triggered by a single party acting alone, an automated process cannot release your vault by mistake, and the reconstructed key exists only in memory for the duration of the operation. It is never written to disk.
This is our current architecture, not a finished one. The next iteration moves the server-held share into a dedicated hardware security module in the EU and signs every reconstruction event in an append-only audit log.
Getting into your account
- No password to steal. Sign-in is passwordless — there is no password database to breach, and no password of yours to reuse elsewhere.
- Two-factor authentication (TOTP)using standard authenticator apps. We strongly recommend enabling it: it is the single largest improvement you can make to your own account's security.
- Row-level isolation in the database. Every query is scoped to the authenticated account, in addition to the authorisation checks in the application layer.
Where your data lives
European infrastructure end to end, because a product built around EU succession law should not store EU families' data outside the EU.
- Application and database — PostgreSQL 16 on Hetzner servers in the European Union.
- Backups — a daily database dump, encrypted before it leaves the server, stored with Scaleway Object Storage in Paris. The decryption key is held offline. We hold documented restore procedures, not just backup procedures — an untested backup is not a backup.
- Monitoring— application error tracking, plus a dead-man's switch that alerts us when a scheduled job stops reporting. Silence is treated as failure.
What we do not do
A security page that only lists strengths is marketing. These are real limits, and some of them are deliberate.
- We do not store complete crypto seed phrases. Sucesio holds the map, not the keys: which wallets exist, where the hardware device is, which exchange holds what, and the instructions your heirs will need. The cryptographic secret stays yours. See our guide to hardware wallet inheritance for how to handle that layer safely.
- We are not zero-knowledge, for the reason set out at the top of this page.
- We hold no security certification yet.No ISO 27001, no SOC 2, no completed third-party penetration test. Claiming otherwise would be trivial and dishonest. These are on the roadmap; they are not behind us.
- We do not replace your will. Sucesio is the operational layer beside notarial succession, never a substitute for it. Your notario or solicitor remains the legal foundation.
Your data, your control
- Export— you can download everything you have stored, at any time, in a portable format (GDPR Article 20).
- Deletion— you can close your account and have your data erased (GDPR Article 17). Reversibility is a feature, not a concession.
- Audit trail — sensitive operations on your vault are logged, so an access can be reconstructed after the fact.
Our full privacy policy sets out the legal detail of what we process and why.
Found a vulnerability?
Report it to hello@sucesio.io. We will keep you informed while we work, and credit you publicly if you want us to. We will not pursue researchers who act in good faith, stay within their own test account, and give us reasonable time before disclosing.
If any claim on this page turns out to be inaccurate, we want to know — write to us and we will correct it here.
See what Sucesio costs →Last reviewed: 7 September 2026. This page describes the architecture in production at that date and is updated when the architecture changes.