What actually happens to a password you save in Trezio
A plain walk through the encryption: what leaves your device, what we could hand over if compelled, and why most of your library is deliberately not encrypted the same way.
Most apps that say "encrypted" mean the disk it sits on is encrypted, which protects you from someone stealing the hardware and almost nothing else. This is what Trezio actually does with a saved login, described precisely enough that you can decide whether you believe it.
The path a credential takes
When you attach a username and password to a saved item, the encryption happens on your device, before anything is sent. The key is derived from your master password using PBKDF2 at 600,000 iterations against a random 128-bit salt. That iteration count is deliberately slow — it is what makes guessing the password expensive rather than trivial.
The credential itself is then encrypted with AES-256-GCM using a fresh random initialisation vector. That per-credential randomness matters more than it sounds: it means saving the same password twice produces two completely different ciphertexts, so nobody can tell from the stored data that you reused a password.
What reaches the server is the ciphertext, the IV and the salt. Your master password is not among them. It is never transmitted and never stored — not in plain text, not hashed, not in any form that could be reversed.
How unlocking works without a stored password
If the password is never stored, there is nothing to compare your input against. So Trezio does not compare. At setup it encrypts a known piece of verification data with your master password and keeps only that. When you later enter a password, it tries to decrypt that data. Success means the password was right. Failure means it was not.
This is the whole mechanism, and it has a consequence worth stating before you rely on it.
There is no reset. No support ticket recovers a lost master password, because there is nothing on our side to reset it from. If you lose it, the credentials encrypted with it are permanently unreadable.
Everything else in your library survives that loss untouched — bookmarks, notes, screenshots, folders, charms. Only the saved credentials become unreadable, because only they were encrypted this way.
Why the rest of your library is not encrypted like this
This is the part a security page would usually leave vague, so here it is directly: your bookmarks, notes and folder names are not protected by zero-knowledge encryption. They are protected by account-level access control, which is a real protection but a different guarantee.
That is a design decision rather than an oversight. Search has to read your text to find it. Thumbnails have to be fetched. AI summaries have to see the content to summarise it. Encrypt all of that so the server cannot read it and you lose every one of those features. Credentials are the one category where none of that applies — nothing needs to search inside a stored password — so it is the one category where the strongest possible protection costs you nothing.
We would rather tell you exactly which guarantee applies to which data than let "end-to-end encrypted" sit on a marketing page and mean whatever you hope it means.
Two locks that are easy to confuse
Trezio has a second, unrelated lock, and mixing the two up is the most common misunderstanding — we have made this mistake in our own documentation and had to correct it.
| Encrypted credentials | Folder vaults | |
|---|---|---|
| What it protects | Usernames and passwords attached to items | Access to a whole folder |
| How | AES-256-GCM, key from your master password | A separate folder password, hashed with bcrypt |
| Can we read it? | No | The folder contents, yes |
| Auto-lock | Fixed at 30 minutes, not configurable | Configurable in Settings: 1–60 min, or Never |
| Recoverable? | No | Yes — you can change a folder password |
The auto-lock control you will find in Settings governs folder vaults. The 30-minute credential timeout is separate, fixed in code, and exposed by no setting — after half an hour of genuine inactivity your master password is cleared from memory and you enter it again.
One practical limitation
Setting up a master password and encrypting a new credential currently happen in the mobile app or the browser extension. The web app can unlock and edit credentials you already have, but it has no path to create the first one. That is a real gap rather than a deliberate design, and worth knowing before you plan around it.
What a breach would actually expose
The honest summary, since that is the only version worth publishing: someone with complete access to our database would get your ciphertext, your IVs and your salts. To turn that into a password they would have to brute-force PBKDF2 at 600,000 iterations per guess against a password only you know. They would also get your bookmarks and notes, because those are not encrypted that way — which is exactly why we would rather you knew now than found out then.