Your Files. Protected.

Killswitch encrypts your files at rest and in transit using AES-256-GCM, the same standard trusted by banks and password managers. When you set up a switch to deliver files to a beneficiary, we use the same per-share key model as 1Password's Emergency Access — explained in detail below, with every share yours to revoke.

Encrypted at rest and in transit. By design.

Encrypted at Rest and in Transit

Your File

Uploaded

AES-256-GCM

Encrypted at Rest

On our servers

Files are encrypted in transit (TLS) on the way to us

Files are encrypted at rest in storage

Filenames, notes, and other metadata are encrypted in our database

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, encrypt the underlying access key with our server-side vault, and only ever store a hash of the token itself.

1

You share a file - A unique secure access token is generated for that share

2

We store a hash, not the token - The plaintext token is never persisted, only its SHA-256 fingerprint

3

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

Only a hash of the token is stored on our servers

You can revoke access anytime

Files stay encrypted at rest and in transit 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

1

You Create a Switch

For each beneficiary-file combination, a unique access key is generated

2

Keys Are Encrypted and Stored

Access keys are encrypted with our server key (AES-256-GCM) before storage - protected even from database access

3

You Check In Regularly

As long as you check in, nothing happens. Your files stay encrypted and private.

4

Miss Your Check-In? Switch Triggers

Access keys are decrypted (server-side) and unique links sent to each beneficiary

Files stay encrypted - Encrypted at rest with AshCloak 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, a unique encryption key is generated specifically for that share. That key is encrypted with our server-side vault before being stored, so we can deliver it to your beneficiary when the time comes. This is the same approach used by 1Password (Emergency Access), Bitwarden (Emergency Contact), and LastPass (Emergency Access).

Because each share gets its own unique key, you can revoke any individual share at any time — once revoked, that key is destroyed and all access through it is permanently 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.

Encryption Algorithms
  • 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
Legacy Sealed files (optional)

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. New files are encrypted at rest and in transit by default and don't depend on this legacy mode.

Server-Side Protection

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.