Architecture crafted for
life's continuity.
A transparent account of the technology behind your digital life vault. We move past cold industrial jargon to provide a secure, human-centric bridge for your family.
System design
Where does my data actually live?
We use Amazon's data centres in Mumbai (ap-south-1). Our system is “serverless”: there are no Soult-managed servers to patch or log in to, and AWS secures the underlying machines. That reduces the attack surface but doesn't remove it — our APIs, sign-in and cloud configuration still need protecting.
Serverless compute on AWS Lambda, with DynamoDB, S3 and Cognito, in ap-south-1 (Mumbai). Data is stored across multiple Availability Zones. Cross-region disaster recovery is on our roadmap.
One region today, silos next
Where does each user's data go?
Today Soult runs as a single silo in AWS Mumbai, India, and every user's vault is stored there. We're preparing to launch in the UAE. Vaults for users there will be stored in AWS Mumbai (India), and we'll ask for their explicit consent to that at sign-up. Separate regional silos are on our roadmap.
Today: one silo, ap-south-1 (Mumbai), for every user; no country-based routing is live. Roadmap: home-region routing at sign-up, a US silo (us-east-1, us-west-2), a SEA silo (ap-southeast-1, ap-southeast-3) and a dedicated GCC silo.
Why AWS Mumbai?
Local compliance and security.
AWS Mumbai gives us a mature, independently audited data-centre footprint in India. Keeping your data on Indian soil means your legacy follows Indian law and stays within reach of your family without complications.
Single-region deployment in ap-south-1 across multiple Availability Zones; cross-region DR on our roadmap. Native Cognito localised phone support and FIPS 140-validated cryptographic modules in AWS KMS.
Authentication flow
Sign up and log in safely.
Registration: verified via Phone OTP and Email OTP. You set a security question and a 4-digit MPIN. Trusted use: daily access requires only your 4-digit MPIN. New device: triggers 2-factor security — phone OTP first, then your MPIN.
Multi-channel OTP verification. Security answers are stored as one-way hashes; the MPIN is verified and stored by AWS Cognito. Re-auth on a new device triggers OTP before MPIN.
MPIN on shared devices
Why can't my family open this?
In shared-phone homes, fingerprints allow anyone enrolled to enter. A private 4-digit PIN keeps your vault private while kids play games or your spouse uses the phone.
4-digit MPIN, verified and stored by AWS Cognito. 3 failed attempts lock sign-in for 24 hours, enforced server-side. Reinstall, device wipe, or device change does not reset the lockout.
Why a 4-digit PIN?
Is 4 digits really secure?
Yes — because the protection is the lockout, not the length. Three wrong tries and your vault locks for 24 hours. Even a thief with your phone gets only 3 guesses before the door slams shut. We chose 4 over 6 deliberately: longer PINs cause more forgotten codes, lockouts, and resets — and memory complexity is the real enemy of security in practice, not raw entropy.
4-digit search space: 10⁴ = 10,000. Brute-force mitigation: server-side counter, 3-strike lockout for 24 hours. Practical entropy with lockout exceeds raw entropy of unprotected 6-digit. Trade-off accepted: usability gain > marginal entropy gain.
Hard drive risk
What if someone steals a hard drive?
Data is AES-256 encrypted at rest. Stolen hardware contains only meaningless ciphertext. Encryption keys are managed by AWS, separately from the data — never on the same disk.
Files: S3 server-side encryption (SSE-S3, AES-256), applied automatically to every object. Tables: DynamoDB encryption at rest. High-sensitivity fields: additionally encrypted with AWS KMS before write.
Key management (KMS)
Who holds the keys?
AWS does. Our field-encryption key lives inside AWS KMS hardware security modules and never leaves them in readable form, so no one at Soult ever handles the raw key. Our application asks KMS to use it when you save or reveal a protected field, which is what makes a verified family handover possible. Keys for files and database tables are managed by AWS.
Sensitive fields: KMS Encrypt/Decrypt under a customer-managed key; key material never leaves KMS's FIPS 140-validated HSMs. Files: S3 server-side encryption (SSE-S3, AES-256). Tables: DynamoDB encryption at rest.
Field-level security
Double-lock security for your most sensitive fields.
For your most sensitive details — national ID, tax ID and passport numbers, card and account numbers, and Standard Password Keeper passwords — we add a second lock. Our servers encrypt each of those fields with an AWS KMS key before saving it, so in the database they are stored as ciphertext.
Server-side field-level encryption with a customer-managed AWS KMS key, applied by our backend before write, on: Aadhaar, PAN and passport numbers; primary credit and debit card numbers; loan, credit-card, fixed-deposit, government-savings and alternative-investment account numbers; investment transaction IDs; property document identifiers; and Standard Password Keeper passwords. A table read without KMS decrypt rights returns only ciphertext for those fields. Insurance policy numbers, bank passbook account numbers and Will details are protected by at-rest encryption only.
Client-side encryption
Which secrets can even Soult never read?
The Password Keeper has two levels. Everyday logins — Wi-Fi, streaming — unlock with your app MPIN, and we can help you recover them. For your most sensitive logins you turn on Advanced, which is locked end-to-end with a vault password that never leaves your phone. Adding an Advanced entry needs no password at all; only reading one does. We store the locked result and never hold the means to open it — so there is no Soult decrypt button, no staff override, and nothing meaningful to hand over under a legal order. You also get a 12-word recovery phrase, shown once, that we never receive. That is the honest trade-off: lose both the vault password and the phrase and those passwords are gone permanently, because the alternative would mean us holding a key. Only the password itself is sealed; the entry's title, username, website, notes and security question and answer use Standard protection.
Per-user X25519 identity keypair; public key stored in the clear, private seed never stored unwrapped. KEK = Argon2id(vault password, 16-byte random salt) — m=64 MiB, t=3, p=1, 32-byte output; the private seed is wrapped with AES-256-GCM (12-byte nonce, 128-bit tag). These KDF parameters are under active hardening review; the wire scheme is versioned (enc_scheme=e2e_v2) and each wrap is self-describing, so parameters can be raised without re-enrolling users. Adds are sealed public-key style: fresh ephemeral X25519 keypair → ECDH against the identity public key → HKDF-SHA256 (salt = ephemeral public key, info soult-pwk-e2e-v2) → AES-256-GCM. The entry stores ciphertext, IV and the ephemeral public key only. Two independent wraps of the same seed exist — one under the vault password, one under a 12-word phrase drawn from a 256-word list (≈96 bits) that is generated on-device and never transmitted. The MPIN is deliberately excluded from key derivation, since rotating or clearing it would otherwise permanently brick recovery; it is enforced as a separate UI gate at recovery time. enc_key_id = first 8 bytes of SHA-256(public key), so entries sealed to a superseded key after a vault reset are flagged unrecoverable rather than failing silently. The backend bypasses KMS entirely for e2e_ schemes: no server-side key for these fields exists to be compelled, audited or misused. Scope: only the password field is sealed; the protection relies on the integrity of the app you install.
Encryption in transit
Spy-proof Wi-Fi.
Data travels through a secure TLS tunnel. Anyone snooping on public airport or café Wi-Fi sees only encrypted gibberish — nothing about what you upload or read.
TLS 1.2+ enforced through API Gateway HTTPS. Files are uploaded and read through S3 presigned URLs that expire after 15 minutes.
The “no routine access” principle
Can Soult staff see my secrets?
Not in routine operation. Soult personnel do not view your vault content in the normal course of work; access to production systems is restricted by IAM and logged. When a death claim is being reviewed, a small number of authorised staff can open the documents in that account, and each such access is logged. Your most sensitive fields are also stored as KMS-encrypted ciphertext.
Least-privilege IAM for application roles. Production access is limited to a small number of named administrators and is logged. Death-claim reviewers are a short allowlist, and every document they open is logged. Only KMS-encrypted fields are ciphertext at the database layer; other content is protected by IAM access controls and logging.
Two executor roles
Who can ever see my vault?
Regular Executor (typically a family member): has their own dashboard listing the people they're named for. Can raise a death claim. Only after Soult verifies and approves it can they sign in — with phone and email OTP — and see your vault.
Emergency Executor (any trusted person you choose — spouse, child, sibling or friend): no death claim needed. Can sign in at any time after phone and email OTP. You get an email as soon as they sign in.
Both roles see your vault in read-only mode. The emergency role is for medical emergencies and time-critical situations; the regular role is for handover after death. How many executors you can name depends on your plan.
Role-based access in application logic. Each executor carries an is_emergency flag (any relationship; total executors capped by plan). Non-emergency executors can sign in only after a death claim is approved; emergency executors can sign in at any time. Executor sign-in requires OTP verification and emails the owner. Executor sessions are read-only.
Handover protocol
How does my family actually get access?
The named Regular Executor raises a death claim from their dashboard and uploads a death certificate; you and your other executors are emailed. An authorised Soult administrator reviews the claim and certificate before approving it — nothing is released on an unverified request. Once approved, your account becomes read-only, and the executor signs in with phone and email OTP to view and download the vault. An email goes to your registered address each time an executor signs in. Advanced Password Keeper passwords stay locked unless you have left your executor your vault password or Recovery Kit.
Gate: (1) a registered, verified executor raises a death claim from their dashboard with a certificate upload; (2) Amazon SES emails the owner and the other executors; (3) an allowlisted Soult administrator reviews and approves the claim; (4) approval opens executor sign-in, with phone + email OTP, and makes the account read-only at the API layer; (5) the owner is emailed on every executor sign-in. Claim uploads and approvals are recorded in a security event log.
No sharing, by design
Can I share one document with my CA or spouse?
Not today. There is no per-item sharing, no per-folder access for an accountant, no time-limited share link. The only way another person ever sees inside your vault is through the executor flow described above — and then they see everything in read-only mode. There is no per-item or per-folder granularity yet.
No collaboration mechanism implemented. Sole access paths: (1) authenticated owner session, (2) executor session post-verification. No share-link generation, no scoped tokens, no per-resource ACL. Roadmap consideration only — not built.
Reality check
What are the risks?
We work to protect against hackers, account takeover, and insider access. We cannot stop you from being physically forced to share your PIN. Soult is for organisation and family continuity — not protection from a coerced disclosure under duress.
Threat model excludes physical coercion. Mitigates: exfiltration, account takeover, insider access. Out of scope: PIN extraction under duress, device compromise post-unlock.
Indian soil
Where exactly does my data live?
Today, all vault data sits in our India silo in AWS Mumbai. We're preparing to launch in the UAE. Vaults for users there will be stored in AWS Mumbai (India), and we'll ask for their explicit consent to that at sign-up. Future silos for the US and Southeast Asia, and a dedicated GCC silo, are on our roadmap.
Active silo: ap-south-1 (Mumbai), with data stored across multiple Availability Zones. Cross-region DR is on our roadmap. Built with DPDP Act, 2023 principles in mind. No other silo is live, and no users are served from a GCC region.
Disaster recovery tiers
What happens at each level of failure?
Tier 1 — one server fails: invisible to users; AWS's managed services replace it automatically.
Tier 2 — one Mumbai data centre fails: service continues, because your data is already stored across several data centres in Mumbai.
Tier 3 — the whole Mumbai region goes down: service pauses until AWS restores it. A standby in a second region is on our roadmap, not live today.
Tier 4 — the Mumbai region is permanently lost: we cannot fully recover from that today. Cross-region backup replication is on our roadmap. Until then, keeping your own backup is the strongest safeguard.
Tier 1: managed-service self-healing (Lambda, DynamoDB, S3). Tier 2: multi-AZ storage within ap-south-1. Tiers 3–4: no cross-region failover today; cross-region backup replication into a second region is on our roadmap.
The audit trail
Record of changes.
A record of every Create, Update or Delete on your vault, with who made the change and when.
Audit log table in DynamoDB. Tracks write operations (CUD). Read events excluded for user privacy and performance balance. Deleted along with the account.
Data usage boundaries
No selling, no training, no surprises.
Your vault content is never used to train AI models or for marketing. When AI features are used in the app, the data for that session is processed in-context only — never retained for model improvement. Revenue is subscription-only. If we ever consider a new way of earning — any change at all — we will ask you first. Not notify. Not announce. Ask. And we will only ask if we genuinely believe it benefits you.
Data isolation. No vault content fed into AI/ML training pipelines. AI features process data in-context per session only — no retention for model improvement. Revenue model independent of vault content. Future monetisation changes gated on explicit per-user opt-in — not announce-and-proceed.
Privacy vs handover
The bridge choice.
Chat apps focus on absolute secrecy — if you lose a key, they can't help you. That is a failure for a life vault. So we designed Soult differently: your vault is recoverable by design, so a lost phone or forgotten PIN never locks your family out, and verified executors can receive what you left them. Soult personnel do not have routine access, and handover happens only through a verified path. For the few passwords only you should ever open, Advanced Password Keeper gives you sole custody. Soult is a bridge to your legacy, not a digital dead end.
Standard vault data is encrypted server-side (S3 and DynamoDB encryption at rest, plus AWS KMS for sensitive fields), so it can be restored to you or shown read-only to a verified executor. No routine staff access; handover requires the verified death-claim flow described above. Advanced Password Keeper entries (e2e_v2) are the only data Soult cannot decrypt.
Roadmap
What is shipping next?
Near-term: one-click vault export (today users back up manually); US silo (N. Virginia, DR Oregon); SEA silo (Singapore, DR Jakarta); cross-silo backup replication so something always survives even if a whole region is lost.
Mid-term: a dedicated GCC silo; SOC 2 Type II.
Always-on: ongoing audits, security hardening, infrastructure reviews.
Phase 1 (next): one-click encrypted export, US silo bring-up. Phase 2: SEA silo, cross-silo cold backup replication, WAF, SSL pinning on mobile clients. Phase 3: dedicated GCC silo, SOC 2 Type II, hardened multi-region KMS.
Honest claims
Every marketing claim, checked. What is true today, what is planned, what is not built, what we do not use.
| Claim | Status | The practical truth |
|---|---|---|
| No routine staff access | TRUE | No routine staff access to vault content; production access is restricted and logged. A small allowlist of reviewers can open an account's documents when reviewing a death claim, each access logged. Except for Advanced Password Keeper passwords, this is an access control, not a technical impossibility. |
| Data residency in India | TRUE | All vault data is stored in India, in AWS Mumbai. Some operational data (sign-in codes, payments, analytics, crash reports) is handled by providers that may process it outside India. |
| ISO 27001 & ISO 9001 certification | IN PROGRESS | Security programme aligned with ISO 27001. Quality management aligned with ISO 9001. Accredited certification in progress for both. |
| AES-256 encryption | TRUE | All vault data is encrypted at rest with AES-256, and sensitive fields get an extra AWS KMS layer. |
| Password Keeper — Standard | TRUE | The default. The password is encrypted on our servers with AWS KMS, so it can be recovered and handed over to your executors. |
| Password Keeper — Advanced | LIVE | Live since July 2026 (opt-in). Turn on Advanced for a Password Keeper entry and its password is encrypted on your phone with a key derived from a vault password only you know, so Soult cannot decrypt it. The entry's other details (title, username, website, notes, security question and answer) use Standard protection. Lose both your vault password and your 12-word recovery phrase and that password cannot be recovered. |
| One-click vault export | PLANNED | Not built today. Users take manual backups. One-click export is on our roadmap. |
| Per-item sharing | NOT BUILT | No sharing or collaboration today. Executor flow is the only access path. |
| Cross-silo backup | ROADMAP | Backup replication to a second region is on our roadmap and comes as the US/SEA silos deploy. |
| Cross-region disaster recovery | ROADMAP | Today your data lives in one AWS region (Mumbai), stored across several data centres there. A standby in a second region is on our roadmap; until then, your own backup is the strongest safeguard against losing a whole region. |
| Deletion from live systems | IMMEDIATE | 10-second confirmation and your MPIN, then your login, records and files are removed from live systems. There is no per-user key, so backups, earlier file versions and logs are not crypto-shredded or erased instantly. |
| AI training on user data | NEVER | Vault content is never used for AI model training, even when AI features are used in-session. |
| Blockchain | NOT USED | Wrong tool for a private vault. We use audit logs instead. |
| Zero-knowledge encryption | PARTLY LIVE | Partly live today. Advanced Password Keeper entries are genuinely client-side encrypted — sealed to a key derived from a vault password that never reaches us, so we cannot decrypt them (see Client-side encryption). The rest of the vault is encrypted on our servers, with sensitive fields under AWS KMS. That is strong, but not zero-knowledge — deliberately, so your family is never locked out. Wider opt-in zero-knowledge options remain on our roadmap. |
Common questions
How do I delete my data?
After a 10-second confirmation pause and your MPIN, your sign-in and vault records are deleted from our databases and your files are removed from active storage straight away. This can't be undone by you or by our support team. Copies in backups, earlier file versions and system logs are not erased instantly, and a payment record is kept with your personal details removed. Download anything you want to keep first. A one-click export is on our roadmap.
What if Soult shuts down?
If Soult ever had to close, we would tell you in advance and help you get a copy of your vault. A one-click export is on our roadmap. We will not sell your data or transfer your vault to a buyer without your consent.
How are subscriptions billed?
Managed via Razorpay on the Soult website. No in-app purchases. This keeps billing separate from your vault device.
Erasure protocol details?
On confirmation, the user's Cognito sign-in is deleted, their rows are purged from the vault tables in DynamoDB and their S3 files are removed from active storage, with an asynchronous second clean-up pass. Payment records are kept with personal details redacted. There is no per-user key, so no crypto-shredding; backups, earlier file versions and logs are not erased instantly.
Why doesn't Soult use blockchain?
Blockchain is built for public verification on shared ledgers where parties do not trust each other — cryptocurrency, supply chains across rivals, public land records. Its strength is making tampering visible to the world.
Soult vaults are the opposite of public — they are private by design. The user is the only party with stake in the data. Tampering intent is low: it is the user's own data, kept for the user's own family.
For change tracking, we use audit logs (see section 14) — every Create, Update, Delete is recorded with timestamp and actor. Blockchain would add cost, complexity, and reduce privacy by exposing patterns to a public ledger — without solving any user problem.
Reconsidered if and when verified-public attestation becomes a real user requirement.
More on what Soult can and cannot do — read the Legal Validity page. For the executor protocol in detail, see Executor & Handover Flow.
Get Started Free →