The design in four numbers
Three of these make the vault expensive to attack. The fourth is what they cost you.
Who can see what
The interesting rows are the ones where the answer is “never” — and the ones where it is not.
| Data | Your device | Our servers |
|---|---|---|
| Your passwords | Decrypted only while you are looking at them | Never — encrypted entries are not uploaded |
| Your passcode | Held only long enough to derive a key | Never — it is not transmitted |
| Key shard 1 | Created inside StrongBox/TEE, non-exportable | Never — this is what makes the rest hold |
| Key shard 2 | Stored encrypted | Handled briefly during key derivation, and stored encrypted. Useless without shard 1 |
| Key shard 3 — the “pepper” | Never — it never reaches your phone | Sealed in a hardware security module. It can be used, but not read out — by anyone, us included |
| ShardVault | Arrives for one unlock, then it is gone | Computed for you at each unlock, from shard 2 and the pepper |
| Email, device model, security events | — | Yes — to run your account and refuse abuse |
We list those rows rather than rounding them away. Our servers hold shard 2 as ciphertext and compute ShardVault on request — two of the three pieces your key is built from. They still cannot open your vault, because the third one, shard 1, has never existed anywhere but your phone.
Hardware key storage and ShardVault are Gold and above. Silver keeps its shard in encrypted app storage instead, and derives its key on the phone alone.
What happens when you unlock
The key that decrypts your vault is not stored anywhere. It is rebuilt from separate shards each time, and destroyed immediately after.
One secret, and the only one you ever type. It never leaves the phone and is never sent to a server.
Never transmitted128 MiB of memory and 10 passes turn the passcode into a vault secret. That cost is paid on every guess an attacker makes too.
128 MiB · 10 passesShard 2 is stored encrypted on the device, with a ciphertext copy synced for durability. On its own it opens nothing.
Generated inside StrongBox or the TEE and non-exportable by hardware design. This is the share that makes the rest hold.
Cannot leave the phoneAn HMAC taken inside a Cloud KMS hardware module, keyed by a pepper that never leaves it — and bound to your account, so it cannot be requested for someone else.
The key exists only in native memory, only on your phone, and only for as long as the operation you asked for.
The key is zeroed straight after use and rebuilt from scratch next time. It is never written to disk, never logged, never cached.
Rebuilt every timeMiss any one of the three and there is no key. We hold two of them and still cannot open your vault, because Shard 1 has never existed anywhere but your phone.
What are you actually afraid of?
Encryption is the easy part — every password manager has it. What separates them is everything layered around the moment you type your passcode. Here is each worry, and the specific thing that answers it.
Someone has your phone
“They will just keep guessing my passcode.”
Every single guess costs them 128 MiB of memory and real time, because that is what it costs you when you unlock. Guessing stops being something you do millions of times an hour.
“They will root the phone and dig the key out of storage.”
One piece of the key was created inside a separate security chip, and that chip has no operation that hands it back — to anyone. Root gets them the phone. It does not get them that piece.
The danger is us
“You get breached and my passwords end up in the dump.”
Your saved passwords are never uploaded to us at all. Our database holds your account details and one encrypted piece of the key. Someone who takes the entire database takes nothing that opens a vault.
“Someone inside your company looks — or a court makes you hand it over.”
There is no internal tool, no support override, no admin mode. Not as a policy we could change under pressure — the piece that completes your key has never existed on our side of the wire.
Something on your phone is watching
“A fake screen appears over the app and I type my passcode into it.”
The app watches for anything drawn on top of the passcode pad and refuses to go on. An invisible layer harvesting your taps is stopped the same way. Both attacks skip the encryption entirely by getting to the secret as you type it — so they get blocked before you finish typing.
“Some app I installed can read my screen.”
Android’s accessibility permission lets an app read every field on screen, password fields included. Plenty of ordinary apps ask for it. While one is active, key operations stop.
“Something is recording my screen while I unlock.”
Screenshots are refused outright, and a recording of the app comes out black — the app and the keyboard over it, nothing to read. The gap is the autofill dialog, which sits over a different app that is being recorded normally, so on Android 15 the app detects the recording and refuses to let you type at all. Below that it cannot detect one, and we would rather say so than let you assume otherwise.
“My keyboard is logging everything I type.”
This one we cannot fix, and pretending otherwise would be the dishonest part. Any keyboard sees the keys you give it, in every app on your phone. What we do is tell you when the keyboard in use did not ship with the phone — a warning, never a block, because locking you out over a keyboard preference helps nobody.
Is this even the real app?
“I install a tampered copy of the app without noticing.”
Before key operations, our server asks Google whether this is the genuine app on a genuine, uncompromised device. The check happens on the server, not on the phone — so a modified app cannot simply patch out its own verdict.
“Something is hooked into the app, reading it from the inside.”
Root, repackaging, an attached debugger and the common hooking toolkits are all detected, and key operations refuse to run. The encryption is only worth anything while the app around it is intact — so the app checks that instead of assuming it.
“Someone on this Wi-Fi — or my employer — intercepts the connection.”
The call that returns part of your key accepts only a fixed set of Google’s own root certificates. A certificate your phone has been made to trust — a work profile, an installed root — is refused anyway.
“Bots hammering away at my account.”
Sign-in attempts are scored for automated abuse in the background — you see nothing unless something looks wrong — and are rate-limited on top of that.
It is your data, including the leaving part
“Someone gets my backup file out of my Drive.”
Backups go to your Drive rather than ours, and they only open on the phone that wrote them — on every tier. A stolen backup file is a brick. The same property is why you cannot move a vault to a new phone, and we would rather you knew that now.
“I want to leave. Will you actually delete it?”
Settings → Reset Account, and it is done. No queue, no thirty-day retention window, no support ticket, no exit survey.
🎁 One of these defences is useful even if you never store a password with us: the app can tell you whether a second-hand phone has been rooted or tampered with, before you pay for it. how to check a used phone
Filling a password, step by step
Autofill needs Android 8.0 or newer. Some apps opt out of it entirely — that is their choice, not a fault in PasswordEpic.
In any app or website that uses a normal password field.
Through the system autofill framework — the app is never watching your screen to find the field itself.
A fingerprint or the passcode, every single time. There is no window during which fills happen unattended.
Every timeOnly the entry being filled, and only for that fill. The rest of the vault stays encrypted.
The decrypted password and the key are released as soon as the field is filled.
Four tiers, each the one below it plus a delta
They are not four separate products. Gold, Platinum and Titanium all run the same native engine and differ only in what guards it or what unwraps the key.
The free tier, and the only one that runs without the Android native module.
- AES-256-CTR with a separate HMAC-SHA256, in JavaScript
- Key rebuilt from two shards, computed on the device
- Unlimited devices
- No hardware key storage
- No guarantee the key is wiped from memory
The real security baseline. All cryptography moves into native code.
- AES-256-GCM in native Kotlin
- Shard 1 held in StrongBox or the TEE, non-exportable
- A third shard computed inside Cloud KMS
- The key is zeroed straight after every operation
Cryptographically identical to Gold. What it adds is proof that the device deserves it.
- Everything in Gold, unchanged
- Play Integrity, verified on the server
- Certificate pinning on the key-derivation call
- Overlay, accessibility and tamper detection
Changes one thing about Gold’s engine — but the thing it changes is what touches your passcode.
- Everything in Platinum
- The passcode unwraps the vault through OPAQUE
- Nothing that unwraps the vault is ever stored unencrypted
- A Rust core that can wipe secrets from native memory
The proof is what we cannot do
A service able to restore your vault is a service able to read it. These limits are the same fact, stated from the other side.
Backups open only on the phone that made them
Every backup and export carries a layer of encryption tied to that device’s secure hardware. They protect you against losing data on the phone you still have — not against losing the phone.
There is no move-to-a-new-phone path
On any tier. Support can release an account so you can start fresh on a new device, but that does not carry the old vault across.
Your keyboard can read what you type
In any app, not just this one, and no amount of screen protection touches it — a keyboard is handed the keystrokes directly, before anything is drawn. PasswordEpic warns you when the active keyboard did not ship with your phone, which is a nudge rather than a verdict.
Detecting a screen recording needs Android 15
A recording of the app itself comes out black on every version. The gap is the autofill dialog, which sits over another app that is being recorded normally — Android 15 lets the app notice and refuse passcode entry there, and below that it cannot notice, and says so rather than implying otherwise.
The free tier is software-only
Silver encrypts in JavaScript with AES-256-CTR plus a separate authentication tag, without hardware key storage, and cannot reliably wipe the key from memory afterwards. Those are accepted trade-offs, not defects — but they are real.
Android only
Android 7.0 and above. There is no iOS version, and the hardware tiers have no iOS equivalent to be ported to.
Judge the claim, don't trust it
The documentation describes the key, the shards and the places each one lives — including the parts we handle. Read it before you decide whether to believe the front page.
