Your Files. Protected.
Your notes, filenames, and metadata are encrypted at rest with AES-256-GCM, the same standard trusted by banks and password managers. Your files travel over TLS and are stored as private objects, locked to your account. When you set up a switch to deliver files to a beneficiary, we hold the keys so your family is never locked out — explained in detail below, with every share yours to revoke.
Encrypted, access-controlled, and delivery-ready. By design.
How Your Data Is Protected
Your File
Uploaded from your browser
TLS
Private Storage
Locked to your account
Filenames & Notes
Everything you type
AES-256-GCM
Encrypted at Rest
In our database
Files are encrypted in transit (TLS) on the way to us
Files are stored as private objects, isolated per account and never publicly readable
Filenames, notes, and other metadata are encrypted at rest in our database (AES-256-GCM)
Same encryption used by banks and governments (AES-256-GCM)
AI connectors: when you authorize an AI connector (like Claude) to work with your account, it can read and work with your content while your session is unlocked. There's no per-file "hide from AI" cryptographic tier — access follows your session, not individual files. Learn more about the Claude connector →
Share Securely, Stay Private
When you share a file, we generate a unique secure access token for that one share. We store a hash of it for verification, plus a copy encrypted with our server-side vault so the link can still be delivered — or re-sent by you — later. Revoking the share kills the token immediately.
You share a file - A unique secure access token is generated for that share
We store a hash, not the token - The plaintext token is never persisted, only its SHA-256 fingerprint
Recipient gets a link - The token is in the URL and is checked against the stored hash to authorize access
Recipient gets a unique secure link
The token is verified against a stored hash; the copy we keep is vault-encrypted
You can revoke access anytime
Every transfer is TLS-protected; metadata stays encrypted at rest throughout
Your Digital Legacy, Protected
Deadman switches automatically transfer your files to beneficiaries if you stop checking in. Here's how we maintain security while enabling this automation.
How Deadman Switch Encryption Works
You Create a Switch
For each beneficiary-file combination, a unique access key is generated
Keys Are Encrypted and Stored
Access keys are encrypted with our server key (AES-256-GCM) before storage - protected even from database access
You Check In Regularly
As long as you check in, nothing happens. Your files stay encrypted and private.
Miss Your Check-In? Switch Triggers
Access keys are decrypted (server-side) and unique links sent to each beneficiary
Nothing moves early - Your files stay private to your account until delivery time
Per-beneficiary keys - Each person gets their own unique access link
Keys encrypted at rest - Protected by server-side encryption
Test before you trust - Verify everything works with test mode
How Delivery Works
When you create a share link or add a file to a deadman switch, we build that delivery on our servers and protect it with our server-side vault, so we can hand it to your beneficiary when the time comes — without needing you present. This is the same approach used by 1Password (Emergency Access), Bitwarden (Emergency Contact), and LastPass (Emergency Access).
Because each share is a separate record with its own access token, you can revoke any individual share at any time — once revoked, that token stops working immediately and all access through it is gone. No impact on your other shares or beneficiaries.
All share link access and email delivery are automatically logged with IP addresses and location data, so any activity leaves a clear audit trail.
Technical Deep Dive
For the security-minded, here's exactly what we use under the hood.
- File Encryption: AES-256-GCM (Advanced Encryption Standard, 256-bit key, Galois/Counter Mode)
- Key Derivation: PBKDF2 with SHA-256, 100,000 iterations (exceeds OWASP recommendations)
- Token Hashing: SHA-256
- IV Size: 12 bytes (96 bits) - standard for GCM
- Salt Size: 16 bytes (128 bits) - randomly generated
Some existing files still use an optional client-side wrapped master key — a legacy "Sealed" mode from before server-side encryption became the default:
- Password-derived key: your password (never stored) derives a key via PBKDF2, which unwraps your master key in the browser
- Per-file keys: each Sealed file has its own random key, wrapped by your master key — the encrypted file itself is never re-uploaded or re-encrypted when your password changes
- Never escrowed: the master key never leaves your browser and is never stored anywhere
Important: If you lose your password, a Sealed file cannot be recovered — we have no way to decrypt it. That is exactly why we moved away from this model: new files don't depend on it, and a password reset never costs you anything.
Additional encryption for metadata stored in our database:
- Cloak Vault: AES-256-GCM encryption for database fields
- Encrypted Fields: Filenames, descriptions, storage paths
- Key Management: Server encryption keys stored in secure environment variables
- Defense in Depth: Even metadata is protected against database breaches
How We Compare
| Feature | Killswitch | Google Drive | Dropbox | iCloud |
|---|---|---|---|---|
| Automatic deadman-switch delivery | Limited | Limited | ||
| Beneficiary management | ||||
| Conditional release on inactivity | Limited | |||
| Encrypted at rest |
Ready to Secure Your Digital Life?
Join thousands of people who trust Killswitch to protect their most important files and ensure their digital legacy reaches the right hands.