Clarmont is built for the one situation where security really matters: when you're gone and the people you love need access. We designed every layer with that in mind — not just strong encryption, but an honest model of what we can and can't see, and why.
The short version: the sensitive stuff is encrypted before it reaches our servers. We hold the ciphertext. We don't hold the key.
Credential passwords, crypto seed phrases, and document contents are encrypted using AES-256 in GCM (Galois/Counter Mode) — the same algorithm used by the U.S. government and military. GCM provides both encryption and authenticated integrity checking, meaning a tampered ciphertext is detectable and rejected before decryption is attempted.
Your Clarmont account password is hashed with bcrypt, a slow-by-design hashing algorithm that makes brute-force attacks computationally prohibitive. We store the hash, never the password. If you forget your password, we can't recover it — you reset it.
All communication between your browser and Clarmont's servers uses TLS 1.3, the current industry standard, which provides forward secrecy — past sessions can't be decrypted even if a key is later compromised.
Documents you upload are stored in Cloudflare R2 object storage with server-side AES-256-GCM encryption at rest. R2 uses GCM as its preferred mode — the same as our field-level encryption.
Encryption keys for sensitive fields are derived from a combination of the user's credentials and a server-side salt using PBKDF2/HKDF. Keys are never stored in plaintext.
Clarmont servers receive already-encrypted blobs for sensitive fields. Decryption requires the user's key, which is derived at runtime and never persisted on our servers.
We believe you deserve an honest answer to this question, not marketing language.
| Data | Clarmont can see it | Notes |
|---|---|---|
| Your name and email address | ✅ Yes | Required to run your account |
| Document filenames | ✅ Yes | Stored as metadata in plaintext |
| Document upload timestamps | ✅ Yes | Stored as metadata |
| Beneficiary names | ✅ Yes | Needed for access grant logic |
| Document contents | ❌ No | Encrypted before upload |
| Credential passwords | ❌ No | Encrypted with AES-256-GCM |
| Crypto seed phrases | ❌ No | Encrypted with AES-256-GCM |
| Private notes in your vault | ❌ No | Encrypted before storage |
| Your Clarmont password | ❌ No | bcrypt hash only — irreversible |
This is the most important security question for Clarmont. If it's designed wrong, the vault is either inaccessible after death or accessible to the wrong people.
When you designate a beneficiary, Clarmont records the grant — who has access to what, under what conditions — in your account settings. Beneficiaries receive an invitation email but cannot access any vault contents while the account holder is alive and active.
Beneficiary access is unlocked through a documented claim process:
Every access grant, every beneficiary invitation, every release approval is logged with a timestamp and admin identifier. If a release is ever disputed, there is a complete audit trail.
We're designing a cryptographic time-lock system that will allow vault access to be granted through a verifiable death signal without requiring staff review for standard family access. This is in research; current access is staff-reviewed.
We chose providers with the strongest compliance posture available to consumer SaaS companies.
| Service | Provider | What it does | Compliance |
|---|---|---|---|
| Hosting & edge compute | Render | Runs the Clarmont application | SOC 2 Type 2 |
| File storage | Cloudflare R2 | Stores encrypted uploaded documents | FIPS 140-2 compliant ciphers |
| Database | Neon (PostgreSQL) | Stores encrypted vault data, account info, access grants | SOC 2 Type 2 |
| Email delivery | Postmark | Sends verification, notifications, beneficiary invites | SOC 2 Type 2, PCI DSS Level 1 |
| Payments | Stripe | Processes one-time payments | PCI DSS Level 1 Service Provider |
Clarmont data is hosted in US-based data centers. We do not currently offer EU-region data residency.
We do not sell, rent, or share your personal data with third parties for marketing purposes. Period.
Your password is hashed with a high work factor. Bcrypt is intentionally slow — hundreds of milliseconds per check — making brute-force attacks economically unviable.
Sessions expire after 30 days of inactivity, invalidate on password change, and use HTTP-only SameSite cookies to prevent XSS-based theft.
Email addresses are verified before vault features activate. Unverified accounts cannot upload documents, add credentials, or designate beneficiaries.
Two-factor authentication (Google Authenticator, 1Password, Authy) is available from your account Security settings. Step-up verification is required to reveal passwords, seed phrases, and exchange credentials.
Login attempts are rate-limited by IP. After repeated failures, accounts enter a temporary cooldown to prevent credential-stuffing attacks.
We don't support "security questions" — the answer is almost always guessable from social media. Password recovery goes through verified email only.
We monitor application errors, unusual access patterns, and authentication anomalies continuously via infrastructure alerting and structured logging.
In the event of a confirmed breach affecting user data, we will:
Unencrypted account data, bulk credential exposure
Metadata exposure, billing data compromise
Infrastructure incidents with no confirmed data access
Found a security issue? Email security@lifelocker.app. We respond within 2 business days. We don't have a formal bug bounty program yet, but we acknowledge responsible disclosure publicly (with your permission).
Response within 2 business days. Responsible disclosure acknowledged publicly (with permission).