Security

Your vault lives on your phone. It's encrypted there with a key derived from your master password, and that password never leaves the device. We don't run a server that stores vault data, so there's no account to break into and no database of ours to leak. If we disappeared tomorrow, your vault and your backup file would still work.

That design has a cost, and we'd rather say it plainly: if you forget your master password and have no backup, we can't recover your vault. Nobody can. That's the same property that keeps everyone else out.

The keys

When you create a vault, SecureKeep generates a random data encryption key and uses it to encrypt everything you store. That key is itself encrypted ("wrapped") with a second key derived from your master password using PBKDF2-SHA256 at 600,000 iterations over a random per-vault salt.

Your master password isn't stored anywhere, in any form. Unlocking works by deriving the key again from what you type and seeing whether it successfully unwraps. The unwrapped key is held in memory only while the vault is unlocked, and it's wiped when the vault locks.

The data

Passwords, notes, documents, video and audio messages, and emergency cards are all encrypted with AES-256-GCM before anything is written to disk. Files like documents and recordings are encrypted as files in the app's private storage, not just referenced from an encrypted database row.

GCM is an authenticated mode, which means tampering with stored data causes decryption to fail rather than silently returning altered content.

Biometric unlock

If you turn on Face ID, Touch ID, or fingerprint unlock, the vault key is placed in your device's own secure hardware — the iOS Keychain or Android Keystore — and marked so the operating system requires authentication before releasing it. We never see or handle your biometric data; your OS does that entirely. Your master password keeps working as the fallback.

Vault contents never do. The only things that ever reach us are ones you deliberately send:

• A feedback or contact message, if you write one. If you attach a screenshot, you're choosing to send that image.
• Standard website analytics on securekeep.app, which is separate from the app. The site also keeps a small count of its own — whether the download prompt was shown or tapped, whether a video was played — with no cookie, no identifier and no IP address stored, and nothing at all if your browser sends Do Not Track.

There's no analytics SDK inside the vault app, no crash reporter, and no telemetry. The app doesn't phone home on launch. This is also why we can't tell you how many people use a given feature — we genuinely don't collect it.

Full detail is in the privacy policy.

A vault backup is a single encrypted file you control. We're documenting its shape here on purpose: if SecureKeep ever stops existing, a competent engineer should be able to recover your data without us and without the app.

• It's a plain-text JSON file. The top-level object has four fields: magic (always SKVT), version (currently 1), salt and payload, the last two base64-encoded.
• A 32-byte key is derived from the backup passphrase and that salt using PBKDF2-SHA256 at 600,000 iterations.
• The payload is a 12-byte initialization vector, then AES-256-GCM ciphertext, then a 16-byte authentication tag. Decrypting it yields a JSON manifest.
• That manifest still holds the vault's own encrypted rows, protected by a second key. It's stored in the manifest wrapped with a key derived the same way from your master password and the vault's own salt. Unwrap it, and each row decrypts with it.

So there are two layers and two secrets. The backup passphrase opens the file; the master password opens what's inside. Neither is stored anywhere in it, and without both, nothing in it is recoverable, by us or anyone else.

What these are, and what they aren't

SecureKeep has not had a paid external security audit by an independent firm. We'd rather tell you that than let a word like "audited" imply something it doesn't.

What we have done is run structured internal reviews, AI-assisted, deliberately carried out by a reviewer that didn't write the code being reviewed. They're real work with real findings, and they're not a substitute for a third-party audit. If that changes, this page changes with it.

What they found

Across seven review phases in April 2026 covering code quality, security, accessibility, product behaviour, testing, and architecture, 110 code issues and 12 testing gaps were identified. Nearly all were fixed. Two were accepted as limitations we can't engineer away and documented as such, and a small number were deferred deliberately.

A further security-focused review in July 2026 worked through the OWASP categories across the app, the website, the serverless API, dependencies, and the git history. Its conclusion was that the vault core was in good shape, with no critical or high findings against the app's encryption, key handling, or data storage, and that the real risk sat on the website side: the admin authentication model, missing rate limiting on public endpoints, and vulnerable dependencies. Those website issues have since been fixed and deployed. That review also confirmed no live secret has been committed to the repository or its history.

Limitations we've accepted

• The lock screen's attempt limit is enforced by the app, so on a rooted or jailbroken device it can be bypassed. The real protection is the key derivation itself, which stays expensive regardless.
• JavaScript can't reliably zero a string in memory, so while we wipe key material as thoroughly as the runtime allows, we can't promise every trace is gone the instant a vault locks.
• Android blocks screenshots inside the app. iOS doesn't allow apps to do that, so on iPhone we cover the app in the task switcher but can't stop a screenshot you take yourself.

If you've found something, email support@securekeep.app with enough detail to reproduce it. It reaches a person, and you'll get a reply.

We don't run a bug bounty and don't offer payment. We'd still rather hear from you, and we'll credit you here if you'd like and if the finding is real.

KCH Labs is one person. I'm Heston Dsouza — I build SecureKeep, and when you write to support@securekeep.app, I'm the one who reads it and writes back.

SecureKeep started with a thought I couldn't put down. If I were gone tomorrow, how would my spouse find the bank accounts and the passwords, or know where the investments actually are? How would I leave a message for my child, or for my parents? I wanted all of it in one place, and I wanted that place to be safe enough that putting it there wasn't a new risk of its own. So I built it.

That's also why this page goes further than most. Every claim on it is one you can check for yourself: the key derivation, the cipher, and the backup format written out in enough detail to recover your data without me and without the app. SecureKeep gets structured security reviews, deliberately carried out by a reviewer that didn't write the code, and what they turn up gets published above — limitations included, not only the findings that flatter the product. Where things stand on an external audit is set out there too.

KCH Labs · Heston Dsouza on LinkedIn