Honest, Transparent Security
We don't claim 'military-grade' or 'unbreakable' because those are marketing lies. Here is the complete, honest truth about how we protect your legacy, written for humans.
Prefer the technical deep-dive? Read the Security WhitepaperTwo levels of protection
Every Soult vault is encrypted server-side. For your most sensitive passwords, you can go one step further — and hold the only key yourself.
Everything in your vault
Encrypted in transit (TLS) and at rest (AES-256), with your most sensitive details — Aadhaar, PAN, card and account numbers — under an extra AWS KMS lock. Soult personnel do not have routine access to your vault. Recoverable by design, so a verified executor can be given read-only access when the time comes.
Your most sensitive passwords
Encrypted on your device with a key derived from a vault password only you know. The key never reaches Soult — so we cannot decrypt these passwords, even if compelled. Only the password itself is sealed; the rest of the entry uses Standard protection. Protected by a Recovery Kit you keep.
The honest trade-off: if you lose both your vault password and your Recovery Kit, these entries are gone for good — not even Soult can restore them. That is the point of sole custody.
You decide which passwords only you can ever open. Everything else stays recoverable on purpose, so a lost phone or forgotten PIN never locks your family out. More opt-in zero-knowledge options are on our roadmap.
Architecture Overview
Where does my data actually live?
Your data is stored in AWS data centres in Mumbai. Soult runs on serverless AWS services — Lambda, DynamoDB, S3 and Cognito — so 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, which we do with authentication, least-privilege access and monitoring.
- Serverless: AWS Lambda, DynamoDB, S3, Cognito.
- Primary Region: ap-south-1 (Mumbai).
- Cross-region disaster recovery: on our roadmap.
Data Residency & Silos
Where does each user's data go?
Today Soult runs from one AWS region — Mumbai, in India — and every 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 for other markets are on our roadmap; none is live yet.
- Today: a single region, ap-south-1 (Mumbai), for every user.
- Roadmap: separate regional silos, each with its own database and file store.
- No country-based routing between silos is live yet.
Why AWS Mumbai?
Why AWS Mumbai for 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.
- Aligned with DPDP Act 2023 principles for Indian data.
- AWS's own infrastructure is independently audited, including ISO 27001 certification and SOC 2 reports.
- Physical security managed by AWS.
Identity & Login
How do I sign up and log in safely?
Registration: Verified via Phone OTP and Email OTP. You set a security question and a 4-digit PIN.
Trusted Use: Daily access requires only your 4-digit PIN.
New Device: Triggers 2-Factor Security: Phone OTP first, then your PIN.
- AWS Cognito for user identity management.
- AWS SNS for SMS-based OTP delivery.
- AWS SES for email-based OTP delivery.
Shared Device Safety
Why can't my family open my vault app on a shared phone?
In shared-phone homes, fingerprints allow anyone registered to enter. A private 4-digit PIN keeps your vault private while kids play games or your spouse uses the phone.
- MPIN is app-specific, not device-wide.
- Biometrics (fingerprint/face) are a device-level convenience, not a Soult security layer.
- PIN is stored securely in device keychain/keystore.
- Session tokens expire and require re-authentication.
Why a 4-Digit PIN?
Is a 4-digit PIN really secure enough?
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 — 6 digits cause too many forgotten PINs, lockouts, and resets.
- Brute-force protection: 3 attempts trigger a 24-hour lockout.
- Lockout is enforced server-side via Cognito.
- Your MPIN is sent only over TLS to our identity provider (AWS Cognito) to verify sign-in; 3 failed attempts lock the account for 24 hours.
- User experience decision to balance security and usability.
Data-at-Rest Encryption
What if someone steals a hard drive from your servers?
Your data is AES-256 encrypted at rest, so a stolen drive holds only unreadable ciphertext. The encryption keys are managed by AWS, separately from the data.
- DynamoDB tables are encrypted at rest (AES-256) with keys managed by AWS.
- Files in S3 use server-side encryption (SSE-S3, AES-256) and move through pre-signed links that expire after 15 minutes.
- All backups and snapshots are also encrypted.
Encryption Key Authority
Who holds the encryption keys?
AWS does. Our field-encryption key lives inside AWS Key Management Service hardware and never leaves it 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 — that is what makes a verified family handover possible, so it is not a key only you hold. Keys for files and database tables are managed by AWS.
- Field-level encryption keys are managed in AWS KMS; file and table encryption keys are managed by AWS.
- KMS keys are held in FIPS 140-validated Hardware Security Modules (HSMs).
Double-Lock Security
What is the double-lock security for sensitive fields?
For specific high-sensitivity details — Aadhaar, PAN and passport numbers, card and account numbers, and Standard Password Keeper passwords — we add a second layer: our servers encrypt each of those fields with a key held in AWS KMS before storing it. In the database they are ciphertext, and the app shows them masked until you choose to reveal them.
- Server-side, field-level encryption with a customer-managed AWS KMS key, applied by the backend before the record is written.
- These fields travel to us over TLS and are encrypted on our servers. Only Advanced Password Keeper passwords are encrypted on your device before upload.
Data-in-Transit Tunnel
Is my data protected on public Wi-Fi?
Data travels through a secure tunnel. Hackers on public airport Wi-Fi cannot see what you upload or read.
- TLS 1.2 or higher enforced for all API and data transfers.
- Our API accepts HTTPS connections only (via AWS API Gateway).
- File uploads and downloads use pre-signed S3 URLs that expire after 15 minutes.
Staff Access Boundaries
Can Soult staff see my secrets?
Not in routine operation. Soult personnel do not view your vault content in the normal course of work, and access to our production systems is restricted 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, so a database view alone does not reveal them.
- IAM roles follow the principle of least privilege.
- Access to production systems is restricted to authorised personnel.
- Administrative access is logged.
Executor Access Roles
Who can ever see my vault?
Regular Executor: Can raise a death claim. Once Soult verifies and approves it, they can sign in with phone and email OTP and see your vault in read-only mode.
Emergency Executor: (any trusted person you choose — spouse, child, sibling or friend) can sign in at any time after verifying their phone and email by OTP. Their access is read-only in the app, and you're emailed as soon as they sign in.
- Role-Based Access Control (RBAC) implemented in application logic.
- Executor roles are stored as attributes in DynamoDB.
- Executor sessions are read-only: executors cannot add, edit or delete anything in the app.
- Amazon SES emails you whenever an executor signs in.
Family Handover Flow
How does my family actually get access to my vault after I pass?
Your Regular Executor raises a death claim from their dashboard and uploads a death certificate; you and your executors are emailed. An authorised Soult administrator reviews the claim 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 your vault. An email goes to your account each time they sign in.
- Death claim, with a death certificate, verified and approved by Soult before any regular executor access.
- Executor sign-in requires phone and email OTP verification.
- Claims are approved by Soult admins in an access-restricted admin panel.
- Executor sessions are read-only, and the owner is emailed on every executor sign-in.
No Per-Item Sharing
Can I share one document with my CA or spouse today?
Not today. There is no per-item sharing, no per-folder access for an accountant, and no time-limited share link. The only other people who can ever see inside your vault are the executors you name, through the executor flow.
- Current architecture is single-tenant access per vault.
- Granular sharing (per-item, per-folder) is a significant architectural change.
- Focus is on post-mortem handover, not active collaboration.
- This simplifies the security model and reduces attack surface.
Real-World Risks
What are the security risks I should know about?
We work to protect against remote attacks. We cannot stop you from being physically forced to share your PIN. Soult is for organisation and family continuity.
- Threat model focuses on remote, technical attacks.
- Does not protect against coercion, social engineering, or physical threats to the user.
Data on Indian Soil
Where exactly does my data live and is it on Indian soil?
Today, all vault data is stored in India, on AWS in Mumbai. Built with India's DPDP Act, 2023 principles in mind.
- Primary: AWS ap-south-1 (Mumbai).
- Within Mumbai, data is stored across multiple AWS data centres (Availability Zones).
- Vault data is not stored outside India.
- All vault data stored in India (AWS Mumbai).
Disaster Recovery Tiers
What happens if a server or entire region fails?
Tier 1 — One server fails: Invisible to users; AWS's managed services replace it automatically.
Tier 2 — One Mumbai data centre fails: Service continues; your data is already stored across several data centres in Mumbai.
Tier 3 — The whole Mumbai region goes down: Service pauses until AWS restores the region. A standby in a second region is on our roadmap, not live today.
Tier 4 — Soult shuts down: We would tell you in advance and help you get a copy of your vault.
- AWS-managed serverless services (Lambda, DynamoDB, S3) recover from single-server failures automatically.
- DynamoDB and S3 store data redundantly across multiple Availability Zones in Mumbai.
- Cross-region backup and failover: on our roadmap.
- One-click self-serve export is on our roadmap.
Audit Trail
Is there a record of every change made to my vault?
Yes. Every Creation, Update or Deletion in your vault is recorded in an audit log, with who made the change and when.
- Changes are written to an audit log table in our database.
- Each Create, Update or Delete is logged with the user and a timestamp.
- Audit records are access-restricted and are deleted along with your account.
Data Use Limitations
Is my data ever used to train AI or sold to advertisers?
No. Your vault content is never used to train AI models or for marketing. Revenue is subscription-only. If we ever consider any new way of earning, we will ask you first — not notify, not announce — ask.
- Business model is subscription-based (SaaS), not data monetization.
- Our Privacy Policy commits that your vault content is never used for AI training.
- Vault content is not fed into analytics or AI training pipelines.
- Google Firebase and Meta App Events receive app events and device identifiers (crash reports also include your email) — never vault content.
Secrecy vs. Legacy
Why isn't my whole vault zero-knowledge?
Because a life vault has to outlive you. If only you held the key, a lost phone, a forgotten PIN or your passing could lock your family out for good. So we designed your vault to be recoverable: it is encrypted on our servers, Soult personnel do not have routine access, and the only way anyone else gets in is a verified handover to the executors you name. For the few passwords only you should ever open, turn on Advanced Password Keeper.
Soult is a bridge to your legacy, not a digital dead end.
- Recoverable by design: vault data is encrypted server-side (AES-256 at rest, plus AWS KMS for sensitive fields), so it can be restored to you or shown read-only to a verified executor. Advanced Password Keeper entries are the exception: encrypted on your device, and Soult cannot recover them.
Future Roadmap
What security features are coming next?
Near-term: One-click vault export, US silo (N. Virginia), SEA silo (Singapore).
Mid-term: Dedicated GCC silo, SOC 2 Type II.
Always-on: Ongoing audits, security hardening, infrastructure reviews.
- Vulnerability assessment completed; a full penetration test is planned.
- AWS patches the managed services we run on (Lambda, DynamoDB, S3, Cognito).
- Cloud configuration monitoring with CheckRed; automated dependency scanning is planned.
Honest Claims
The security industry is full of misleading buzzwords. Here’s what we claim, what we don’t, and why. We believe transparency is the highest form of security.
| Claim | Status | The Honest Truth |
|---|---|---|
| AES-256 Encryption | TRUE | Used for all data at rest. Data in transit is protected with TLS. This is the industry standard, not a special feature. |
| Indian Data Residency | TRUE | All vault data is stored and processed in India, in AWS Mumbai. We are not yet compliant with the DPDP Act as a whole — its full obligations apply from 13 May 2027. |
| Serverless Architecture | TRUE | Reduces attack surface: AWS runs and patches the underlying servers, and there are no long-running Soult servers to compromise. Application code, APIs and configuration still need protecting. |
| Zero-Knowledge | PARTLY LIVE | Only for Advanced Password Keeper passwords, which are encrypted on your device with a key Soult never receives. Double-locked fields are encrypted server-side with AWS KMS; our systems can decrypt them to show them to you and to support family handover, so they are not zero-knowledge. |
| 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. |
| End-to-End Encryption | PARTLY LIVE | Live only for Advanced Password Keeper passwords, which are encrypted on your device. Everything else is encrypted in transit (TLS) and at rest (AES-256) on our servers, not end-to-end. |
| SOC 2 Type II Report | ROADMAP | SOC 2: readiness work is in progress; we will publish the report when an independent auditor issues it. A Type II report also needs a 6–12 month observation period. |
| Military-Grade Security | MARKETING | This is a meaningless marketing term. We use specific, verifiable standards like AES-256 and FIPS 140-validated key hardware. |
| Immediate Deletion (live data) | IMMEDIATE | Deleting your account removes your sign-in and vault records from our databases and your files from active storage straight away. We don't use cryptographic erasure (there is no per-user key to destroy), so copies in backups, earlier file versions and system logs are not erased instantly. A payment record is kept with your personal details removed. |
| Unbreakable / Hack-Proof | NEVER | No system is unbreakable. We focus on multiple layers of defense, rapid detection, and transparent communication. |
| Blockchain | NOT USED | Blockchain is the wrong tool for this job. It's for decentralized, public trust. We need centralized, private trust. We use an audit log instead. |
Data Deletion & Business Failure
How do I delete my data permanently?
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.
What happens 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 subscription payments handled?
Managed via Razorpay on the Soult website. No in-app purchases. This keeps billing separate from your vault device.
Common Myths
Why doesn't Soult use blockchain?
Blockchain is built for public verification on shared ledgers where parties do not trust each other. Soult vaults are private by design.
For change tracking, we use audit logs — every Create, Update, Delete is recorded with timestamp and actor. Blockchain would add cost, complexity, and reduce privacy without solving any user problem.
- Use case mismatch: Blockchain is for decentralization and transparency.
- Soult requires centralization and privacy.
- An audit log records changes without blockchain overhead.
- Performance and cost of blockchain are prohibitive for this application.
Read the full Security Whitepaper
This page is the plain-English overview. For the complete technical architecture — encryption, key management, access controls and data residency in depth — read our Security Whitepaper.
Open the Security Whitepaper