Money, property & valuables→Important documents & Will→Medical wishes & emergency info→Memories, stories & voice notes→Relationships & trusted people→
Security & privacy→How Soult works→Executor & handover flow→Legal validity→Legal Help Centre→Security Whitepaper→Blog & life guides→Help centre→About Soult→
Pricing→Early access→
Corporate Employee Wellness→Channel Partners→
My AccountStart Protecting Today
🛡Security Whitepaper

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.

01Crafted infrastructure

System design

Practical perspective

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.

Technical logic

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.

01aSilo architecture

One region today, silos next

Practical perspective

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.

Technical logic

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.

02Partnership

Why AWS Mumbai?

Practical perspective

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.

Technical logic

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.

03Identity access

Authentication flow

Practical perspective

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.

Technical logic

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.

04Household privacy

MPIN on shared devices

Practical perspective

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.

Technical logic

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.

04aThe PIN-length choice

Why a 4-digit PIN?

Practical perspective

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.

Technical logic

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.

05Storage safety

Hard drive risk

Practical perspective

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.

Technical logic

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.

06Authority

Key management (KMS)

Practical perspective

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.

Technical logic

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.

07The double lock

Field-level security

Practical perspective

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.

Technical logic

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.

07aA vault inside your vault

Client-side encryption

Practical perspective

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.

Technical logic

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.

08The tunnel

Encryption in transit

Practical perspective

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.

Technical logic

TLS 1.2+ enforced through API Gateway HTTPS. Files are uploaded and read through S3 presigned URLs that expire after 15 minutes.

09Staff boundaries

The “no routine access” principle

Practical perspective

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.

Technical logic

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.

10Executor roles

Two executor roles

Practical perspective

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.

Technical logic

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.

11The legacy handover

Handover protocol

Practical perspective

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.

Technical logic

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.

11aSharing reality

No sharing, by design

Practical perspective

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.

Technical logic

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.

12Honesty

Reality check

Practical perspective

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.

Technical logic

Threat model excludes physical coercion. Mitigates: exfiltration, account takeover, insider access. Out of scope: PIN extraction under duress, device compromise post-unlock.

13Sovereignty

Indian soil

Practical perspective

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.

Technical logic

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.

13aDisaster tiers

Disaster recovery tiers

Practical perspective

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.

Technical logic

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.

14Visibility

The audit trail

Practical perspective

Record of changes.

A record of every Create, Update or Delete on your vault, with who made the change and when.

Technical logic

Audit log table in DynamoDB. Tracks write operations (CUD). Read events excluded for user privacy and performance balance. Deleted along with the account.

14aUsage limits

Data usage boundaries

Practical perspective

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.

Technical logic

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.

14bThe handover tension

Privacy vs handover

Practical perspective

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.

Technical logic

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.

15Future path

Roadmap

Practical perspective

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.

Technical logic

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.

16Veracity

Honest claims

Every marketing claim, checked. What is true today, what is planned, what is not built, what we do not use.

ClaimStatusThe practical truth
No routine staff accessTRUENo 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 IndiaTRUEAll 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 certificationIN PROGRESSSecurity programme aligned with ISO 27001. Quality management aligned with ISO 9001. Accredited certification in progress for both.
AES-256 encryptionTRUEAll vault data is encrypted at rest with AES-256, and sensitive fields get an extra AWS KMS layer.
Password Keeper — StandardTRUEThe default. The password is encrypted on our servers with AWS KMS, so it can be recovered and handed over to your executors.
Password Keeper — AdvancedLIVELive 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 exportPLANNEDNot built today. Users take manual backups. One-click export is on our roadmap.
Per-item sharingNOT BUILTNo sharing or collaboration today. Executor flow is the only access path.
Cross-silo backupROADMAPBackup replication to a second region is on our roadmap and comes as the US/SEA silos deploy.
Cross-region disaster recoveryROADMAPToday 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 systemsIMMEDIATE10-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 dataNEVERVault content is never used for AI model training, even when AI features are used in-session.
BlockchainNOT USEDWrong tool for a private vault. We use audit logs instead.
Zero-knowledge encryptionPARTLY LIVEPartly 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.
17 — Support & Erasure

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.

18 — Common Myths

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 →
Available on iOS & Android

8,000+ families
on the path of continuity.

Useful every day — organise your assets, memories and important documents in one private vault. Built to pass everything on to your family exactly as you intend, whenever the time comes.

“Before finding Soult, my important documents were scattered everywhere and I was constantly forgetting passwords. This app is a total lifesaver. The Password Keeper is incredibly secure, and I love that I can easily upload my family's IDs and health records into the Medical Binder so I have them instantly at the doc…”
App Store review · Sept 2026
Read all reviews on App Store · Google Play
Your vault is protected by AES-256 encryption at rest, TLS encryption in transit and role-based access controls. Advanced Password Keeper passwords are encrypted on your device.
ISO/IEC27001ALIGNEDISO 27001-alignedAccredited certification in progress
ISO9001ALIGNEDISO 9001-alignedAccredited certification in progress
AES-256Encryption at rest · TLS in transit
AWSAWSSecure Cloud Hosting
Contact us