SECURITY ARCHITECTURE
The Architecture Behind the Guarantee
We do not ask you to trust us. We ask you to verify the mathematics. Every cryptographic primitive is NIST-standardised, open-source, and auditable directly from your browser console — no proprietary black boxes.
PROOF & DOCUMENTATION
Everything in One Place
A reviewer should never have to hunt for proof. Architecture, scope, threat model, disclosure policy, and our open-source roadmap — linked directly below.
Audit Status →
Internal review complete, bug bounty active, external audit planned (not yet scheduled).
DocumentSecurity Whitepaper →
Full cryptographic protocol — AES-256-GCM, random keys, Shamir SSS, heir release.
PolicyPrivacy Model →
Zero PII stored. Data minimisation by design. GDPR-aligned.
On this pageThreat Model →
Six adversary classes, impact, and mitigations.
On this pageAudit Scope →
Complete surface published before engagement — no exclusions.
PolicyResponsible Disclosure →
Rules of engagement, safe-harbour, and how to report.
ProgrammeBug Bounty Programme →
Severity tiers, scope, Hall of Fame + CVE credit.
RFC 9116security.txt →
RFC 9116 machine-readable disclosure contact.
GitHubOpen-Source Crypto-Core →
AES-256-GCM · SHA-256 · Shamir SSS · MIT — live on GitHub.
Grey-box source review of the crypto core, all API routes, auth/MFA, and the succession protocol, modelled on Cure53 methodology. No Critical or High findings. All Medium findings resolved before public launch; residual items are Low/Info hardening, tracked internally. External professional audit planned — scope ready, auditor not yet selected and no date committed; full report will be published on completion.
Download internal review (PDF) →ZERO-KNOWLEDGE DATA FLOW
How Your Data Actually Moves
Your Owner Key (Shard 1) is downloaded to your device and never transmitted to VaultPass. We hold at most one of the remaining shards — never enough to reconstruct your vault alone. Every encryption step runs in your browser before any data is sent.
ALL THREE STEPS OCCUR IN YOUR BROWSER — NO PLAINTEXT IS EVER TRANSMITTED
3-STEP ZERO-KNOWLEDGE FLOW
How VaultPass Stays Zero-Knowledge
From the moment you type your seed phrase to the moment shards reach their guardians — every transformation happens on your device. Watch it happen below.
Prove it yourself →DISTRIBUTED VAULTING · INTERACTIVE
Sentinel Sharding — Live
Distribute your vault key across three independent guardians, then reconstruct it using any two. No single guardian holds enough to open the vault — not even us.
SHAMIR'S SECRET SHARING · 2-OF-3 THRESHOLD · OPEN STANDARD
THE SENTINEL PROTOCOL
How the Dead-Man's Switch Works
“Security is not a promise; it is a verifiable sequence of cryptographic events.”
Zero-Knowledge Encryption
Before any data is stored, it is encrypted on your device using AES-256-GCM — a NIST-standardized authenticated-encryption cipher. Your master key never touches our servers.
The Heartbeat (Sentinel Pulse)
You define your inactivity threshold: 30, 180, or 365 days. A secure Cloud Function monitors the timestamp of your last check-in. This is the only metadata we track.
The Verification Phase (Grace Period)
A missed heartbeat does not immediately trigger release. The system enters a Grace Period and sends encrypted notifications via Email. You can reset the timer at any point with a single click.
The Event Horizon (Inheritance Release)
Once threshold + grace period expires, the Sentinel releases its shard. Combined with the heir's sealed shard, the vault reconstructs — without your Owner Key, without VaultPass staff involvement, and without any central point of control.
OPEN SOURCE PROMISE
The cryptographic primitives are browser-native and independently verifiable today. The crypto-core module — AES-256-GCM, SHA-256, and Shamir's Secret Sharing — is open-source and MIT-licensed on GitHub right now. The crypto path is left unobfuscated in the shipped app, so you can read it in your browser's DevTools and confirm it matches the public source — no hidden cryptography. That verifies the algorithm itself; the independent external audit, which covers the whole application, is planned — scope finalised, not yet scheduled.
NIST-standardised authenticated encryption. Browser-native via Web Crypto API.
crypto.subtle.generateKey({name:"AES-GCM",length:256},true,["encrypt","decrypt"])Each vault key is a fresh random 256-bit key from the browser CSPRNG — not derived from a password.
crypto.getRandomValues(new Uint8Array(32))Splits your key into N shards; any M can reconstruct it. Mathematically proven; no central custodian.
github.com/lionzion351-dev/crypto-core (open source · live)Open any browser DevTools console on this site and run the snippets above. The cryptography is real.
DESIGN RATIONALE · PRIMITIVE SELECTION
Why AES-256-GCM and not ChaCha20-Poly1305?
Both are AEAD (Authenticated Encryption with Associated Data) ciphers with equivalent security margins. AES-256-GCM is browser-native via the Web Crypto API, which eliminates the risk of a flawed JavaScript implementation of ChaCha20. Hardware AES acceleration is available in every modern CPU — latency is negligible. The authentication tag (GHASH) ensures any ciphertext modification is detected before decryption.
Why Shamir's Secret Sharing over threshold signatures (e.g. FROST)?
Shamir SSS operates on a finite field (GF(2^8) or GF(prime)) using polynomial interpolation — it is information-theoretically secure. A shard below the threshold reveals absolutely zero bits of the secret, provably. Threshold signature schemes like FROST require all participants to be online simultaneously for key generation. SSS allows offline shard distribution — critical for an inheritance protocol where heirs may only be online months or years after setup.
Why isn't the vault key derived from my password?
Because a password-derived key would require your heir to know your password — which defeats the entire point of password-free inheritance. Instead, each vault uses a fresh random 256-bit key from the browser CSPRNG, split via Shamir's Secret Sharing so any 2 of 3 shards reconstruct it. Your heir recovers the vault from shards, never from a password you'd have to share. (PBKDF2 key-stretching is used only in the standalone importer that decrypts files you bring from other password managers.)
Open Source · Live
github.com/lionzion351-dev/crypto-core
AES-256-GCM · SHA-256 · Shamir SSS implementation · MIT licensed
LIMITATIONS & RISK DISCLOSURE
No security product is absolute. Here is exactly what VaultPass does not protect against, and how your secrets could still be lost — so you can plan around it.
It is not a full estate plan or legal advice
VaultPass delivers your encrypted secrets to a chosen heir. It does not replace a will, an executor, or legal counsel. Treat it as one layer alongside your hardware-wallet backups and legal documents.
Your heir must act — correctly and in time
Release is automated; recovery is not. If your heir ignores notifications, loses their access, or cannot follow the recovery steps, the vault is not opened for them. Brief your heir in advance and keep their contact details current.
Secrets can be lost if enough shards are lost
The vault key is split 2-of-3. If you lose your owner shard and the server-held shards also become unavailable, the vault cannot be reconstructed. There is no master backdoor — that is the point, and the risk. Keep your owner shard and an encrypted export safe.
Email is part of the recovery chain
Check-in reminders and heir notifications use email. A compromised or abandoned inbox (phishing, SIM-swap on any SMS fallback, provider lockout) weakens that link. Use a secure, monitored inbox and enable MFA.
Trust boundary while VaultPass operates
While the service runs, VaultPass holds the encrypted heir and sentinel shards and combines them only when your switch fires. A full internal compromise of both server-held shards after a trigger is the worst case we design against — and a key reason the independent external audit matters. Your plaintext and owner shard are never on our servers.
Recovery if VaultPass disappears
The reconstruction math is open-source (crypto-core). Exported shards can be recombined without our servers, so a permanent shutdown does not strand a vault you have exported. Keep an encrypted export.
AUDIT ROADMAP
Full threat-model analysis, code review, and cryptographic protocol verification by the core team.
Public invitation for independent researchers to find and responsibly disclose vulnerabilities. Valid findings earn Hall of Fame credit and CVE recognition (no cash bounties).
Independent third-party cryptographic audit by a specialist security firm. Full report will be published publicly upon completion.
COMPLIANCE & CERTIFICATIONS
Institutional Standards
Commitment to regulatory and industry frameworks is not a checkbox — it is a constraint that shapes architecture decisions from day one.
External audit planned — scope ready, not yet scheduled. Full report published on completion.
Zero PII stored. Data minimisation by design. No IP logging.
Identify · Protect · Detect · Respond · Recover
EXTERNAL AUDIT SCOPE
Published Scope Document
Published prior to engagement so any researcher — not just our auditor — can review the same surface area. Scope is intentionally complete: no exclusions that would hide known weaknesses.
Cryptographic Implementation
Authentication & Session Management
API & Server Security
Client-Side Security
Heir Delivery Protocol
Infrastructure & Supply Chain
Full audit report, including findings, severities, and retest confirmation, will be published publicly at this URL upon completion. No findings will be withheld. Auditing firm to be announced on engagement.
TRUST TIMELINE
Verifiable History
Every security milestone, audit event, and infrastructure change — timestamped and permanent. Updated as events occur; nothing retroactively edited.
Architecture design complete. Zero-knowledge constraint formalised: plaintext must never leave the client device. Threat model drafted.
Full threat-model analysis, cryptographic protocol review, and code audit by the core team. All critical findings resolved before public launch.
VaultPass opened to early users. Random-key AES-256-GCM encryption and Shamir 2-of-3 sharding live in production.
Public vulnerability disclosure programme opened. Valid findings earn Hall of Fame credit and CVE recognition. Responsible disclosure policy published at /security.
AES-256-GCM, SHA-256, and Shamir's Secret Sharing implementation published as a standalone, dependency-free, MIT-licensed module on GitHub — ahead of the external audit, for independent review.
Independent third-party cryptographic and application security audit planned. Scope finalised and ready; auditor not yet selected and no date committed. Full public report to be published upon completion.
External SOC 2 Type II audit covering Security, Availability, and Confidentiality Trust Services Criteria. Report to be published publicly.
RESEARCHER ACKNOWLEDGEMENTS
Hall of Fame
Security researchers who disclosed vulnerabilities responsibly and helped make VaultPass safer. Listed with permission. We are bootstrapped and offer recognition and CVE credit, not cash payments.
NO VULNERABILITIES REPORTED YET
Be the first. Valid findings earn public recognition here and CVE credit. We are bootstrapped — we offer acknowledgement, not cash. All reports acknowledged within 48 hours.
[email protected] →REFERENCED IN /.WELL-KNOWN/SECURITY.TXT · RFC 9116 COMPLIANT
ARCHITECTURE TEAM
Two Domain Specialists. No Generalists.
Cryptographic decisions and product decisions are handled by separate, focused roles. No single person controls both the key architecture and the user-facing protocol — by design.
“Every cryptographic primitive is NIST-standardised. Every integration is peer-reviewed before deployment. The architecture is designed so any competent cryptographer can verify it without taking our word.”
“The inheritance trigger must work correctly the first time — for a person who has just lost someone. That single constraint shapes every product decision: no friction, no dependency on VaultPass staff, no lawyers required.”
“We are confident in our architecture — confident enough to invite independent researchers to break it. No security claim at VaultPass is considered final until it has survived external scrutiny.”
THREAT MODEL
What We're Defending Against
A security architecture is only meaningful when measured against specific, named threats. Below is the complete threat model for VaultPass — including threats we cannot fully prevent and why zero-knowledge limits their blast radius.
Impact if successful
Database read access — ciphertext only
Mitigation
Zero-knowledge by design. AES-256-GCM ciphertext without the master key is computationally indistinguishable from random bits. 2^256 keyspace — brute force is physically impossible within the age of the universe.
Impact if successful
Traffic inspection or credential intercept
Mitigation
TLS 1.3 enforced on all endpoints. All plaintext encryption occurs client-side before any byte leaves the device. A successful MITM yields only ciphertext and salted auth tokens.
Impact if successful
Seed phrase capture at point of entry
Mitigation
Session inactivity lock. No persistent plaintext in memory between sessions. Vault contents cleared on tab close. No clipboard persistence. 2FA enforced on account login.
Impact if successful
Account takeover via login
Mitigation
Supabase bcrypt-hashed auth credentials. Upstash Redis rate limiting (5 req/min on auth endpoints). Account lockout after 10 failed attempts. The vault key is a random key, not derived from your password, so a cracked login password alone does not decrypt vault ciphertext without the owner's separately-held shard.
Impact if successful
Unauthorized access to production systems
Mitigation
No employee accesses vault plaintext in normal operation, and no interactive decryption back door exists. Production access requires MFA and is fully audited, with separation of duties between infrastructure and cryptographic roles.
Impact if successful
Theoretical weakening of encryption guarantees
Mitigation
AES-256 is quantum-resistant to Grover's algorithm (effective 128-bit post-quantum security). SHA-256 resistant to known quantum attacks. Post-quantum migration path (ML-KEM / CRYSTALS-Kyber) planned within the external audit scope.
INCIDENT RESPONSE POLICY
How We Respond When Things Go Wrong
Detection → Triage → Containment → Remediation → Disclosure. Every incident is assigned a severity tier with binding response time commitments. Affected users are notified before the public.
Examples
Acknowledge
< 1 hour
Notify Users
< 4 hours
Remediate
< 24 hours
Disclose
Within 72 hours
Examples
Acknowledge
< 4 hours
Notify Users
< 8 hours
Remediate
< 72 hours
Disclose
Within 7 days
Examples
Acknowledge
< 24 hours
Notify Users
< 48 hours
Remediate
Next sprint
Disclose
On resolution
Report incidents: [email protected] · Status updates posted to vaultpass.network/status · Post-mortems published for all P0 and P1 incidents.
VULNERABILITY DISCLOSURE POLICY
Responsible Disclosure — Full Policy
We operate a public responsible disclosure programme. Researchers who follow this policy will not face legal action. Valid findings earn public credit and Hall of Fame acknowledgement. We respond within 48 hours and target a 90-day patch window.
In Scope
Out of Scope
Safe Harbor · Security research conducted in good faith under this policy will not result in legal action. We will not refer researchers to law enforcement for responsible disclosure that adheres to these guidelines. Your research helps make VaultPass safer for everyone.
SECURE SOFTWARE DEVELOPMENT LIFECYCLE
Security at Every Stage of Development
Security is not a review step at the end of a sprint. Every phase of the VaultPass development lifecycle has security controls built in — from whiteboard to production monitoring.
Design
Development
Review
Deploy
Monitor
KEY MANAGEMENT PRACTICES
Complete Key Lifecycle
The security of your vault is entirely determined by how its encryption key is generated, stored, used, and destroyed. Every stage of that lifecycle is documented here.
All cryptographic keys generated using the browser CSPRNG via Web Crypto API (window.crypto.getRandomValues). No server-side key generation for user vault keys. Randomness cannot be influenced or observed by VaultPass.
VaultPass does not derive vault keys from a password. The random per-vault key is used directly with AES-256-GCM and then split via Shamir's Secret Sharing — there is no master-password KDF in the vault path.
The full vault key is never persisted. Only AES-256-GCM ciphertext and encrypted key shards are stored in Supabase — a database-only compromise yields ciphertext, not plaintext.
Vault key split via Shamir's Secret Sharing (2-of-3). Owner shard downloaded to your device and never uploaded; heir and sentinel shards stored by VaultPass, encrypted at rest with secrets held outside the database. Any single shard reveals zero bits. The heir + sentinel shards are used to reconstruct the key during heir release.
Re-encrypting your vault generates a fresh random vault key, re-splits it via Shamir, and replaces all stored ciphertext and shards browser-side. Previous ciphertext is overwritten and irrecoverable.
Account deletion triggers immediate removal of all ciphertext, Shamir shards, and associated metadata from Supabase. No soft-delete or recovery window for vault contents. Destruction is permanent and irreversible.
EMPLOYEE ACCESS CONTROLS
Internal Access Policy
Your vault is encrypted on your device before it reaches us — we store ciphertext, not plaintext. The encrypted heir and sentinel shards we hold for automated delivery are combined only when the dead man's switch fires. The controls below govern everything else.
Principle of Least Privilege
All internal service accounts scoped to minimum required permissions. Supabase Row-Level Security (RLS) enforced on every table — no application-layer bypass possible. Service role keys used only for server-side operations that explicitly require them.
Zero-Knowledge Enforcement
No VaultPass employee accesses user vault plaintext in normal operation, and the full vault key is never transmitted to our servers — owner shards stay on user devices. Note that automated heir release requires our infrastructure to hold the heir and sentinel shards, so this is end-to-end encryption with automated delivery rather than a technical inability to decrypt.
Multi-Factor Authentication
MFA required for all production system access: Supabase dashboard, Vercel deployment, GitHub, and Stripe. TOTP authenticator apps required — SMS MFA explicitly prohibited due to SIM-swap risk.
Audit Logging
All production database access, deployment events, and admin actions are logged with timestamp, identity, and action. Logs are immutable and retained for 12 months. Anomalous access patterns trigger automated alerts.
Code & Repository Access
Repository access restricted to active team members. All commits GPG-signed. Main branch protected — no direct pushes. Automated secret scanning on every push prevents accidental credential commits.
Offboarding Protocol
Departing team members have all access revoked within 24 hours across GitHub, Supabase, Vercel, Stripe, and shared credentials. OAuth tokens rotated immediately. Quarterly access review performed for all active accounts.
RECOVERY GUARANTEES
What We Guarantee, In Writing
Most password managers ask you to trust their uptime. VaultPass is designed so that even a full service failure cannot lock you or your heirs out of your vault. These are not aspirational targets — they are architectural constraints.
Inheritance Without VaultPass
Because your Owner shard lives on your device and the Heir shard is held by your designated heir, vault reconstruction requires no VaultPass infrastructure. Any 2-of-3 Shamir shards reconstruct the vault key. Your inheritance plan works even if VaultPass ceases to exist.
Data Durability
Encrypted vault data stored in Supabase with continuous replication across multiple EU availability zones. Point-in-time recovery available for 30 days. Target RPO: 0 seconds (synchronous replication). Target RTO: < 15 minutes for full restoration.
No Vendor Lock-in
Your encrypted vault export is available at any time from the dashboard in standard JSON. The export is AES-256-GCM encrypted and readable with the open-source crypto-core module (live on GitHub) — no VaultPass software required to decrypt your own data.
Service Continuity Commitment
If VaultPass is acquired, merged, or ceases operations: 90-day notice to all users; full vault export delivery to all active accounts; open-sourcing the full cryptographic core before shutdown so heirs can reconstruct vaults independently forever.
Uptime SLA Target
99.9% monthly uptime target for API and Heartbeat Sentinel (< 44 minutes downtime/month). Planned maintenance announced 48 hours in advance. Sentinel trigger clock pauses during verified VaultPass outages — your inactivity window is never unfairly consumed.
Export your encrypted vault at any time from the Dashboard → Settings → Export. Your data is always yours.
END-TO-END SECURITY
Your Email is Part of the Security Chain
VaultPass protects your vault with AES-256-GCM encryption and zero-knowledge architecture. But the last mile — delivering your vault to your heir — depends on email. A compromised or inaccessible inbox can break the chain. Here is what we recommend.
Your Email (Vault Owner)
Strong unique password
Use a password manager for your email account. Never reuse passwords across services.
Enable 2FA
Use Google Authenticator or Microsoft Authenticator — not SMS, which is vulnerable to SIM-swap attacks.
Recovery method
Add a backup email and phone number. Losing email access means losing check-in ability, which could trigger your vault prematurely.
Your responsibility
VaultPass sends check-in reminders and warning emails to this address. Losing access to it could trigger your dead man's switch unintentionally.
Your Heir's Email
Active & accessible inbox
The vault transfer token is delivered by email. If your heir cannot access their inbox, they cannot claim the vault.
Enable 2FA on their account
A compromised heir inbox means an attacker could intercept the vault transfer. Authenticator-based 2FA prevents this.
Safe-sender list
Ask your heir to add vaultpass.network to their trusted senders now — before it matters — so transfer emails are never caught by spam filters.
Brief them now
Don't wait until the switch triggers. Tell your heir about VaultPass, their role, and that they should keep this email address active.
Our commitment: VaultPass secures what we control — the vault encryption, the key sharding, the trigger protocol. What we cannot control is whether you and your heir maintain access to your email accounts. That responsibility is yours. We strongly recommend briefing your heir when you set up your vault, not after you need it.
RESPONSIBLE DISCLOSURE
Found a Vulnerability?
We are confident in our code — confident enough to invite researchers to break it. Valid findings earn public acknowledgement in our Hall of Fame. We are a bootstrapped startup: we offer recognition, credit, and a CVE, not cash. Disclosure acknowledged within 48 hours.